Does it make sense to remove slots ?

[Brian Rice]

Neat! Finally a fun post.

I'll just follow up by adding that multiple dispatch can change 
#squish'es into:

e@(Ellipse traits) be: c@(Circle traits)
[
   "..."
   "Hocus pocus, ala kazaam, alchemy, voodoo, and presto, an ellipse 
becomes a circle!"
   e xRadius = e yRadius
     ifTrue: [e traits: c traits]
].

c@(Circle traits) be: e@(Ellipse traits)
[
   "..."
   "By the powers invested in me, I decree you an ellipse!"
   c traits: e traits
].

Although this last method could just be the same as a default be: 
method. :-)

You can almost smell the eeeeeeeevil. >:-)

On Nov 9, 2004, at 6:14 AM, Lee Salzman wrote:

> And just on a further note, some fatal assumptions seem to be made in
> this discussion. To quote Dave Ungar, "I sold the language [Self] 
> originally
> on dynamic inheritance."
>
> So, with my almighty, omnipotent powers of utter dynamicity, I decree
> the following pathological oddity that would have most Smalltalk
> programmers screaming (but not good little Self or Cecil programmers):
>
> (addPrototype: #Ellipse)
>   `>> [addSlot: #xRadius. addSlot: #yRadius].
>
> e@(Ellipse traits) squish
> [
>   "..."
>   "Hocus pocus, ala kazaam, alchemy, voodoo, and presto, an ellipse 
> becomes a circle!"
>   e xRadius = e yRadius
>     ifTrue: [e traits: Circle traits]
> ].
>
> addPrototype: #Circle derivedFrom: {Ellipse}.
>
> _@(Circle traits) extraStuffCirclesCanDoButEllipsesCannot
> ["..."].
>
> c@(Circle traits) squish
> [
>   "..."
>   "By the powers invested in me, I decree you an ellipse!"
>   c traits: Ellipse traits
> ].
>
> Slate is very stateful. Delegation is state. Imagine that, eh?
> Now, did that merit a whole mailing list discussion? :)
>
> On Mon, Nov 08, 2004 at 08:04:51PM -0800, Brian Rice wrote:
>> Okay, I'm kind of tired of the philosophical/theoretical/rhetorical
>> discussion at this point. :)
>>
>> So in the hope that a mildly put-my-foot-down response will get people
>> to think about improving the actual code, my recommendation is to not
>> have a separate Circle traits from Ellipse traits, and just let 
>> radius:
>> set both radii. In particular, handle circleness as a coincidence for
>> the most part if someone sets xRadius and yRadius to the same value
>> outside of that context (i.e. make an isCircle method).
>>
>> Just do it and don't be so uncertain about things.
>>
>> On Nov 7, 2004, at 1:36 AM, Pupeno wrote:
>>
>>> I'm creating some objects for Ellipses and circles and I have the
>>> following
>>> code:
>>>
>>> Graphics addPrototype: #Ellipse derivedFrom: {Area}.
>>> Ellipse addSlot: #center.
>>> Ellipse addSlot: #xRadius.
>>> Ellipse addSlot: #yRadius.
>>>
>>> Graphics addPrototype: #Circle derivedFrom: {Ellipse}.
>>> Circle addSlot: #radius.
>>> Circle removeSlot: #xRadius.
>>> Circle removeSlot: #yRadius.
>>>
>>> c@(Circle traits) xRadius [ c radius ].
>>> c@(Circle traits) xRadius: r [ c radius: r ].
>>> c@(Circle traits) yRadius [ c radius ].
>>> c@(Circle traits) yRadius: r [ c radius: r ].
>>>
>>> for me it makes sense since Circles are special cases of Ellipses
>>> where both
>>> radius are the same, so, whatever method I can apply to an Ellipse
>>> should be
>>> also available to Circle, except that a Circle can have only one
>>> radius.
>>> That's why I removed the slots, created another one, and then created
>>> accessors as if it was an Ellipse. Maybe the write accessors 
>>> shouldn't
>>> be
>>> there.
>>> Or, am I totally confused ? Does this make sense ?
>>> -- 
>>> Pupeno: pupeno at pupeno.com - http://www.pupeno.com
>>>
>> --
>> Brian T. Rice
>> LOGOS Research and Development
>> http://tunes.org/~water/
>>
>
>
--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/