CharacterArray class>>#lineDelimiter and Dictionary>>#addAll: both fail

This is with 2.3.3.  I noticed that #lineDelimiter fails
when sent to
the class it's defined in, CharacterArray:

    st> CharacterArray lineDelimiter!
    Object: CharacterArray new: 1
"<-0x5c60cd20>" error: Invalid
    argument : argument must be between 0 and 4294967295
   
SystemExceptions.ArgumentOutOfRange(Exception)>>#signa
l
   
SystemExceptions.ArgumentOutOfRange(Exception)>>#signa
l:
    SystemExceptions.ArgumentOutOfRange
class>>#signalOn:mustBeBetween:and:
   
CharacterArray(Object)>>#checkIndexableBounds:put:
    CharacterArray(Object)>>#at:put:
    CharacterArray class(ArrayedCollection
class)>>#with:
    CharacterArray class>>#lineDelimiter

Seeing that it works with most subclasses, I guess it makes
sense to put
the method in a common parent class, but there's no
documentation that
says "don't use this here, use with String (or other
subclass) instead".

Also, #addAll: doesn't work on Dictionaries:

    st> Smalltalk at: #a put: (Dictionary new add: 1
-> 'one'; yourself)!
    st> Smalltalk at: #b put: (Dictionary new add: 2
-> 'two'; yourself)!
    st> a addAll: b!
    Object: 'two' error: did not understand #key
    MessageNotUnderstood(Exception)>>#signal
    String(Object)>>#doesNotUnderstand:
    Dictionary>>#add:
    optimized [] in Collection>>#addAll:
    [] in Dictionary>>#do:
    Dictionary(HashedCollection)>>#do:
    Dictionary>>#do:
    Dictionary(Collection)>>#addAll:

I believe it should iterate directly over elements and not
their values.

Best,
Jānis



_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Also, #addAll: doesn't work on Dictionaries:
> 
> I believe it should iterate directly over elements and
not their values.

It should use #keysAndValuesDo:, indeed.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, 2007-03-20 at 14:54 +0100, Paolo Bonzini wrote:
> > Also, #addAll: doesn't work on Dictionaries:
> > 
> > I believe it should iterate directly over elements
and not their values.
> 
> It should use #keysAndValuesDo:, indeed.

Its current meaning lends itself to the extremely
convenient

