[squeak-dev] Instance variable access in superclasses.

Hi all.

What would people's reaction be if a class was prevented from being able to directly access its superclass's instance variables? A subclass should use accessor methods to access a superclass's instance variables.

Is there any particular reason subclasses get access to superclass instance variables? I think it breaks encapsulation.

If this was implemented, it might be possible to avoid needing to recompile every subclass when you modify the instance variables of a class.

Gulik.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

2008/11/25 Michael van der Gulik <[hidden email]>: No, you can't avoid recompiling.
Suppose base class having vars:
0 - a
1 - b

and subclass

2 - d
3 - c

now, if you add or remove vars in base class, indexes of 'd' and 'c'
variables will be shifted correspondingly. And therefore it would
require to recompile all methods where you using 'd' and 'c' ivars. It
also may require recompiling methods in base class, when you inserting
a var before a or b.. or removing var 'a'. - for same reason - indexes
will be shifted.

> Gulik.
>
> --
> http://people.squeakfoundation.org/person/mikevdg
> http://gulik.pbwiki.com/
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

I was thinking, briefly, about modifying the VM and object memory format so that instance variables are always indexed beginning from 0 for every subclass. Somehow.

It isn't necessarily a good idea. I haven't thought through the details yet.

Gulik.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

2008/11/25 Michael van der Gulik <[hidden email]>:
Well, if you put ivars into dictionary of some sort, then you don't
need to recompile anything. But speed tradeoff will be huge :)
One possible format change could be to keep a class ivars starting
index in its instanceFormat field.
Then, when you changing the number of ivars, you simply go through
subclasses and update their instanceFormat w/o recompiling  methods.
You still need to recompile methods but only of class which changes
its ivars:

ClassA (ivarsIndex = 0)
ivars: a, b, c

ClassB (ivarsIndex = 3)
ivars: d,e,f

Now if you change ClassA ivars to = 'b,c'
you setting ClassB ivarsIndex = 2
and recompiling ClassA methods.

An ivar accessing instruction now requires 2 arguments: index and class.

ivarAddr = oop at: (class ivarsIndex) + index

not much overhead, but you have to keep a class oop in literal frame of method :

ClassB >> methodFoo
   ^ a + e

will require to keep 2 class oops (ClassA and ClassB) , because you
accessing ivars from both of them..

IMO, it is better to recompile things all the way down, rather than
bother with such complexity which gives no real benefits except
compiling time.

> It isn't necessarily a good idea. I haven't thought through the details yet.
>
> Gulik.
>
> --
> http://people.squeakfoundation.org/person/mikevdg
> http://gulik.pbwiki.com/
>


--
Best regards,
Igor Stasenko AKA sig.

Michael van der Gulik wrote:
> I was thinking, briefly, about modifying the VM and object memory
> format so that instance variables are always indexed beginning from
> 0 for every subclass. Somehow.

See a detailed implementation of this here -

http://stephane.ducasse.free.fr/FreeBooks/LittleSmalltalk/ALittleSmallta
lk.pdf

> It isn't necessarily a good idea. I haven't thought through the details yet.

I think that the versions of Little Smalltalk created after the book was
published no longer use this idea. I would have to look at the sources
again to be sure.

-- Jecel

On Wed, Nov 26, 2008 at 12:13:14AM +0200, Igor Stasenko wrote:
> IMO, it is better to recompile things all the way down, rather than
> bother with such complexity which gives no real benefits except
> compiling time.

Or switch to SystemEditor, which can recompile classes 6-8x
faster than ClassBuilder.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

 > What would people's reaction be if a class was prevented from being
 > able to directly access its superclass's instance variables?

      "This is insane." :)


-C

Craig Latta wrote:
>
> > What would people's reaction be if a class was prevented from being
> > able to directly access its superclass's instance variables?
>
>      "This is insane." :)

"I hope you have a good inlining JIT"  :-p

Josh


>
>
> -C
>
>
>

Matthew Fulmer wrote:
> On Wed, Nov 26, 2008 at 12:13:14AM +0200, Igor Stasenko wrote:
>> IMO, it is better to recompile things all the way down, rather than
>> bother with such complexity which gives no real benefits except
>> compiling time.
>
> Or switch to SystemEditor, which can recompile classes 6-8x
> faster than ClassBuilder.

Really? I'm somewhat surprised to hear that. It means that either most
of the time in recompilation doesn't go where I think it goes or that
SystemEditor does things very differently from ClassBuilder. Either way
I always take a 6x-8x speedup when I can get one - where do I find
SystemEditor to run a few benchmarks against it?

Cheers,
   - Andreas

Joshua Gargus wrote:
> Craig Latta wrote:
>>> What would people's reaction be if a class was prevented from being
>>> able to directly access its superclass's instance variables?
>>      "This is insane." :)
>
> "I hope you have a good inlining JIT"  :-p

