Re: Creating collections - dynamic list operator - braces

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Creating collections - dynamic list operator - braces

David Simmons
"Costas Menico" <[hidden email]> wrote in message
news:[hidden email]...

> I am trying to find an easier way to express the following construct
> example:
>
> arr := OrderedCollection new add: user;
> add: password;
> add:  level;
> add: 100;
> add #system1;
> add: Date today;
> add: #(#read #write);
> yourself.
>
> I was hoping there could be something similar to:
>
> arr := #(user password level 100 #system1 (Date today)  #(#read
> #write) )  asValues.

If you're Smalltalk supports the dynamic list operator defined from QKS
Smalltalk then this operation becomes:

    arr := {user. password. level. 100. #system1. Date today. #(read
write)}.
OR
    arr := {user, password, level, 100, #system1, Date today, #(read
write)}.

I believe that there are one or two other dialects that adopted our
definition of braces as a dynamic list operator {...}. I'm pretty sure
sqeuak has it and I think Dolphin may have it.  I believe it should be
moderately easy for someone to add this feature to Cincom Smalltalk because
it has an open compiler architecture.

>
> Costas

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."


Reply | Threaded
Open this post in threaded view
|

Re: Creating collections - dynamic list operator - braces

Andy Bower
Costas,

> > I am trying to find an easier way to express the following construct
> > example:
> >
> > arr := OrderedCollection new add: user;
> > add: password;
> > add:  level;
> > add: 100;
> > add #system1;
> > add: Date today;
> > add: #(#read #write);
> > yourself.
> >
> > I was hoping there could be something similar to:
> >
> > arr := #(user password level 100 #system1 (Date today)  #(#read
> > #write) )  asValues.

No, but you can always use the ##() compile time evaluation construct in
Dolphin to allow the collection to be constructed once by the compiler
rather than at runtime.

arr := ##(OrderedCollection new add: user;
    add: password;
    add:  level;
    add: 100;
    add #system1;
    add: Date today;
    add: #(#read #write);
    yourself)

Best Regards

Andy Bower
Dolphin Support
http://www.object-arts.com/Support.htm

Not all Addictions are Bad for you
http://www.object-arts.com/Addiction.htm


Reply | Threaded
Open this post in threaded view
|

Re: Creating collections - dynamic list operator - braces

Costas Menico-2
"Andy Bower" <[hidden email]> wrote:

Andy,

>> >
>> > arr := #(user password level 100 #system1 (Date today)  #(#read
>> > #write) )  asValues.
>
>No, but you can always use the ##() compile time evaluation construct in
>Dolphin to allow the collection to be constructed once by the compiler
>rather than at runtime.
>
>arr := ##(OrderedCollection new add: user;
>    add: password;
>    add:  level;
>    add: 100;
>    add #system1;
>    add: Date today;
>    add: #(#read #write);
>    yourself)
>

The above is powerful but I don't see how this helps in what I was
asking. I am simply looking for a quicker (as in typing and
readability) way to create a collection. Squeak has exactly what I am
looking for but of course does not exist in Dolphin.

Squeak Example:

