On Wed, 29 Aug 2007 22:55:39 -0700, Yoshiki Ohshima yoshiki@squeakland.org wrote:
if these keywords messages were truly unordered and optional, we could write it in this way:
This is the way my thinking runs, though there are issues (like the possibility of creating something that changing the order gives a deceptive clue to the semantic meaning). But say we have a method with three parms, we may end up with routines like so (ignore the punctuation here, I'm throwing out ideas that have come from my attempts at designing a language):
aMethod with: and: plus:
where the parameters are optional, we end up with routines like:
aMethod withParm1: aParm1 aMethod with: aParm and: defaultParm2 plus: defaultParm3
aMethod withParm2: aParm2 aMethod with: defaultParm1 and: aParm2 plus: defaultParm3
aMethod withParm1: aParm1 andParm3: aParm3 aMethod with: defaultParm1 and: defaultParm2 plus: aParm3
versus a single method where optional parameters are noted in some fashion:
aMethod [with: aParm1] [and: aParm2] [plus: aParm3] aParm1 unassigned: defaultParm1. aParm2 unassigned: defaultParm2. aParm3 unassigned: defaultParm3.
Square brackets borrowed from grep to mean "optional parameter" with the unassigned method of course meaning "if not nil then assign this value".
And then there's and:and:and:and versus:
and: *block self ifFalse: [^false]. block do: [value | ifFalse: [^false]]. ^true.
which could be called the same way as "and:and:and:and:" only with no limit on the number of "and"s, and with only one method to do so.
And how about a keyword/keywords without parameters, i.e., values that have meaning just by being specified?
switch [on]
or select many/select one-type lists:
switch [on|off|flip] fire [red,green,blue]
These were ideas that I came up with while trying to make things even more "natural". I don't know all the ramigications of such changes (although it'd clean up the Boolean class), but these discussions have encouraged me to experiment.