It's neither insane nor is an inlining JIT is a strict necessity. Tweak
for example uses property dictionaries throughout and although it's
slower than I'd like it to be it's certainly acceptable for most
situations. Also, doesn't Newspeak use messages for *all* accessors?

I think most people would be surprised to see how acceptable the
practical behavior is on modern day machines. The boxes are so darn fast
it's not even funny...

Cheers,
   - Andreas

>
> Hi all.
>
> What would people's reaction be if a class was prevented from
> being able to directly access its superclass's instance
> variables?

I would object.

> A subclass should use accessor methods to access a
> superclass's instance variables.

Says who?

> Is there any particular reason subclasses get access to
> superclass instance variables? I think it breaks encapsulation.

Then we have different definitions of encapsulation.  To me encapsulation
means one object can not directly access the state of another object but
must use messages for communication.  

If class #B inherits from class #A an instance of class #B is only *one
object*; i.e. super is not another object but the same object as self and
thus the object should have direct access to *all* of its own instance
variables regardless of where they lie in the inheritance tree.  I don't
think encapsulation was intended to protect an object from itself.  That's
my 2 cents!

Ramon Leon
http://onsmalltalk.com

      Oh, I wasn't even thinking of the performance implications. I
think it's a bad idea from a semantic standpoint, too. And I'm not
saying that property dictionaries are necessarily bad (although I sure
haven't enjoyed the implications for debugging and navigating unfamiliar
code so far!).


-C

On Tue, Nov 25, 2008 at 3:48 PM, Andreas Raab <[hidden email]> wrote:
> It's neither insane nor is an inlining JIT is a strict necessity. Tweak for
> example uses property dictionaries throughout and although it's slower than
> I'd like it to be it's certainly acceptable for most situations. Also,
> doesn't Newspeak use messages for *all* accessors?

Yes, it does, and it's very nice especially considering that classes
are mixins, and inst var index base is different in different mixin
applications.

--Vassili

      Heh, sorry to use the mailing list like IRC. :)

      What seems particularly weird to me is using direct access for
some instance variables but not others (which is what I sensed from
Michael's original message). Of course there are reasonable systems that
don't have direct access at all.


-C

2008/11/26 Vassili Bykov <[hidden email]>:
I like the idea of hiding the state/storage specific details from eyes
of subclasses.
It makes irrelevant, in what format or where particular object holds its state.
As long as you providing messages to access it, it could be anything.


> --Vassili
>
>



--
Best regards,
Igor Stasenko AKA sig.

Hi all.



I'm referring to encapsulation of an implementation of something. If a superclass is an "implementation of something", a subclass is a user and extender of that "implementation of something". Allowing a subclass direct access to the innards of its superclass prevents that superclass from being able to protect its carefully guarded state from meddling by subclasses.

This is relevant in the area of secure programming for my SecureSqueak project, although I can't think of a good example yet where it would really be a problem.

Say you have a class with a carefully guarded secret in it. It would then be possible for untrusted, remotely loaded code to be a subclass of that class and then give out that secret. This makes several assumptions though: firstly that you can somehow create an instance of your subclass with that secret state (which is unlikely) and secondly that the remotely loaded code actually has access to the class and is able to become a subclass of it.

Gulik.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

On 25-Nov-2008, at 7:57 PM, Igor Stasenko wrote:
>
> I like the idea of hiding the state/storage specific details from eyes
> of subclasses.
> It makes irrelevant, in what format or where particular object holds  
> its state.
> As long as you providing messages to access it, it could be anything.

So why not just get rid of instance variables completely?   :-)

I think Ramon Leon hit the nail on the head.   You're not supposed to  
try to protect anything in a class definition from any of its  
subclasses.  Inheritance is a mechanism to _expand_ upon the  
definition of a class, not restrict it.

An instance of an object contains all of the components (instance  
variables, methods, etc.) of the class it belongs to as well as, by  
definition, all of the components from any (and all) class(es) it  
inherits from.  That's the whole idea, as I understand it, underlying  
the concept of inheritance.

An object shouldn't have to use accessor methods to get at its own  
internal state, no matter where in the class hierarchy its state may  
be defined.  "super" is only needed to get around explicit re-
definitions done by the subclass.

--
                                        Greg A. Woods; Planix, Inc.
                                        <[hidden email]>

2008/11/26 Greg A. Woods; Planix, Inc. <[hidden email]>:
My understanding of inheritance is different, in short:
A subclass of particular class is a _specialization_ of base class,
not  _expansion_.

An instance of subclass provides same interface as base class, but
with possibly different behavior (because of overrides) or provide
additional specialized interface (by introducing new methods).

