Name spaces in Spoon

Michael Latta lattam at
Sat May 27 16:40:14 UTC 2006

This is sort of my point exactly.  The object's behavior is different
depending on the sender of the message.  While some systems claim that to be
a valuable "feature" (I think Slate does that), I think it will just cause
confusion.  The argument for this often goes along the lines of supporting
different roles for an object in different contexts.  Joe as a Father at
home behaves differently than Joe as a Manager at work.  With the right tool
support it might seem natural to always ask "what context am I in when
reading this code?", but I think the cure is worse than the disease.  If
someone has actually used this type of system I would be interested in their


> -----Original Message-----
> From: squeak-dev-bounces at [mailto:squeak-dev-
> bounces at] On Behalf Of Peter Crowther
> Sent: Saturday, May 27, 2006 12:21 AM
> To: The general-purpose Squeak developers list
> Subject: RE: Name spaces in Spoon
> > From: Michael Latta
> > The downside I see in having call context dependent behavior
> > is that the
> > reader of the code needs to know the run-time context that
> > will modify the
> > behavior of the object.  The same result can be achieved with
> > a wrapper
> > object that implements the new methods, and passes on unknown
> > methods to the delegate.
> Consider the following: ClassA implements methodA as '^self'.  ClassB, a
> subclass of A, implements methodB as '^self methodA'.  Now a module adds
> methodA to ClassB (let's say it's '^self') and calls 'ClassB new
> methodB'.  The delegate case would call ClassA>>methodA, whereas the
> 'expected' behaviour is pobably a call of the module's methodA.  There's
> also an interesting discussion to be had about what class the returned
> object would be - it could be ClassB or ClassB-delegate depending on how
> this was implemented
> This is not 'the same result', I think.
> 		- Peter

More information about the Squeak-dev mailing list