[squeak-dev] Re: Instance variable access in superclasses.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Instance variable access in superclasses.

Ralph Boland
My idea here is too late for squeak but is food for thought
for the next great object oriented programming language.

Instead of using a full fledged message send for accessing
instance variables we could  use a compromise. 

Lets say that symbol  @  is special and cannot be used as a regular message
and let  var be an instance variable of a class MyClass and  used in MyClass
method myMethod.

Then to access var in myMethod we can write:

       @ var.

as in:

      ^ @ var

or even:

      @ var := 5.

With this notation local variables and instance variable are distinguishable
which results in safer and (arguably) more readable code.


One way of implementing this would be to require that MyClass
define  instance variable var or an error message would be generated.

The other way of  doing this would be to not require that MyClass define var.  However, if  var is not defined, then myMethod would be abstract and unusable
by MyClass.  Instead only subclasses of MyClass that define
instance variable var could use the myMethod.  This would mean that versions
of myMethod would need to  be compiled for each subclass that defined var.
If the additional byte code generated was considered too wasteful then
one could always use regular message sends.
I would strongly recommend that  abstract variables (such as var) and abstract
methods somehow be clearly marked.
I would also recommend that, when var is defined in a subclass,  symbol  @ be
placed in front of it to flag that an abstract variable is being made concrete
as opposed to a brand new instance variable being created.

(calm) opinions welcome.

Ralph Boland


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Instance variable access in superclasses.

David Zmick
i like that idea.  if i ever manage to make up my own smalltalk, or my own language, that will defiantly by considered in making it.
David Zmick
/dz0004455\
http://david-zmick.co.cc


On Thu, Nov 27, 2008 at 11:08 PM, Ralph Boland <[hidden email]> wrote:
My idea here is too late for squeak but is food for thought
for the next great object oriented programming language.

Instead of using a full fledged message send for accessing
instance variables we could  use a compromise. 

Lets say that symbol  @  is special and cannot be used as a regular message
and let  var be an instance variable of a class MyClass and  used in MyClass
method myMethod.

Then to access var in myMethod we can write:

       @ var.

as in:

      ^ @ var

or even:

      @ var := 5.

With this notation local variables and instance variable are distinguishable
which results in safer and (arguably) more readable code.


One way of implementing this would be to require that MyClass
define  instance variable var or an error message would be generated.

The other way of  doing this would be to not require that MyClass define var.  However, if  var is not defined, then myMethod would be abstract and unusable
by MyClass.  Instead only subclasses of MyClass that define
instance variable var could use the myMethod.  This would mean that versions
of myMethod would need to  be compiled for each subclass that defined var.
If the additional byte code generated was considered too wasteful then
one could always use regular message sends.
I would strongly recommend that  abstract variables (such as var) and abstract
methods somehow be clearly marked.
I would also recommend that, when var is defined in a subclass,  symbol  @ be
placed in front of it to flag that an abstract variable is being made concrete
as opposed to a brand new instance variable being created.

(calm) opinions welcome.

Ralph Boland






Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Instance variable access in superclasses.

Igor Stasenko
In reply to this post by Ralph Boland
2008/11/28 Ralph Boland <[hidden email]>:

> My idea here is too late for squeak but is food for thought
> for the next great object oriented programming language.
>
> Instead of using a full fledged message send for accessing
> instance variables we could  use a compromise.
>
> Lets say that symbol  @  is special and cannot be used as a regular message
> and let  var be an instance variable of a class MyClass and  used in MyClass
> method myMethod.
>
> Then to access var in myMethod we can write:
>
>        @ var.
>
> as in:
>
>       ^ @ var
>
> or even:
>
>       @ var := 5.
>
> With this notation local variables and instance variable are distinguishable
> which results in safer and (arguably) more readable code.
>
>
> One way of implementing this would be to require that MyClass
> define  instance variable var or an error message would be generated.
>
> The other way of  doing this would be to not require that MyClass define
> var.  However, if  var is not defined, then myMethod would be abstract and
> unusable
> by MyClass.  Instead only subclasses of MyClass that define
> instance variable var could use the myMethod.  This would mean that versions
> of myMethod would need to  be compiled for each subclass that defined var.
> If the additional byte code generated was considered too wasteful then
> one could always use regular message sends.
> I would strongly recommend that  abstract variables (such as var) and
> abstract
> methods somehow be clearly marked.
> I would also recommend that, when var is defined in a subclass,  symbol  @
> be
> placed in front of it to flag that an abstract variable is being made
> concrete
> as opposed to a brand new instance variable being created.
>
> (calm) opinions welcome.
>
i could imagine that in this case, class can define an abstactVarsMapping
in a form:

'@varname = ivarname , @varname2 = #accessor'

so compiler could use this information when dealing with methods you described.

Too bad, it involves even more activity of compiler during development:
now each time you changing a method in superclass, you need to go
through all subclasses and recompile their versions as well.

To my eyes, this trade off (including memory needed to keep multiple
versions of same method) outweights possible benefits.

> Ralph Boland
>

--
Best regards,
Igor Stasenko AKA sig.