[squeak-dev] Re: Migrating Complex in a separate package

Juan Vuletich juan at jvuletich.org
Tue Oct 11 12:49:20 UTC 2011


Hi Folks,

Rodney Polkinghorne wrote:
> ...
>
> extra fact:
> - Complex is absent from Cuis
>   

Not for long :) . I have already integrated it and will be in next Cuis 
release. I think Complex belongs in the base system.

> I think a common Complex library makes sense.
>
>   
>> What do you think of these proposals ?
>>     
>
> If complex numbers are removed from the image, there's a risk that
> scientists evaluating Squeak won't find them, and will reject
> Smalltalk as a result.  Complex can't be a library, because it takes
> special syntax to parse 3+4i.  Or so everyone thinks, who hasn't seen
> Smalltalk.
>
> I think brevity trumps the arguments for ComplexNumber.  Rebuttal:
>
> 1. Does any other language call them that?  Scheme, C, Python and
> Haskell all say complex.
>
> 2. Smalltalk has been used for 30 years.  Has there ever been an
> isComplex method that didn't refer to numbers?
>
> 3. All symbolic algebra systems I know about define isKnown, to test
> for literal values of any type.  Users can define isKnownComplex as
> self isKnown & self isComplex if they want to.
>   

Agreed wrt class name. But #isComplex has complete different semantics 
in BorderStyle and ParseNode. I think this is a clear case of "false 
polymorphism": using the same selector for completely different 
semantics, that should never be confused. It is better if this selector 
is changed for three distinct ones, to make the meaning clearer and 
avoid errors.

>> unifying Complex and Point
>>     
>
> I think points with non-elemental arithmetic would be too big a
> change.  However, Point>>asArgandComplex and Complex>>asArgandPoint
> would be useful.
>
> Rodney

Haven't made my mind wrt this. Not sure at all.

Cheers,
Juan Vuletich



More information about the Squeak-dev mailing list