[squeak-dev] Instance variable access in superclasses.

>> So you are lamenting loss of encapsulation (a restrictive feature) in
>> the first paragraph, and decrying loss of freedom to restrictive
>> features in the second. Come on, pick one.
>
> Because I consider encapsulation something that exists between objects, not
> between super and subclass.  I don't consider that a conflict, interesting
> that you do.
>
>> If you don't want the
>> author of a class deciding how you might decide to use it, how can you
>> put up with him deciding what instance variables are off-limits and
>> have no public accessors?
>
> Again, the object class divide; he can't, in Smalltalk, restrict me from
> seeing instance variables if I subclass his class.  I like it this way.
> When I'm building a new class it's up to me whether to choose to use
> inheritance or not and if I choose to do so it's because I want to share
> code or extend or specialize that class and I want direct access to anything
> in that superclass.  My class is not his class and if I do something that
> makes my classes instances misbehave that's my problem, not his.
>
> The public interface of instances of his objects however, is his problem and
> he has every right to encapsulate and protect the implementation of his
> instances.  There simply is a difference, to me at least, between using
> someone else's objects, and using someone else's classes as a template to
> build my own objects.  I accept encapsulation as beneficial and necessary in
> the former case but as harmful and restrictive in the latter.
>
> I base this judgment on the vocabulary I find myself muttering in each case,
> usually profanity in the latter case while I hunt down source code to change
> the original authors access modifiers.
>
>> Indeed what I had in mind were Newspeak-style access modifiers
>> combined with message-based slot access. Their combination in fact
>> improves encapsulation. And no, they don't lead to final classes.
>>
>> Cheers,
>>
>> --Vassili
>
> They certainly start down that road, final and sealed are just as much
> access modifiers as public, private, or protected; however, if not applied
> zealously and taken too far (i.e. final classes), I agree it's not a bad
> solution.  I would prefer not to have two ways to access instances vars so
> if protected accessors were the solution I'd want them to replace all direct
> instance variable access, even within a single class so slots make perfect
> sense.  But at this point, we're not really talking about Smalltalk any
> more.
>
> I won't pretend to be a language designer or say I know what the perfect
> balance of features is, but I rather like the balance Smalltalk struck with
> no access modifiers, public methods, protected instances variables, and
> trust in the programmer.
>

> nicolas cellier wrote:
>> 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 :)
>
> With the Rectangle as subclass of Square option this wouldn't be a
> problem - you would just have two different subclasses of Square.
>
> Could Rectangle be a subclass of Square? Sure:
>
> - Square instance variables: center, size, orientation
>
> - Rectangle adds this instance variable: aspectRatio
>

> We can make Ellipse a subclass of Circle using the same style. We can
> even have an #aspectRatio method in Square and Circle which always
> returns 1 and then we can move some of the more general code up in the
> classes hierarchy if we want to.
>
> For raster graphics it is convenient to define Rectangles as always
> parallel to the screen axis so that just two points are enough to fully
> identify them. Perhaps calling them RasterRects instead would have made
> us think more clearly about them. We later moved to vector graphics
> (Balloon) but were stuck with the historic baggage.
>
> -- Jecel
> P.S.: I am aware that even in this scheme you might want Parallelogram
> to inherit from both Rectangle and Lozenge (actually, Rhombus is more
> generic) and then you have the multiple inheritance problem again. Which
> is what Traits are for...
>
>
>