If you look from a user's point of view (outside a class), you could
only send a messages to it. So, for you, as for user its not relevant
where an object holds its state - you only interested in its
behavior/interface.

As for subclass - a subclass interested in inheriting same interface
as base class. Inheriting a state information having a little
importance, its just an implementation detail for outside user of
class, because anyways he unable to operate with this state directly.

>
> --
>                                        Greg A. Woods; Planix, Inc.
>                                        <[hidden email]>
>


--
Best regards,
Igor Stasenko AKA sig.

On 25-Nov-2008, at 9:20 PM, Michael van der Gulik wrote:
> I'm referring to encapsulation of an implementation of something. If a
> superclass is an "implementation of something", a subclass is a user  
> and
> extender of that "implementation of something".

Well, umm, no, I don't think so -- a subclass is, by definition, an  
_extension_ of the class it inherits from.

> Allowing a subclass direct
> access to the innards of its superclass prevents that superclass  
> from being
> able to protect its carefully guarded state from meddling by  
> subclasses.

If such protection seems necessary then I'd say there's something  
extremely broken in the overall design of that part of the class  
hierarchy in question.

> This is relevant in the area of secure programming for my SecureSqueak
> project, although I can't think of a good example yet where it would  
> really
> be a problem.

Perhaps you could start by explaining some of the theory about how any  
kind of "secure" (do you really just mean "safe"?) programming  
techniques can be aided by what you seem to be describing here.

> Say you have a class with a carefully guarded secret in it. It would  
> then be
> possible for untrusted, remotely loaded code to be a subclass of  
> that class
> and then give out that secret.

Ah, perhaps you don't mean secure programming, but rather actual data  
security.

I really don't understand your security model here.  It doesn't seem  
to be related to or compatible with the object oriented programming  
model of Smalltalk at all, at least as I understand things.  A  
subclass is an extension of its superclass.  An object which is an  
instance of the subclass inherits all the qualities of the  
superclass(es) too.

An object that is only derived from the "superclass" is a separate  
object.  And it isn't an instance sharing any quality of any subclass  
that may inherit from its class, let alone sharing any data with any  
instance of any subclass.

> This makes several assumptions though:
> firstly that you can somehow create an instance of your subclass  
> with that
> secret state (which is unlikely) and secondly that the remotely  
> loaded code
> actually has access to the class and is able to become a subclass of  
> it.

Indeed, that part is just plain nonsensical.

You seem to be confusing the definition of objects with the actual  
objects themselves.

If you're really trying to create a model where objects created as  
instances of classes which have been remotely loaded, then you need to  
create some sort of partitioned VM storage model such that the VM will  
only pass messages between objects within a given partition, and  
perhaps one way from a parent partition.  I don't think this can  
really work very well in a Smalltalk system though, but perhaps I'm  
missing something.  If I load untrusted code I basically have to do it  
in a different VM image which has been carefully constructed so as to  
contain only public data and which has built-in controls which will  
only allow it to access those parts of the outside system environment  
which I would feel safe allowing untrusted code to access.  Perhaps  
this VM image could be dynamically created and managed by another full  
"parent" VM.  If I'm not mistaken this is kind of sort of how the Java  
VM security model is supposed to work.

--
                                        Greg A. Woods; Planix, Inc.
                                        <[hidden email]>

On 25-Nov-2008, at 10: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_.

Well when you're defining the behaviour of objects in an OO system  
there's not really any difference between "specialization" and  
"expansion" -- the subclass is _adding_ changes to the definitions  
given in the superclass.  Perhaps the changes will over-ride a  
behaviour in the superclass, or modify it in some way, but  
fundamentally a subclass is always adding something to the superclass  
in order to create the new subclass it defines.

Or to paraphrase the Blue Book, allowing intersection in class  
membership is the basic mechanism used to allow code sharing between  
class descriptions.  Smalltalk-80 of course doesn't allow multiple  
inheritance, just plain subclassing.

> If you look from a user's point of view (outside a class), you could
> only send a messages to it. So, for you, as for user its not relevant
> where an object holds its state - you only interested in its
> behavior/interface.

You don't send messages to a class -- you send messages to objects  
which are derived from a class, i.e. which follow the behaviours  
defined by the class.

> As for subclass - a subclass interested in inheriting same interface
> as base class. Inheriting a state information having a little
> importance, its just an implementation detail for outside user of
> class, because anyways he unable to operate with this state directly.

Classes don't have state -- objects have state.  An object which has  
been derived from a subclass gains definitions about its state from  
_all_ of the classes in the class hierarchy which the subclass belongs  
to.

At least that's how I understand things in the Smalltalk way of  
defining classes and instantiating objects.

--
                                        Greg A. Woods; Planix, Inc.
                                        <[hidden email]>