a :='12'.
b := 1.
arr := {a. b. 1. 2.  #(1 2). Date today.}

In this case Squak creates an Array object.

It would be very useful if you could add something similar. It looks
to me that BlockClosure could actually do this by sending it a message
similar to #value but will answer an array of each statement's result.

Example:
arr := [a. b. 1. 2.  #(1 2). Date today.] arrayValues.

Why... you could even pass parameters to it:

arr := [:aString | a. b. 1. 2.  #(1 2). Date today. aString]
arrayValues: 'Hi'.

Regards,

Costas


Reply | Threaded
Open this post in threaded view
|

Re: Creating collections - dynamic list operator - braces

Ian Upright
In reply to this post by David Simmons
"David Simmons" <[hidden email]> wrote:

>If you're Smalltalk supports the dynamic list operator defined from QKS
>Smalltalk then this operation becomes:
>
>    arr := {user. password. level. 100. #system1. Date today. #(read
>write)}.
>OR
>    arr := {user, password, level, 100, #system1, Date today, #(read
>write)}.

This brings back memories of everyone having different formatting styles.
Then we write fancy text editors/browsers to automatically convert one
programmer's formatting style to another, so when we browse it, we read the
code in the way we are used to seeing it.  Then everybody gives up and they
write a book called Smalltalk with Style which attempts to standardize some
of the formatting and conventions so that we all are more compatible with
each other, and we standardize on one way, so that one programmer's code
isn't vastly different than another.  Given all this, when you've got a
language feature that is six one and a half a dozen the other, with my
crazed idealist view, I think it's better to just pick one rather than
writing standardization books or creating a fancy editor to automatically
convert one convention into the other, depending on the programmer's
preference!  :-)  Personally I prefer the periods, as it seems to read more
like Smalltalk to me.  Also could one use the #, message in defining an
Array.  Like:

   arry := { (firstname, space, lastname). Date today. #100. (#my, #Symbol)
}.

If so,

   arry := { (firstname, space, lastname), Date today, #100, (#my, #Symbol)
}.

Seems more confusing to me, especially to new programmers, as in once case
the comma is a message and in the other case the comma indicates
termination.  A period is never a message so thats why it seems like the
logical choice.

Ian


Reply | Threaded
Open this post in threaded view
|

Re: Creating collections - dynamic list operator - braces

David Simmons
"Ian Upright" <[hidden email]> wrote in message
news:[hidden email]...

> "David Simmons" <[hidden email]> wrote:
>
> >If you're Smalltalk supports the dynamic list operator defined from QKS
> >Smalltalk then this operation becomes:
> >
> >    arr := {user. password. level. 100. #system1. Date today. #(read
> >write)}.
> >OR
> >    arr := {user, password, level, 100, #system1, Date today, #(read
> >write)}.
>
> This brings back memories of everyone having different formatting styles.
> Then we write fancy text editors/browsers to automatically convert one
> programmer's formatting style to another, so when we browse it, we read
the
> code in the way we are used to seeing it.  Then everybody gives up and
they
> write a book called Smalltalk with Style which attempts to standardize
some
> of the formatting and conventions so that we all are more compatible with
> each other, and we standardize on one way, so that one programmer's code
> isn't vastly different than another.  Given all this, when you've got a
> language feature that is six one and a half a dozen the other, with my
> crazed idealist view, I think it's better to just pick one rather than
> writing standardization books or creating a fancy editor to automatically
> convert one convention into the other, depending on the programmer's
> preference!  :-)  Personally I prefer the periods, as it seems to read
more
> like Smalltalk to me.  Also could one use the #, message in defining an
> Array.  Like:
>
>    arry := { (firstname, space, lastname). Date today. #100. (#my,
#Symbol)
> }.
>
> If so,
>
>    arry := { (firstname, space, lastname), Date today, #100, (#my,
#Symbol)
> }.
>
> Seems more confusing to me, especially to new programmers, as in once case
> the comma is a message and in the other case the comma indicates
> termination.  A period is never a message so thats why it seems like the
> logical choice.

Hmm, sigh, I agree in my heart of hearts. It is the same
logic/thought-process I went through when I originally designed it. It is
the same argument I gave when people asked for a "," syntax in the early
years.

It was not until SmallScript that I was willing to change it. Primarily
because SmallScript has many extensions to allow a non-smalltalker to
leverage their familiar/other-language constructs and avoid Smalltalk
syntax/rules if-and-until they are ready to be a real smalltalker.

Only time will tell which if any of these extensions to SmallScript should
become deprecated. The current SmallScript compiler design is intended to
make it pretty easy to use it for rewriting code that contains "deprecated"
forms.

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

>
> Ian
>