Name spaces in Spoon
Michael Latta
lattam at mac.com
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
experience.
Michael
> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] 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
|