May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Is it always needed to redefine #hash message when you redefine #= message?

by Julien Delplanque

Thanks, I understand now :) On 26/05/15 21:06, Carlo wrote: > Hi > > Any two objects that are = must answer the same #hash value. > The hash is used in any of the HashedCollection's for storage and then to find the exact element the #= is used. > If 2 objects are #= but their hash values are different the HashedCollection will not find the correct storage slot and you will have undefined behaviour when looking up objects. > > Out of interest, Andres Valloud wrote a whole book on 'Hashing in Smalltalk' (http://www.lulu.com/content/1455536) > > Also the Javadoc comments are pretty good in explaining the usage: >> The general contract of hashCode is: >> Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application. >> If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result. >> It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables. >> As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. > Cheers > Carlo > > On 26 May 2015, at 8:45 PM, Julien Delplanque <julien(a)tamere.eu> wrote: > > The subject of this mail is exactly my question. > > I came to this question by looking at Object>>#= message implementation. > > """ > = anObject > "Answer whether the receiver and the argument represent the same > object. If = is redefined in any subclass, consider also redefining the > message hash." > > ^self == anObject > """ > > When do we need to redefine #hash message? > > Is it the right way to implement equality between two objects or is there another message that I should override? > > Regards, > Julien > > >

May 26, 2015

Re: [Pharo-users] How to update to Pharo 5 in Ubuntu 14.04 ?

by Markus Fritsche

On 26.05.2015 11:23, Dimitris Chloupis wrote: > I have tried to use sudo apt-get update , but when i open > pharolauncher using the pharo command in the terminal i see no option > to download a pharo 5 image, Any clue how I can update it ? Hello Dimitris, Damien was so kind to forward your mail - I updated the pharo-launcher package, an apt-get upgrade should install the new package.

May 26, 2015

Re: [Pharo-users] Is it always needed to redefine #hash message when you redefine #= message?

by Carlo

Hi Any two objects that are = must answer the same #hash value. The hash is used in any of the HashedCollection's for storage and then to find the exact element the #= is used. If 2 objects are #= but their hash values are different the HashedCollection will not find the correct storage slot and you will have undefined behaviour when looking up objects. Out of interest, Andres Valloud wrote a whole book on 'Hashing in Smalltalk' (http://www.lulu.com/content/1455536) Also the Javadoc comments are pretty good in explaining the usage: > The general contract of hashCode is: > Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application. > If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result. > It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables. > As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. Cheers Carlo On 26 May 2015, at 8:45 PM, Julien Delplanque <julien(a)tamere.eu> wrote: The subject of this mail is exactly my question. I came to this question by looking at Object>>#= message implementation. """ = anObject "Answer whether the receiver and the argument represent the same object. If = is redefined in any subclass, consider also redefining the message hash." ^self == anObject """ When do we need to redefine #hash message? Is it the right way to implement equality between two objects or is there another message that I should override? Regards, Julien

May 26, 2015

Re: [Pharo-users] Is it always needed to redefine #hash message when you redefine #= message?

by Julien Delplanque

Mmmh, Let's assume I have a Letter object. This object have a body (String) and a title (also a String). I want to define that two Letter objects are equals if and only if theirs bodies are equals and theirs titles are equals. How do I implement it? I don't understand why I should override #hash in this case? Julien On 26/05/15 20:54, Esteban A. Maringolo wrote: > 2015-05-26 15:45 GMT-03:00 Julien Delplanque <julien(a)tamere.eu>: >> The subject of this mail is exactly my question. >> >> I came to this question by looking at Object>>#= message implementation. >> >> """ >> = anObject >> "Answer whether the receiver and the argument represent the same >> object. If = is redefined in any subclass, consider also redefining the >> message hash." >> >> ^self == anObject >> """ >> >> When do we need to redefine #hash message? > Whenever you redefine #=. > >> Is it the right way to implement equality between two objects or is there >> another message that I should override? > #hash, as per the #= suggests. > > Hashed collections (Set mainly, but there are others) index and lookup > objects by its hash value. > > Esteban A. Maringolo > > ps: The proper implementation of #hash to avoid collisions (two > different objects sharing the same hash) can be plain simple or a > little more complex (mathematically challenging). >

May 26, 2015

Re: [Pharo-users] Is it always needed to redefine #hash message when you redefine #= message?

by Esteban A. Maringolo

