[squeak-dev] Instance variable access in superclasses.

> And thus the fragile superclass problem is born.
>
> The thing is, there are two overlapping but different perspectives
> here. From an object-centric view, sure, any state or behavior is
> there in the object and where in the hierarchy it comes from is a
> minor detail.
>
> However, as far as the code goes, we are talking about distinct chunks
> of code, potentially written, maintained and updated by different
> people. A subclass depends on the superclass in the same way that code
> using a library is a dependent of that library's API. Managing that
> dependency has maintainability repercussions, and weakening it is a
> good thing.
>
> Cheers,
>
> --Vassili

>
> On Nov 25, 2008, at 7:45 PM, Igor Stasenko wrote:
>> My understanding of inheritance is different, in short:
>> A subclass of particular class is a _specialization_ of base class,
>> not  _expansion_.
>
> In this context, I sometimes wonder if Square should inherit from
> Rectangle (a specialization in which width and height are equal), or
> Rectangle should inherit from Square (adding an instance variable). Am I
> right that you would have Square inherits from Rectangle (Square being
> more specialized)? But then it feels like we are wasting an instance
> variable (since Rectangle would have two).
>
> James
>
>

>
> On 26-Nov-2008, at 1:54 PM, Tony Garnock-Jones wrote:
>
>> Greg A. Woods; Planix, Inc. wrote:
>>>
>>> I.e. you could sort of create a subclass by simply copying the whole
>>> class definition you wish to inherit from, then modify it to your liking
>>> (this has been done an infinite number of times in uses of non-OO
>>> languages!).  However then you lose the support of the system to maintain
>>> the relationship between the shared parts of the superclass definition(s)
>>> and the subclasses that inherit from it (or indeed even just between the
>>> superclass and its sole subclass in the case where the superclass is not
>>> actually an abstract class).
>>
>> Traits?
>
> Maybe.  I don't know.
>
> I definitely don't know how Traits would/could work in Smalltalk and what
> benefit they would bring.
>
> Does anyone have a reference to a good outline of what Traits do for
> Smalltalk?  Do they provide the ability to hide instance variables from
> subclasses -- or eliminate the need for recompiling subclasses?  Do they
> simply add a new feature, or do they replace something in (or even all of)
> classes or metaclasses?
>
> --
>                                        Greg A. Woods; Planix, Inc.
>                                        <[hidden email]>
>
>
>
>
>

> James Foster a écrit :
> >
> > On Nov 25, 2008, at 7:45 PM, Igor Stasenko wrote:
> >> My understanding of inheritance is different, in short:
> >> A subclass of particular class is a _specialization_ of base class,
> >> not  _expansion_.
> >
> > In this context, I sometimes wonder if Square should inherit from
> > Rectangle (a specialization in which width and height are equal), or
> > Rectangle should inherit from Square (adding an instance variable). Am I
> > right that you would have Square inherits from Rectangle (Square being
> > more specialized)? But then it feels like we are wasting an instance
> > variable (since Rectangle would have two).
>
> Beware, you're dangerously sliping to multiple inheritance because your
> Square might also be a lozenge :)

> Tony Garnock-Jones wrote:
>> Bert Freudenberg wrote:
>> > Just a meta remark - I find it highly amusing how people dissect the
>> > Gospel of Alan, even interpreting it literally. He must get quite a
>> > chuckle from that ;)
>>
>> Well I hope so! :-)
>
> Given how happy he said he was to not have any disciples, he might be
> less than amused to find out otherwise ;-)
>
> Going to the other extreme, where everyone's opinion is equally valid,
> leads to situations like a guy explaining to me on comp.lang.lisp that
> multiple dispatch is the most important feature of OOP and so CLOS and
> C++ are true OO languages but Smalltalk is not.
>
>>http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/b2aa1842ccb7d7c/134456502780e63f?hl=en&lnk=gst&q=jecel#134456502780e63f

> On 26.11.2008, at 09:48, Igor Stasenko wrote:
>
>> 2008/11/26 Trygve Reenskaug <[hidden email]>:
>>>
>>> On 26.11.2008 05:32, Igor Stasenko wrote:
>>>>
>>>> 1. Everything is an object
>>>> 2. Objects communicate by sending and receiving messages (in terms of
>>>> objects)
>>>> 3. Objects has their own memory (in terms of objects)
>>>> ----
>>>> 4. Every object is an instance of class (which must be an object)
>>>> 5. The class holds the shared behavior for its instances (in the form
>>>> of objects in a program list)
>>>> 6. To eval a program list, control is passed to the first object and
>>>> the remainder is treated as its message
>>>>
>>>> so, where in these statements you find anything about inheritance, or
>>>> something where it says that subclass(es) should have any assumptions
>>>> about the ways how superclass is storing its instances in memory, and
>>>> therefore a subclass allowed to directly manipulate the object's state
>>>> without consulting with superclass?
>>>
>>> I'm afraid Alan wasn't as precise as he should have been here.
>>
>> I think he did this intentionally, because a precise parts is up to
>> implementation.
>> The principles above is most generic ones. Btw, notice a line between
>> 3 and 4, its not just a random stroke - its actually shows a first
>> step from most generic to more specific.
>
>
> Just a meta remark - I find it highly amusing how people dissect the Gospel
> of Alan, even interpreting it literally. He must get quite a chuckle from
> that ;)
>

