Pool dictionary entries and array shorthand

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

Pool dictionary entries and array shorthand

Louis LaBrunda
Hi,

I'm sure we have all used the array creation shorthand: #(5 4 3 2 1).  When
trying to create an array with elements of a pool dictionary like:
#(BlueWool LimeWool) one ends up with an array of the symbolic names of the
pool dictionary entries and not their values: #(#BlueWool #LimeWool).

IMHO this is almost useless.  If I wanted the symbols in an array I would
just use: #(#BlueWool #LimeWool) which looks like what was wanted and isn't
much more to type.  I think the values is what one would expect from:
#(BlueWool LimeWool) and not the symbols and I don't see any other
shorthand way to get them.

VA Smalltalk works the same way.  I don't know about any other Smalltalk.
Both Smalltalks pretty print it the same way they do with any other pool
dictionary usage.

I don't want to go so far as to call this a bug but I'm close.  I don't see
why one would want it to work this way and I can see great value in
building the array with the pool values.  Can we get this changed?  Does
anyone depend on the current implementation?

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com


Reply | Threaded
Open this post in threaded view
|

Re: Pool dictionary entries and array shorthand

Frank Shearar-3
On 5 March 2013 19:17, Louis LaBrunda <[hidden email]> wrote:

> Hi,
>
> I'm sure we have all used the array creation shorthand: #(5 4 3 2 1).  When
> trying to create an array with elements of a pool dictionary like:
> #(BlueWool LimeWool) one ends up with an array of the symbolic names of the
> pool dictionary entries and not their values: #(#BlueWool #LimeWool).
>
> IMHO this is almost useless.  If I wanted the symbols in an array I would
> just use: #(#BlueWool #LimeWool) which looks like what was wanted and isn't
> much more to type.  I think the values is what one would expect from:
> #(BlueWool LimeWool) and not the symbols and I don't see any other
> shorthand way to get them.

a := 1.
b := 2.
{a. b.} == Array with: a with: b

#() array literals have their uses because they're _compile-time_
calculated. A method that uses them won't pay the cost of creating the
array on every invocation.

frank

> VA Smalltalk works the same way.  I don't know about any other Smalltalk.
> Both Smalltalks pretty print it the same way they do with any other pool
> dictionary usage.
>
> I don't want to go so far as to call this a bug but I'm close.  I don't see
> why one would want it to work this way and I can see great value in
> building the array with the pool values.  Can we get this changed?  Does
> anyone depend on the current implementation?
>
> Lou
> -----------------------------------------------------------
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
> mailto:[hidden email] http://www.Keystone-Software.com
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pool dictionary entries and array shorthand

Bob Arning-2
In reply to this post by Louis LaBrunda
The thing to remember is that #() is a literal array - the contents do not depend on the state of the system when you write the expression. If you want to include non-literal values, you can use braces

{BlueWool. LimeWool}

Cheers,
Bob

On 3/5/13 2:17 PM, Louis LaBrunda wrote:
Hi,

I'm sure we have all used the array creation shorthand: #(5 4 3 2 1).  When
trying to create an array with elements of a pool dictionary like:
#(BlueWool LimeWool) one ends up with an array of the symbolic names of the
pool dictionary entries and not their values: #(#BlueWool #LimeWool).

IMHO this is almost useless.  If I wanted the symbols in an array I would
just use: #(#BlueWool #LimeWool) which looks like what was wanted and isn't
much more to type.  I think the values is what one would expect from:
#(BlueWool LimeWool) and not the symbols and I don't see any other
shorthand way to get them.

VA Smalltalk works the same way.  I don't know about any other Smalltalk.
Both Smalltalks pretty print it the same way they do with any other pool
dictionary usage.

I don't want to go so far as to call this a bug but I'm close.  I don't see
why one would want it to work this way and I can see great value in
building the array with the pool values.  Can we get this changed?  Does
anyone depend on the current implementation?

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
[hidden email] http://www.Keystone-Software.com






Reply | Threaded
Open this post in threaded view
|

Pool dictionary entries and array shorthand

Louis LaBrunda
Thanks Bob and Frank,

I thought I had tried: {BlueWool. LimeWool} but must have done something
wrong and then just posted about #().

Lou

>The thing to remember is that #() is a literal array - the contents do
>not depend on the state of the system when you write the expression. If
>you want to include non-literal values, you can use braces
>
>{BlueWool. LimeWool}
>
>Cheers,
>Bob
>
>On 3/5/13 2:17 PM, Louis LaBrunda wrote:
>> Hi,
>>
>> I'm sure we have all used the array creation shorthand: #(5 4 3 2 1).  When
>> trying to create an array with elements of a pool dictionary like:
>> #(BlueWool LimeWool) one ends up with an array of the symbolic names of the
>> pool dictionary entries and not their values: #(#BlueWool #LimeWool).
>>
>> IMHO this is almost useless.  If I wanted the symbols in an array I would
>> just use: #(#BlueWool #LimeWool) which looks like what was wanted and isn't
>> much more to type.  I think the values is what one would expect from:
>> #(BlueWool LimeWool) and not the symbols and I don't see any other
>> shorthand way to get them.
>>
>> VA Smalltalk works the same way.  I don't know about any other Smalltalk.
>> Both Smalltalks pretty print it the same way they do with any other pool
>> dictionary usage.
>>
>> I don't want to go so far as to call this a bug but I'm close.  I don't see
>> why one would want it to work this way and I can see great value in
>> building the array with the pool values.  Can we get this changed?  Does
>> anyone depend on the current implementation?
>>
>> Lou
>> -----------------------------------------------------------
>> Louis LaBrunda
>> Keystone Software Corp.
>> SkypeMe callto://PhotonDemon
>> mailto:[hidden email] http://www.Keystone-Software.com
>>
>>
>>
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com