Dictionary withAll: {#a -> 1. #b -> 2}.

as class>>withAll: is defined as something like
"self new addAll: arg".

I prefer the semantics of addAll: to definitely be "arg
do: [:each|self
add: each]", but this would change or be special-cased
if you could
addAll: aDictionary in the manner parasti speaks of.

Perhaps a new method, like addAllAssociations:, which would
be
semantically equivalent to "arg associationsDo:
[:assoc|self at: assoc
key put: assoc value]", would be more appropriate?

-- 
;;; Stephen Compall ** http://scompall.no
candysw.com/blog **
"Peta" is Greek for fifth; a petabyte is 10 to the
fifth power, as
well as fifth in line after kilo, mega, giga, and tera.
  -- Lee Gomes, performing every Wednesday in his tech
column
     "Portals" on page B1 of The Wall Street
Journal

_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Stephen Compall wrote:
> On Tue, 2007-03-20 at 14:54 +0100, Paolo Bonzini
wrote:
>>> Also, #addAll: doesn't work on Dictionaries:
>>>
>>> I believe it should iterate directly over
elements and not their values.
>> It should use #keysAndValuesDo:, indeed.
> 
> Its current meaning lends itself to the extremely
convenient
> 
> Dictionary withAll: {#a -> 1. #b -> 2}.
> 
> as class>>withAll: is defined as something like
"self new addAll: arg".
> 
> I prefer the semantics of addAll: to definitely be
"arg do: [:each|self
> add: each]", but this would change or be
special-cased if you could
> addAll: aDictionary in the manner parasti speaks of.
> 

I remember now that I was a bit surprised to discover that,
in
Dictionaries, #do: is, in fact, redefined to iterate over
values, and
not the Associations (which is what I meant by
"elements").  Removing it
would preserve the indeed useful behaviour you demonstrated
in your
example and also make it behave the way I expected.  And
probably break
something.  

Jānis


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Fri, 2007-03-23 at 02:29 +0200, Jānis Rūcis wrote:
> I remember now that I was a bit surprised to discover
that, in
> Dictionaries, #do: is, in fact, redefined to iterate
over values, and
> not the Associations (which is what I meant by
"elements").  Removing it
> would preserve the indeed useful behaviour you
demonstrated in your
> example and also make it behave the way I expected. 
And probably break
> something.  

I agree on the surprise, that changing
Dictionary>>#do:'s semantics
would be an acceptable way to get the behavior you want, and
that it
would break something.  

My suggestion for a new protocol was an attempt to carry
over the spirit
of the associationsDo:/do: relationship.

Unfortunately, this seems moot, as revealed by checking
ANSI:

5.7.2.1 Message:          addAll: dictionary
   Synopsis
       Store the elements of dictionary in the receiver at
the corresponding keys from dictionary.
   Definition: <abstractDictionary>
       This message is equivalent to repeatedly sending the
#at:put: message to the receiver with
       each of the keys and elements in dictionary in turn.
If a key in dictionary is key equivalent to
       a key in the receiver, the associated element in
dictionary replaces the element in the receiver.
   Parameters
       dictionary         <abstractDictionary>   
unspecified

ANSI seems to solve the add:/addAll: mismatch for Dictionary
by leaving
add: out of the protocol -- including the inherited
<collection>.
Furthermore, <Dictionary factory>>>#withAll: is
equivalent to its
current definition in GST, so its arg must also be an
<abstractDictionary> as implied by the above addAll:
definition.

I would suggest that addAllAssociations: have the current
behavior of
addAll:, but that would likely lead to confusion, as the
relationship
between addAll: and addAllAssociations: would be precisely
the opposite
of that between do: and associationsDo:.  On the other
hand,
associationsDo: is not even part of
<abstractDictionary>....

-- 
;;; Stephen Compall ** http://scompall.no
candysw.com/blog **
"Peta" is Greek for fifth; a petabyte is 10 to the
fifth power, as
well as fifth in line after kilo, mega, giga, and tera.
  -- Lee Gomes, performing every Wednesday in his tech
column
     "Portals" on page B1 of The Wall Street
Journal

_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Stephen Compall wrote:
> I would suggest that addAllAssociations: have the
current behavior of
> addAll:, but that would likely lead to confusion, as
the relationship
> between addAll: and addAllAssociations: would be
precisely the opposite
> of that between do: and associationsDo:.  On the other
hand,
> associationsDo: is not even part of
<abstractDictionary>....

#associationsDo: is not optimal;  it says "here's a
collection of stuff,
including associations, so lets do something to these
associations, but
not other elements", but that's not what really
happens.

Same for #do: -- if you see a Dictionary as a Collection of
Associations, being able to iterate over them with #do:
seems natural.
Likewise for being able to add a Dictionary to a Dictionary.
 And
likewise for being able to initialize a Dictionary from an
Array, or any
other Collection, of Associations.  (Including Dictionary
itself.)  All
of these things are neither confusing nor useless.  Quite
the opposite.

I don't see a reason to follow the standard so closely that
it would
make for a less useful behaviour.

Let's just remove #do: from Dictionary (say, move its
functionality to
#valuesDo and do
away with the misleading #associationsDo: (whose
functionality will be taken care of by the inherited #do.  Some
incompatibility is a very small price to pay for this.

Jānis



_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> I don't see a reason to follow the standard so closely
that it would
> make for a less useful behaviour.

Unfortunately, this is not something that I can do (nor
want,
actually).  Most of the time with Dictionaries you'd be
using
#keysAndValuesDo: anyway.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
>> I don't see a reason to follow the standard so
closely that it would
>> make for a less useful behaviour.
> 
> Unfortunately, this is not something that I can do (nor
want,
> actually).

It's a side issue.  It doesn't have the intended effect if
you take it
out of context like that.  But it was not a general
statement, anyway.
I was speaking specifically of something Stephen wrote:

> Furthermore, <Dictionary
factory>>>#withAll: is equivalent to its
> current definition in GST, so its arg must also be an
> <abstractDictionary> as implied by the above
addAll: definition.

Taken literally, the standard says "nothing but
Dictionary".  But my
point is, if a Dictionary is a Collection of Associations,
any such
Collection can be used.  This isn't a violation of standard.
 It's
interpretation.  That's what "abstract" in
"<abstractDictionary>" means.
 "If it walks like a duck and quacks like a duck,
..."

The only thing that stands in the way of that is #do:. 
Dictionary>>#do:
isn't in the standard, so compliance is not really a
problem.

Jānis


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Taken literally, the standard says "nothing but
Dictionary".  But my
> point is, if a Dictionary is a Collection of
Associations, any such
> Collection can be used.

The point is that it is not.  The standard has no mention
of
Associations at all, and that's a really good thing.

While the standard does not give any relationship between
Dictionaries and any other collection, there is only one
that is
coherent with the rest of the standard:  keyed collections
in
Smalltalk are SequenceableCollections and Dictionaries (the
keys
being integers in the case of seq. collections).  Keyed
collections
would be those that implement #keysAndValuesDo: (and if you
search
for "keyed" in the standard, you'll see what I
mean).

> This isn't a violation of standard.  It's
> interpretation.  That's what "abstract" in
"<abstractDictionary>" means.
>  "If it walks like a duck and quacks like a duck,
..."

... but then, since, #('a' 'b' 'c') implements
#keysAndValuesDo:,
"Dictionary withAll: #('a' 'b' 'c')" will give a
Dictionary with 1->'a', 2->'b', and 3->'c'.  This
also can be
seen as "If it walks like a duck and quacks like a
duck".

But the point is that the standard guys were *right* in
dropping
Associations and "#add:" from it. 
"#add:" makes no sense with
external keys, and it percolates Associations (which are an
implementation detail) to the definition of Dictionary.

One possibility could be to extend the {...} syntax to
something
like "OrderedCollection {...}", "Dictionary
{...}", and have it send
messages like "#braceWithAll:".  Then you would
have:

     Array >> braceWithAll: x
         ^self

     Collection >> braceWithAll: x
         ^self withAll: x

     Dictionary >> braceWithAll: x
         | dict |
         dict := self new: x size * 2.
         "in the loop we want 'self add: x'
maybe?"
         x do: [ :each | dict at: x key put: x value ].
         ^dict

The compiler might know of a few classes and optimize them;
or maybe not.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> The only thing that stands in the way of that is #do:. 
Dictionary>>#do:
> isn't in the standard, so compliance is not really a
problem.

Forgot replying to this part, sorry:  Dictionary>>#do:
is in the
standard.

An <abstractDictionary> is a <collection> and
the collection's
#do: is defined as this:

"For each element of the receiver, operation is
evaluated with
the element as the parameter."

and <abstractDictionary> is said to provide
"protocol for accessing,
adding, removing, and iterating over the elements of an
unordered 
collection whose elements are accessed using an explicitly
assigned
external key."  So, it's clear that the key is *not*
part of the
element, and thus not considered by #do:.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk