pipe

Blake blake at kingdomrpg.com
Thu Aug 30 08:15:48 UTC 2007


On Wed, 29 Aug 2007 22:55:39 -0700, Yoshiki Ohshima  
<yoshiki at 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.



More information about the Squeak-dev mailing list