> On Thu, Nov 27, 2008 at 3:54 AM, Jecel Assumpcao Jr <[hidden email]
> > wrote:
>> Tony Garnock-Jones wrote:
>>> Bert Freudenberg wrote:
>>>> Just a meta remark - I find it highly amusing how people dissect  
>>>> the
>>>> Gospel of Alan, even interpreting it literally. He must get quite a
>>>> chuckle from that ;)
>>>
>>> Well I hope so! :-)
>>
>> Given how happy he said he was to not have any disciples, he might be
>> less than amused to find out otherwise ;-)
>>
>> Going to the other extreme, where everyone's opinion is equally  
>> valid,
>> leads to situations like a guy explaining to me on comp.lang.lisp  
>> that
>> multiple dispatch is the most important feature of OOP and so CLOS  
>> and
>> C++ are true OO languages but Smalltalk is not.
>>
>>> http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/b2aa1842ccb7d7c/134456502780e63f?hl=en&lnk=gst&q=jecel#134456502780e63f
>
> I know I shouldn't react, but could you just dissect for me how Alan's
> post, either the one before or the one after the post of yourself you
> linked here, makes the point you're suggesting him to be making?
>
> Is it the 'I've no idea where I'm going with this.' part perhaps?

> On Thu, Nov 27, 2008 at 3:54 AM, Jecel Assumpcao Jr wrote:
> > Going to the other extreme, where everyone's opinion is equally valid,
> > leads to situations like a guy explaining to me on comp.lang.lisp that
> > multiple dispatch is the most important feature of OOP and so CLOS and
> > C++ are true OO languages but Smalltalk is not.
> >
> >>http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/b2aa1842ccb7d7c/134456502780e63f?hl=en&lnk=gst&q=jecel#134456502780e63f
>
> I know I shouldn't react, but could you just dissect for me how Alan's
> post, either the one before or the one after the post of yourself you
> linked here, makes the point you're suggesting him to be making?
>
> Is it the 'I've no idea where I'm going with this.' part perhaps?

>
> On 25-Nov-08, at 11:21 PM, Andreas Raab wrote:
>
>> Holy cow. If that actually works, it's impressive as hell. Given the
>> complexity in ClassBuilder (all of which is the direct result of
>> people actually using it and running into issues) it'll be no small
>> feat to get this right in SystemEditor. I've spent a few years on it ;-)
>
> It shows. ClassBuilder isn't actually that hard to understand. The
> constraints are hairy, but the code is fairly straightforward and has
> lots of comments.
>
> In SystemEditor, those constraints are encapsulated in ClassFormat, with
> unit tests. The tests probably aren't as complete as they could be, but
> it gives us a place to document issues as they come up.
>
> I'm looking forward to reenabling atomic commits in Monticello2. The
> speed improvement there is even greater, because right now, MC2 takes a
> speed hit from loading instance variables one at a time.
>
> Colin
>
>

> On Wed, Nov 26, 2008 at 02:53:17PM -0800, Andreas Raab wrote:
> > Hi Colin -
> >
> > I was looking over SystemEditor and one thing that really surprised me
> > was the use of ClassEditors as proxies. What is the reasoning behind it?
> > It makes the design difficult to understand and extremely hard to debug
> > - I gave up trying to find out what causes the issue with class
> > migration when I effectively couldn't debug the editors since all they
> > would show me were those pretend-classes. Is there some sort of debug
> > mode to turn off all that evil magic? ;-)
>
> yes. from the context of a class editor, do this:
>
> self system debug: true
>
> I got fed up with that myself today and made debug mode the
> default. I havn't committed that change yet.

>> However, as far as the code goes, we are talking about distinct chunks
>> of code, potentially written, maintained and updated by different
>> people. A subclass depends on the superclass in the same way that code
>> using a library is a dependent of that library's API. Managing that
>> dependency has maintainability repercussions, and weakening it is a
>> good thing.
>
> Not at the expense of encapsulation by forcing access to instance variables
> to go through public accessors.  Protected accessors (visible only to self
> and subclasses) might be a compromise but then you open up the whole can of
> worms going down that path where the language starts trying to protect the
> programmer from himself with all kinds of visibility options for methods and
> classes.
>
> This leads to things like csharp and java's final/sealed classes where the
> author of a class decides all future uses of the class.  I prefer a language
> to enable me, not restrict me.  I don't want the author of a class deciding
> for me how I might decide to use that class in the future.  If the fragile
> base class problem is the price, then I'm happy to pay it.

> Matthew Fulmer wrote:
> > The syntax to do that is:
> >
> > ed := SystemEditor new.
> > (ed at: #Morph) addInstVarName: #foo.
> > ed commitWithProgress.
> >
> > Adding an instance variable to Morph used to work, but now it
> > runs out of memory :P
>
> This doesn't seem to work. If I do something a little simpler:
>
>    ed := SystemEditor new.
>    (ed at: #SimpleButtonMorph) addInstVarName: #foo.
>    ed commitWithProgress.
>
> it completes but subinstances of SimpleButtonMorph are not correctly
> migrated. Try inspecting foo in "IconicButton someInstance" or in
> "UpdatingSimpleButtonMorph someInstance".