2008/11/28 Ralph Boland <rpboland at gmail.com>:
> 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.