2015-05-26 15:45 GMT-03:00 Julien Delplanque <julien(a)tamere.eu>: > The subject of this mail is exactly my question. > > I came to this question by looking at Object>>#= message implementation. > > """ > = anObject > "Answer whether the receiver and the argument represent the same > object. If = is redefined in any subclass, consider also redefining the > message hash." > > ^self == anObject > """ > > When do we need to redefine #hash message? Whenever you redefine #=. > Is it the right way to implement equality between two objects or is there > another message that I should override? #hash, as per the #= suggests. Hashed collections (Set mainly, but there are others) index and lookup objects by its hash value. Esteban A. Maringolo ps: The proper implementation of #hash to avoid collisions (two different objects sharing the same hash) can be plain simple or a little more complex (mathematically challenging).

May 26, 2015

Re: [Pharo-users] Is it always needed to redefine #hash message when you redefine #= message?

by Cyril Ferlicot

I think you redefine hash to allow a Set to know if two objects are the same or not. So it's not an equals but it's a way for a Set to know if an equivalent element is already on a Set or not. Correct me if i'm wrong. On 26 May 2015 at 20:45, Julien Delplanque <julien(a)tamere.eu> wrote: > The subject of this mail is exactly my question. > > I came to this question by looking at Object>>#= message implementation. > > """ > = anObject > "Answer whether the receiver and the argument represent the same > object. If = is redefined in any subclass, consider also redefining the > message hash." > > ^self == anObject > """ > > When do we need to redefine #hash message? > > Is it the right way to implement equality between two objects or is there > another message that I should override? > > Regards, > Julien > -- Cheers Cyril Ferlicot

May 26, 2015

Is it always needed to redefine #hash message when you redefine #= message?

by Julien Delplanque

The subject of this mail is exactly my question. I came to this question by looking at Object>>#= message implementation. """ = anObject "Answer whether the receiver and the argument represent the same object. If = is redefined in any subclass, consider also redefining the message hash." ^self == anObject """ When do we need to redefine #hash message? Is it the right way to implement equality between two objects or is there another message that I should override? Regards, Julien

May 26, 2015

Re: [Pharo-users] Some Pharo 4 Getting-Started tips

by Esteban A. Maringolo

2015-05-25 21:50 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Ben Coman wrote >> We should at least change the Nautilus title bar to "Nautilus System >> Browser" (or just "System Browser" ?) > The other complication is that we have jumped onto the fad now to have cool > names for all software projects which offer no guidance as to what the code > actually does - a la Ruby, Sinatra, Rails. While this mysteriousness may > generate excitement for the project, it seems far less useful once we > integrate things in the image. What does/could Nautilus mean to a new user? > Taking a cue from Mac - the core apps are called Mail, Contacts, Maps, > Notes; not Sandcastle, Cabana, SkippingStone, and Umbrella ;) At least Opal > has the word Compiler attached to it! +1 I think intention revealing names helps even the seasoned user. Regards! Esteban A. Maringolo

May 26, 2015

Re: [Pharo-users] Some Pharo 4 Getting-Started tips

by Esteban Lorenzano

