@James Foster: 100%. There are no exceptions. @John Pferisch: the GNU Smalltalk web site hosted an attempt to update the ANSI standard for a while. I was on the mailing list. I had to be away from it for a bit and when I came back wanting to upload my contribution it had all gone. There *is* a lot that is already shared or could be shared at low cost, but trawling through Smalltalks is pretty labour- intensive so such a project needs money. We are still seeing crazy date & time classes and even Complex classes purporting to inherit Magnitude.
On 1 August 2018 at 02:05, James Foster <smallt...@jgfoster.net> wrote: > To what extent is it required by ANSI that objects be of the same class? > Does Pharo treat a String and a Symbol as equivalent if they have the same > characters? > > James > > > On Jul 30, 2018, at 10:59 PM, Richard O'Keefe <rao...@gmail.com> wrote: > > I do not think that (1 to: 4) and #(1 2 3 4) should be equal. > Let me put it a little more strongly: it's a bug. > Taking > a := 1 to: 4. > b := Array withAll: a. > c := OrderedCollection withAll: b. > in the two other Smalltalk systems I just tried, > no two of these are equal. This is what the ANSI > Smalltalk standard requires. Ceteris paribus, > two sequences are equivalent if and only if > 1. they are instance of the same class > 2. they have the same size > 3. corresponding elements are equivalent. > It is fairly common for Smalltalk systems to distinguish > between "these sequences are equivalent" and "these > sequences have the same elements in the same order", > with no consensus on the name of the second method. > One calls it #sameContentsAs:, Squeak #hasEqualElements:. > > > On 31 July 2018 at 00:07, werner kassens <wkass...@libello.com> wrote: > >> Hi, >> i guess i can subsume almost everything i know about hashes in one >> sentence: >> it is my understanding that two objects that are equal (obj1=obj2. >> -->true) have to have the same hash value (which is used for some >> collection types), whereas objects where obj1=obj2 returns false should >> have different hash values although it may happen that they have the >> same one. >> >> now here things don't turn out exactly like that: >> (1 to:4) = #(1 2 3 4). "true" >> (1 to:4)hash = #(1 2 3 4)hash. "false" >> well ok, actually these results make - pfffh, in a certain way - sense >> to me, but i wonder what arguments the people in the know would use to >> defend that result, if i would have another opinion? >> werner >> >> >> > >
