A provocative naming idea for "setter" methods

[Brian Rice]

On Sep 23, 2005, at 4:12 AM, Rastislav Kassak wrote:

> Even more provocative idea:
>
> Brian, you are familiar with this blog post
> http://www.cincomsmalltalk.com/userblogs/mls/blogView? 
> showComments=true&title=Language+Evolution&entry=3295244449

Yes, I commented it on my Slate blog:
http://cincomsmalltalk.com/userblogs/slate/blogView? 
showComments=true&entry=3296059325

> I've found it today. One of the discussed inprovements in Smalltalk
> was automatic creation of instance variables.
> You has opposed against that idea as there is trouble with message not
> understand exception vs. automatic slot creation.
> What do you think about it when we are going to have different syntax
> for setter methods? Could it be possible to automaticaly create slot
> only if unknown setter method has been invoked? Simply exception
> handler will call #addSlot:valued:.

Why should I change my mind just because we change a naming  
convention? :)

At least give me some reasoned argument. Even with an assignment- 
style naming convention for messages, it is still not unambiguous  
what assignment should mean when a random object receives this idiom.  
After all, the sender may want one of those view-wrapper objects  
instead of what he got, so adding the slot would be "deceptive" as a  
dynamic implementation of the method. So I would still want an  
exception, even if it were a specialized "hey, it looks like  
someone's trying to assign something here, but there's no place for  
it" exception (which sounds good if I can figure out a good new  
implementation of the defaultHandler that does this).

> This reminds me some another newbie question.
> I will again show example in Ruby. I'm no Ruby zealot, just beginner,
> bud I really like some concepts.
> Lazy cached evaluation (maybe it has some better name :)) is really
> concise in Ruby. Just define getter method this way:
> def someProperty
>   @someProperty ||= evaluateSomeProperty
> end
> Fisrt time, it is called, @someProperty (instance variable) evaluates
> to Nil, as there is no such variable defined. Therefore ||= operator
> start evaluation of expression on right side, and stores result in
> @someProperty and returns it.

"No such variable defined" is not the same as "a variable defined but  
not set to any object". The first is a condition, the latter is where  
you would use Nil.

||= is the same as "foo ifNil: [foo: evaluateSomeProperty]" which we  
might provide a macro for. Someone has suggested `<< - even so, so  
far it only works for block locals (useful for optional argument  
default values) as "foo: (foo ifNil: [evaluateSomeProperty]). / 
Again/, the "assignment-futzing" nature of other languages is >>>meta- 
syntactic<<< and not just another message form. This is why Ruby and  
less-object-y languages are missing the point when they claim to be  
object-oriented because they're only made of objects: they're missing  
the other part where you know which operations syntactically are  
messages and which are syntactic sugar-coating which actually reaches  
over the top of the OOP idea and imposes old-style L-value thinking.

In Slate, you would need to provide a "foo||=" message /not/ on foo,  
but on the object with the slot named foo.

> Next time this getter method is called, @someProperty is already
> defined and contains previously evaluated data, so right expresion
> doesn't need to be evaluated second time.

Right, I've used it in a lot of Smalltalk programs - it's an old  
pattern from the early 90's.

> This pattern is quite common, at least we use it in our projects.
> What's the best way to make this work in Slate? Is there (could be)
> some @addLazySlot:[#name]valued:[evaluation block]?

There IS addLazySlot: #name initializer: block in root.slate! It  
looks like you didn't bother to do a basic grep of Slate sources. ;)  
Actually, it's worth reading because it uses the accessor/mutator API  
directly.

(Aside: now I realize that you didn't want the above ruby behavior  
for "arbitrary slots", but "chosen slots", so you can mostly ignore  
my rant above and consider it from that perspective. Oops. :) )

> I think it is very helpful and maybe some top level implementation is
> quite easy.
>
> What do you think?

Of course I like it, I already implemented it. :)

--
-Brian