About getting HashedCollection (another dream happening)

igor

peter snippets was just a dull example. Peter mentioned that some people fix consequences instead of causes....


Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Mon, 12 Apr 2010, Peter Hugosson-Miller wrote:

<snip>
>
> Sig, I agree with you! My example was of some code that would not survive
> the transition: using a asSet as a cheap way to get rid of the *possible*
> nils in a collection.

(ab)using asSet this way is bad practive (if it works at all in VA).
#(1 2 3 4 nil 6 7 nil) reject: #isNil and
#(1 2 3 4 nil 6 7 nil) select: #notNil (or the corresponding versions with
block arguments) are the way to do it.


Levente

>
> In fact, I think I'm going to take a look at our code and do something about
> it now, just in case... Thanks for the heads-up
>
> --
> Cheers,
> Peter
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Apr 12, 2010, at 5:33 42PM, Stéphane Ducasse wrote:

> igor
>
> peter snippets was just a dull example. Peter mentioned that some people fix consequences instead of causes....
>
>
> Stef

Or their application may have different expectations for what methods are ok to return collections with duplicated/nils in them.

In which case (in VW)

mySourcesWithoutNilsOrDuplicates
|myColl|

myColl := List new.
myColl addAll: self aSourceWithNils.
myColl addAll self aSourceWithDuplicates.
^myColl asSet

might have been an entirely legit use, which is sure to cause headaches if ported to a dialect which allows nils.

Not that that's a common occurrence, or something we should account for, just sayin'

Cheers,
Henry


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Peter mentioned VA, whose Set's swallow nil's.  Perhaps that's the
missing link in the communication here.  Igor is talking about
*Squeak*, which does not swallow nil's, it throws an error.

So, to "fix consequences instead of causes" in the case of Squeak, the
software would have to be doing something like:

  [ #(1 2 3 nil) asSet ]
    on: Error
    do: [ : err | "ignore it!" ]

which, deserves to break if it exists at all..

On Mon, Apr 12, 2010 at 10:33 AM, Stéphane Ducasse
<[hidden email]> wrote:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Tue, 13 Apr 2010, Chris Muller wrote:

> Peter mentioned VA, whose Set's swallow nil's.  Perhaps that's the
missing link in the communication here.  Igor is talking about
*Squeak*, which does not swallow nil's, it throws an error.

So, to "fix consequences instead of causes" in the case of Squeak, the
software would have to be doing something like:

   [ #(1 2 3 nil) asSet ]
     on: Error
     do: [ : err | "ignore it!" ]

which, deserves to break if it exists at all..


Squeak doesn't raise an error, but adds nil to the set (since 4.1), so
there's no need for such tricks. If you want to ignore nils, just #reject:
or #remove: them.


Levente

On Mon, Apr 12, 2010 at 10:33 AM, Stéphane Ducasse
<[hidden email]> wrote: _______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project