In the Wikipedia entry on Smalltalk, there is this line in the history
section, 3rd paragraph, added roughly a year ago: "...Smalltalk-80 added [[metaclass]]es, to help maintain the "everything is an object" (except private instance variables) paradigm by associating properties and behavior with individual classes, ..." Is this one of those esoteric details that mere mortals are not meant to understand, or is this an error? Lawson |
On Mon, Oct 25, 2010 at 1:59 PM, Lawson English <[hidden email]> wrote: In the Wikipedia entry on Smalltalk, there is this line in the history section, 3rd paragraph, added roughly a year ago: "...Smalltalk-80 added [[metaclass]]es, to help maintain the "everything is an object" (except private instance variables) paradigm by associating properties and behavior with individual classes, ..." "(except private instance variables)" looks like a dig or a jibe. I would have put it
"...Smalltalk-80 added [[metaclass]]es, to help maintain the "everything is an object" paradigm by allowing classes to have their own specific state and behavior, ..." Perhaps they were trying to say that because Smalltalk lacks private instance variables Smalltalk objects are not true objects, which is I suppose arguable. But it makes poor sense to state that private instance variables aren't objects; public inst vars aren't objects either.
best, Eliot
|
On 25.10.2010, at 23:10, Eliot Miranda wrote:
It's plain nonsense. Here's the edit that added the "private instance" modifier: Someone should just correct it. - Bert - |
On 10/25/10 2:23 PM, Bert Freudenberg wrote:
So now I just confused (more). Instance variables are NOT objects in Squeak? Lawson |
On 25.10.2010, at 23:42, Lawson English wrote:
They are, don't get confused. It depends on what is meant by "instance variable". Their contents are objects of course. No doubt about that, everything is still an object. But there is no "variable" object. Assignment to temps and instance variables is not a message send, but done "directly". I guess that's what some people mean when complaining about insufficient "objectness" of variables. - Bert - |
In reply to this post by LawsonEnglish
On Mon, Oct 25, 2010 at 2:42 PM, Lawson English <[hidden email]> wrote:
No they're not. They're elements of objects. Instance variables contain references to objects but you can't send messages to instance variables, only to their contents. In Smalltalk instance variables implement the state of objects while classes implement the behavior of objects.
HTH Eliot
|
In reply to this post by LawsonEnglish
2010/10/25 Lawson English <[hidden email]>:
> On 10/25/10 2:23 PM, Bert Freudenberg wrote: > > On 25.10.2010, at 23:10, Eliot Miranda wrote: > > > On Mon, Oct 25, 2010 at 1:59 PM, Lawson English <[hidden email]> wrote: >> >> In the Wikipedia entry on Smalltalk, there is this line in the history >> section, 3rd paragraph, added roughly a year ago: "...Smalltalk-80 added >> [[metaclass]]es, to help maintain the "everything is an object" (except >> private instance variables) paradigm by associating properties and behavior >> with individual classes, ..." >> >> >> Is this one of those esoteric details that mere mortals are not meant to >> understand, or is this an error? > > "(except private instance variables)" looks like a dig or a jibe. I would > have put it > "...Smalltalk-80 added [[metaclass]]es, to help maintain the "everything is > an object" paradigm by allowing classes to have their own specific state and > behavior, ..." > > Perhaps they were trying to say that because Smalltalk lacks private > instance variables Smalltalk objects are not true objects, which is I > suppose arguable. But it makes poor sense to state that private instance > variables aren't objects; public inst vars aren't objects either. > > It's plain nonsense. Here's the edit that added the "private instance" > modifier: > http://en.wikipedia.org/w/index.php?title=Smalltalk&diff=prev&oldid=280020438 > Someone should just correct it. > > So now I just confused (more). Instance variables are NOT objects in Squeak? > This has to be german here... Temp and instance variable point to some objetcs, but are not reified as Objects by themselves... Technically, there are just an offset (instance variable = offset in receiver object, temp variable = offset in the context). Nicolas > > Lawson > > > > > |
In reply to this post by Eliot Miranda-2
On Mon, Oct 25, 2010 at 2:49 PM, Eliot Miranda <[hidden email]> wrote:
I think that's sloppy language, Bert. An instance variable is /not/ an object. An instance variable is a reference to an object. variables != values. Yes, it's complicated but the binding of names to values is essential to programming languages.
best Eliot
|
I agree with Eliot that we should very clearly answer the question "are
instance variables objects?" with "no: but they hold references to objects". But I would like to discuss some related questions - "Could instance variables be objects?" Yes, but there would be significant costs. You would have to solve issus of infinite regress (how do you represent the instances variables of the instance variables? And the instance variables of the instance variables of the instance variables? And so on....) and even then they would add significant overhead to the implementation. "Would anything good come from having instance variables be objects?" Debuggers, browsers and other tools could be written in more object oriented and less imperative style. In fact, the compiler does create objects for the instance variables while doing its job but throws these objects away when it is finished. "Is there some way to have the advantages of variables as objects without all the costs?" The compiler shows it can be done - only have them be objects when you happen to be looking at them but not otherwise. Self mirrors are a great example of this - when you create a mirror on some object, it seems to be a set of "slot" objects. You can send many interesting messages to the individual slots as well as to the whole set. For any object on which you don't have a mirror, no slot objects exist. -- Jecel |
In reply to this post by Eliot Miranda-2
On 10/25/2010 4:17 PM, Jecel Assumpcao Jr. wrote:
> Yes, but there would be significant costs. You would have to solve issus > of infinite regress (how do you represent the instances variables of the > instance variables? And the instance variables of the instance variables > of the instance variables? And so on....) and even then they would add > significant overhead to the implementation. FWIW, Tweak reifies instance variables in its fields. Also, class variables are reified (as Associations). Cheers, - Andreas > "Would anything good come from having instance variables be objects?" > > Debuggers, browsers and other tools could be written in more object > oriented and less imperative style. In fact, the compiler does create > objects for the instance variables while doing its job but throws these > objects away when it is finished. > > "Is there some way to have the advantages of variables as objects > without all the costs?" > > The compiler shows it can be done - only have them be objects when you > happen to be looking at them but not otherwise. Self mirrors are a great > example of this - when you create a mirror on some object, it seems to > be a set of "slot" objects. You can send many interesting messages to > the individual slots as well as to the whole set. For any object on > which you don't have a mirror, no slot objects exist. > > -- Jecel > > > |
Free forum by Nabble | Edit this page |