A provocative naming idea for "setter" methods

[Brian T. Rice]

Diego Fernandez <diegof79 at gmail.com> said:

> I'm new to Slate and from the point of view of an Smalltalker, the
Slate 
> syntax look very complicated now. 

Welcome! I'm sorry you feel that way; the Slate grammar is formally
more regular and machine-processable than Smalltalk-80's. The @
syntax is not ideal, but eventually we want to leave the
ASCII-limitations behind when the UI and IDE are ready.

> I think that this complexity problem is worse than the problem you
have 
> mentioned.

Please explain the specifics of this. You should bring this up when
you first learn it so I can understand what bothers people and
document it, say, on the wiki, so I can address it without guessing.

There is also a Smalltalk-80 vs. Slate page that is ready for
extension already:
http://slate.tunes.org/wiki/Changes_from_Smalltalk-80

There is one initial important example, that whitespace separators
and lack thereof are taken literally by the Slate grammar, not
loosely as in Smalltalk-80. This is a bit of a pain in a plain
text-editor, but is meant to give freedom in the kind of names given
to things. Eventually this can be understood and used to make
code-reading less ambiguous.

> Why just don't use categories to avoid confusion? 
> If you have a "handle:" setter, use a proper method categorization
(like 
> "accessing"). 
> I think that this simple solution is enough to avoid confusion.

I'm sorry, but you missed my point about how this works. The
/sender/ of the message is who gets confused, not the receiver.
Without perfect type inference, you won't know what method
implements a given message, so its method category is unavailable.
Do you see the problem? I'd rather have the intention in the name
than just in the implementation (or its annotations).

> If you want to create tools that handle mutators methods in a
special way,
> you can easily add some kind of meta data to each method without
changing
> the language syntax.

Again, the sender of the message won't see that meta-data until it
infers the correct type. This also gets a little too close to
breaking encapsulation, to have to know too much at compile-time to
understand what will happen at run-time. Putting the information
that "this sets something" vs. "this acts on the arguments with this
verb" is not breaking encapsulation, it's revealing information that
makes code clearer.

Also, we haven't changed the syntax much other than allow for ways
of expressing things that Smalltalk-80 doesn't allow for legacy
reasons. Don't pretend that Smalltalk-80 isn't shaped by legacy -
there's a large amount of that going around, and very little
discussion about why things are the way they are for that reason.
Slate exists to make a Smalltalk that is as generic as possible
without reference to any of that.

In the example at hand, we simply allowed alphanumerics to show up
in binary selectors as long as they are begun by ordinary binary
selector elements. We're not sure how we'll eventually use this, but
if we put in that Smalltalk-80 restriction, we'd never know what we
wouldn't have. And a good editor with incremental parser can always
tell you as you type (or when you pause for a moment) how your
content appears to the language grammar (see Shout for the Squeak
IDE). Sure, we don't have this, but you don't judge Smalltalk-80
code by how it looks in FileOuts, either!

--
-Brian