A provocative naming idea for "setter" methods

[Brian Rice]

Hello,

On Sep 20, 2005, at 2:48 AM, Rastislav Kassak wrote:

> I think it's quite interresting, and it could tend to something what
> paul graham calls brevity - on of the key points of language
> popularity in his article http://paulgraham.com/popular.html.

Hm, I hadn't put those two ideas together when I started; I'll think  
a little about that.

> However, as I'm only slate beginner I realized don't understand the
> mechanism of invoking slots vs methods.
> You pointed out that "A handle: B" could be understood as setting slot
> #handle or calling method #handle:.
> But as I understand it, similar trouble gets in the way with getter
> method. Does "A handle" means slot getter method, or regular method
> invoked on object A?

A regular method which would usually be a slot-update action, but is  
intended to represent some kind of assignment. The subtext here is  
that all the accessors and mutators are indeed methods that can be  
overridden like any others. There are API's in root.slate, say, for  
doing this when the slot is created.

> What happen if there are both slot #handle and methods #handle or  
> #handle:?

There's less chance of a conflict since the use of #handle as a verb  
without a direct object to act on is much less useful from a code- 
reading perspective. You /could/ make the direct object of handle: an  
optional (ie.e. "handle &thing: object") but that is an abuse of  
optionals (the non-optional optional is no such thing!). Still, the  
language itself doesn't prevent you from creating non-sensical idioms.

> Thanx for enlightenment of RTMF directions. :)
>
> PS> Although I'm computer science graduate I prefer something more
> human readable than pure theory, if is it possible. :))

Thanks, so do we! :)

> On 9/20/05, Brian Rice <water at tunes.org> wrote:
>
>> Hi all,
>>
>> Don't take this terribly seriously (I'm not hell-bent on changing
>> anything), but I thought I'd poke around at some discussion of the
>> way Slate names mutator methods (to update slot values).
>>
>> In a nutshell, what I'm talking about is that for slot #foo, #foo: is
>> the name of the method that sets it. But this makes for some
>> confusing reading sometimes. Let's say that you have a #handle slot,
>> which means you set it with handle:. But that kind of precludes you
>> wanting to express the command "A handle: B" where you want A "to
>> handle" B; you see? Nouns and verbs often look alike, so we get some
>> confusion. This is just one example, but it could multiply - it
>> complicates message-send tracing unless you have good type-inference
>> information as well.
>>
>> It would also be a little nicer to have binary-selectors used (for
>> their lower/easier precedence), since Slate allows for something that
>> Smalltalk-80 doesn't: alphanumerics inside of binary selectors. For
>> example, cross- and dot-products in Slate don't have to be dot: and
>> cross:, but can be instead <dot> and <cross>; the <> symbols at the
>> ends make it read and look like an operator (html-tag-lookalikes
>> notwithstanding). I actually made those to get an idea of being able
>> to write binary selectors that could be related to Unicode symbols
>> more clearly.
>>
>> But in this case, it'd be nice to be able to say, instead of "(A:
>> someValue) doSomethingWith: B", i could do something like "<A<
>> someValue doSomethingWith: B". Or "<A< (<B< 0)" instead of "(a: (b:
>> 0))".
>>
>> So, for posterity's sake (i.e. so everyone knows how bad my ideas are
>> sometimes ;) ), my ideas are to make mutator names like these  
>> examples:
>>
>> <A-
>> <-A-
>> <A<
>>
>> Again, there are binary selector characters on both sides to keep it
>> clear, and the lexer requires this. It's possible to modify the lexer
>> a little if we really wanted something looser like "A<", but that'd
>> take some agreement.
>>
>> Hm, well, that's it in a nutshell. I have only a vague idea what it
>> would be like to have to refactor the whole system to this new
>> method, but once done it'd be easier to undo or redo since there'd be
>> _no_ ambiguity over naming convention - the keyword confusion at work
>> again.
>>
>> Thoughts? Suggestions? Verbal beat-downs? :)
>>
>> I don't mind if no one cares too much, since I'm writing this down
>> for posterity anyway. I may turn it into a wiki page or something if
>> I just shelf the idea.
>>
>> --
>> -Brian
>>
>>
>

--
-Brian