> On Wed, Nov 26, 2008 at 8:42 PM, Ramon Leon
> <[hidden email]> wrote:
> >> So you are lamenting loss of encapsulation (a restrictive
> feature) in
> >> the first paragraph, and decrying loss of freedom to restrictive
> >> features in the second. Come on, pick one.
> >
> > Because I consider encapsulation something that exists
> between objects, not
> > between super and subclass.  I don't consider that a
> conflict, interesting
> > that you do.
>
> Then you don't seem to realize that we work with classes and their
> code, not objects. It's code dependencies that translate into
> maintenance. As for objects, their composition from class blueprints
> is not necessarily as unambiguous as you are used to. In Newspeak, for
> example, you can't always point and say, "this will be the superclass
> of this guy" because the superclass is late-bound. You can't even
> compile that sort of thing easily unless you take messages further, to
> communicate within objects as well as between them. I view that
> information hiding as beneficial enough to even overlook the sacrifice
> encapsulation in its naive understanding (see below what I really
> think about access modifiers).
>
> Encapsulation is an interesting thing in that popular literature
> promotes a very narrow view of it. It often starts with a reasonable
> explanation of information hiding as a noble architectural principle,
> then degrades into "so in a nutshell, store your data in private
> fields". That confuses information hiding with security. Information
> hiding helps structure code, security when it's inappropriate only
> gets in the way. There are languages where all object slots are
> accessible--CLOS, for example. I'd like to hear a C++ programmer
> declare CLOS a non-OO language because it lacks "encapsulation".
>
> This narrow view is the evidence of how little the mainstream gets OO.
> The mechanism for encapsulation in its true sense is so ingrained in
> Smalltalk you can't take it out--it's messages, with the late binding
> of a name to its interpretation. There is no other way to communicate
> with an object. Too bad for C++, but that is what OO is about, not
> "encapsulation, inheritance, polymorphism". Message-based computation
> enables information hiding and promotes weaker code dependencies.
>
> And now I can admit that I view access modifiers for slot accessor
> messages as more of a political tool to shut up those who would cry
> "aha, no encapsulation!" as soon as they saw messages used for slot
> access. I don't think they are an important safeguard preventing
> horrors from happening.
>
> Here is what I find interesting about the belief that encapsulation is
> critically flawed without object data hidden away. There is enough
> Smalltalk code out there written in variable-exposing style. Large
> complex systems have been built in CLOS with its wide open object
> slots. Where are the real horror stories about this practice? I mean
> real horror--not "I remember there was this bug once..." but rather
> "...and man, we had to spend weeks fixing that crap before it started
> working".
>
> All you hear are speculations how exposed variables are bad because
> encapsulation is good. That sounds to me like "dynamic typing is
> dangerous because you get runtime errors, and static typing would
> catch at least some of those". An intellectual bogeyman. It may sound
> reasonable as an isolated statement, but anyone with some practical
> experience will know better. Having open slots at your disposal is one
> thing, using that access indiscriminately to hurt yourself is a
> completely different one.
>
> One last point, the most likely reason instance variables are the way
> they are is because it was a necessary performance compromise for the
> '70s hardware. No reason to consider that as some sort of heavenly
> harmony, even if you are used to it.
>
> Cheers,
>
> --Vassili

> Secondly, the issue I was seeing with the iVars being incorrect are one
> of the subtleties that SE currently doesn't correctly deal with. Here is
> an illustration:
>
> testCleanupOfOldInstances
>    "Ensure that old instance are cleaned up properly"
>    instance := CleanupTestClass new.
>    Smalltalk garbageCollect. "for easier results make it old"
>
>    self assert: CleanupTestClass instanceCount = 1.
>
>    ed := SystemEditor new.
>    (ed at: #CleanupTestClass) addInstVarName: #whatever.
>    ed commit.
>
>    self assert: CleanupTestClass instanceCount = 1.
>
>    ed := SystemEditor new.
>    (ed at: #CleanupTestClass) removeInstVarName: #whatever.
>    ed commit.
>
>    self assert: CleanupTestClass instanceCount = 1.
>
> The problem is that since #become: changes class pointers you *must*
> clean out the old instances or otherwise they'll be completely and
> utterly broken when you finally #become: the classes itself. This can be
> achieved by placing a strategic full GC in the right place in the
> migration process (I'm not sure where that would be in SE but probably
> somewhere in the migration transaction).

>
> On 26.11.2008, at 22:38, Ties Stuij wrote:
>
>> 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?
>
>
> I know I shouldn't respond, but did you read further up in the thread, where
> Alan (Crowe) described how even the "simplest" things are impossible without
> multiple dispatch, which made him despise Smalltalk on his first encounter,
> an event he recites quite colorfully, with phrases like "I found this
> incomprehensibly awful. It completely destroyed the object metaphor. [...]
>  I fled in horror from this hideous, mutilating language."