Does it make sense to remove slots ?

[Lee Salzman]

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/
>