> On 26 May 2015, at 19:20, Ben Coman <btc(a)openInWorld.com> wrote: > > On Wed, May 27, 2015 at 1:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> Hi, >> >>> On 26 May 2015, at 18:16, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> On Tue, May 26, 2015 at 8:50 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>> Ben Coman wrote >>>>> We should at least change the Nautilus title bar to "Nautilus System >>>>> Browser" (or just "System Browser" ?) >>>> >>>> Part of the problem is that we have overloaded system categories to package >>>> code for SCM. System categories should be tags (preferably multiple allowed) >>>> which offer a logical view of the system. Packages, the POV we show now, are >>>> orthogonal and much less useful for users. >>>> >>>> The other complication is that we have jumped onto the fad now to have cool >>>> names for all software projects which offer no guidance as to what the code >>>> actually does - a la Ruby, Sinatra, Rails. While this mysteriousness may >>>> generate excitement for the project, it seems far less useful once we >>>> integrate things in the image. What does/could Nautilus mean to a new user? >>>> Taking a cue from Mac - the core apps are called Mail, Contacts, Maps, >>>> Notes; not Sandcastle, Cabana, SkippingStone, and Umbrella ;) At least Opal >>>> has the word Compiler attached to it! >>> >>> Agreed. Also take a cue from Microsoft and their successful >>> applications (I wonder what they could possibly be uesed for?): >>> * Word >>> * SQLServer >>> * Internet Explorer >>> * Publisher >>> * Media Player >>> >>> Of course the incumbent players have the luxury of already having an >>> audience to take the dominant position on the app names. But the >>> situation is a bit the same for tools delivered by by default with the >>> standard Image. >> >> I disagree with this way. >> We are not building an OS (regardless the original intentions of smalltalk) and this profusion of names are generating more confusion than benefits, thinking on new users. >> For me, intention revealing names needs to be applied not just to the methods and classes we code, but also the tools we use. Then, fantasy names are just that, fantasy. >> In fact, I was planning a couple of sessions to get an idea of how can we do to have the system in a more clear way. Something like: >> >> - System Browser (Nautilus) >> >> then if we change it it can be >> >> - System Browser (GCoder) (Or whatever the name gtools guys are planning). >> - System Browser (AltBrowser) >> >> or whateverâ¦ same for other âmysteriousâ tools like monticello (who can know that monticello is a SCM, as a newbie?). >> A lot better: >> >> - SCM (Monticello) >> - SCM (Other) >> >> etc. >> Soâ¦ I think is better to change âNautilusâ title to âSystem Browserâ. > > The potential downside is a newcomer wanting to look look into the > System Browser implementation, and not finding a class named "System > Browser" to review. Maybe they would discover the ImplementationClass > (e.g. Nautilus) anyway by digging into the tool using halos (?). Iâm not sure I want a newcomer to look at nautilus code ;) Sarcasm aside, I get your concern but I remain thinking I have a strong point. Anyway that can be somewhere in the aboutâ¦ or we can rename it as "System Browser (Nautilus)â in the title, or something like that, we still need to work to have the best solution. Only thing is clear to me is current situation is not good at all :) > > >> >> Esteban >> >>> >>> cheers -ben

May 26, 2015

Re: [Pharo-users] Some Pharo 4 Getting-Started tips

by Ben Coman

On Wed, May 27, 2015 at 1:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > >> On 26 May 2015, at 18:16, Ben Coman <btc(a)openInWorld.com> wrote: >> >> On Tue, May 26, 2015 at 8:50 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> Ben Coman wrote >>>> We should at least change the Nautilus title bar to "Nautilus System >>>> Browser" (or just "System Browser" ?) >>> >>> Part of the problem is that we have overloaded system categories to package >>> code for SCM. System categories should be tags (preferably multiple allowed) >>> which offer a logical view of the system. Packages, the POV we show now, are >>> orthogonal and much less useful for users. >>> >>> The other complication is that we have jumped onto the fad now to have cool >>> names for all software projects which offer no guidance as to what the code >>> actually does - a la Ruby, Sinatra, Rails. While this mysteriousness may >>> generate excitement for the project, it seems far less useful once we >>> integrate things in the image. What does/could Nautilus mean to a new user? >>> Taking a cue from Mac - the core apps are called Mail, Contacts, Maps, >>> Notes; not Sandcastle, Cabana, SkippingStone, and Umbrella ;) At least Opal >>> has the word Compiler attached to it! >> >> Agreed. Also take a cue from Microsoft and their successful >> applications (I wonder what they could possibly be uesed for?): >> * Word >> * SQLServer >> * Internet Explorer >> * Publisher >> * Media Player >> >> Of course the incumbent players have the luxury of already having an >> audience to take the dominant position on the app names. But the >> situation is a bit the same for tools delivered by by default with the >> standard Image. > > I disagree with this way. > We are not building an OS (regardless the original intentions of smalltalk) and this profusion of names are generating more confusion than benefits, thinking on new users. > For me, intention revealing names needs to be applied not just to the methods and classes we code, but also the tools we use. Then, fantasy names are just that, fantasy. > In fact, I was planning a couple of sessions to get an idea of how can we do to have the system in a more clear way. Something like: > > - System Browser (Nautilus) > > then if we change it it can be > > - System Browser (GCoder) (Or whatever the name gtools guys are planning). > - System Browser (AltBrowser) > > or whateverâ¦ same for other âmysteriousâ tools like monticello (who can know that monticello is a SCM, as a newbie?). > A lot better: > > - SCM (Monticello) > - SCM (Other) > > etc. > Soâ¦ I think is better to change âNautilusâ title to âSystem Browserâ. The potential downside is a newcomer wanting to look look into the System Browser implementation, and not finding a class named "System Browser" to review. Maybe they would discover the ImplementationClass (e.g. Nautilus) anyway by digging into the tool using halos (?). > > Esteban > >> >> cheers -ben >> > >

May 26, 2015