Hi all,
for a current project, I need to compare form or sound objects with each other, but I found out that they do not override #=, so for example, we get:
Wasn't this implemented a) simply because it looked like YAGNI?
b) for design reasons? For example, should (Form extent: 1 @ 1) be equal to (ColorForm extent: 1 @ 1) or not? c) for performance reasons? I don't know if there any guidelines for implement #= (except that you need to implement #hash as well), but is an equality comparison generally allowed to be an expensive operation if two objects are equal? If two large forms have a different resolution or a different bitmap hash, comparison will be fast, but if they are equal, we will need to compare every single bit. Would this be okay or a no-go?
If implementing #= as proposed is not possible, how would you think about implementing it as a keyword message on Form, e.g. #sameAs:?
The same questions apply to the AbstractSound hierarchy, too, where I'm not sure whether two sounds being played for different duration should equal or not. For a similar discussion, see also this thread: [squeak-dev] FormInspector, or also: Text>>#= and its consequences. Best,
Christoph
Carpe Squeak!
|
Hi Christoph. Hmmm... maybe it is not straightforward to implement? Especially whether #class (or #species) should match or not. Reminds me of SequenceableCollection >> #= and #hasEqualElements:. I keep on using #hasEqualElements: in tests because I don't care about Array-vs-OrderedCollection in several places. And Form has also a non-trivial hierarchy of variations: For example, would you ignore the #depth if it is black and white anyway? Or would you break uses of Dictionaries that are virtually IdentityDictionaries because of their current keys and the missing #=? It can be hard. Maybe it needs to be maintined afterwards. So, YAGNI? :-) Best, Marcel
|
Hi Marcel,
I am sending pictures and sounds to a server that only accepts mutually different items. However, if multiple of these items are generated using the same code, e.g. Morph new imageForm, there is no chance to identify this duplicate at the moment. Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Donnerstag, 1. Oktober 2020 14:43:38 An: squeak-dev Betreff: Re: [squeak-dev] Overriding #= in Graphics and Sounds
Hi Christoph.
Hmmm... maybe it is not straightforward to implement? Especially whether #class (or #species) should match or not. Reminds me of SequenceableCollection >> #= and #hasEqualElements:. I keep on using #hasEqualElements: in tests because I don't care about
Array-vs-OrderedCollection in several places.
And Form has also a non-trivial hierarchy of variations:
For example, would you ignore the #depth if it is black and white anyway?
Or would you break uses of Dictionaries that are virtually IdentityDictionaries because of their current keys and the missing #=?
It can be hard. Maybe it needs to be maintined afterwards. So, YAGNI? :-)
Best,
Marcel
Carpe Squeak!
|
Hello Christoph
I think implementing a method such as Form>>sameAs: you mentioned in the mail starting the thread to be a good solution. And the implementation is not complex http://wiki.squeak.org/squeak/2852 Regards Hannes On 10/1/20, Thiede, Christoph <[hidden email]> wrote: > Hi Marcel, > > > I am sending pictures and sounds to a server that only accepts mutually > different items. However, if multiple of these items are generated using the > same code, e.g. Morph new imageForm, there is no chance to identify this > duplicate at the moment. > > <http://www.hpi.de/> > > Thanks for the hints, this sounds indeed too complex for my use case. For > now, I decided to simply catch and ignore the server errors about the > duplicates. It's easier to ask for forgiveness than permission. :-) > > Best, > Christoph > ________________________________ > Von: Squeak-dev <[hidden email]> im Auftrag > von Taeumel, Marcel > Gesendet: Donnerstag, 1. Oktober 2020 14:43:38 > An: squeak-dev > Betreff: Re: [squeak-dev] Overriding #= in Graphics and Sounds > > Hi Christoph. > > Hmmm... maybe it is not straightforward to implement? Especially whether > #class (or #species) should match or not. Reminds me of > SequenceableCollection >> #= and #hasEqualElements:. I keep on using > #hasEqualElements: in tests because I don't care about > Array-vs-OrderedCollection in several places. > > [cid:aa12d832-9f5e-4b25-ba80-37b31d0c2dba] > > And Form has also a non-trivial hierarchy of variations: > > [cid:3ca1fe29-c01e-4821-91ee-d30a841a9712] > > For example, would you ignore the #depth if it is black and white anyway? > Or would you break uses of Dictionaries that are virtually > IdentityDictionaries because of their current keys and the missing #=? > > It can be hard. Maybe it needs to be maintined afterwards. So, YAGNI? :-) > > Best, > Marcel > > > Am 01.10.2020 14:23:37 schrieb Thiede, Christoph > <[hidden email]>: > > Hi all, > > > for a current project, I need to compare form or sound objects with each > other, but I found out that they do not override #=, so for example, we > get: > > > (ColorForm extent: 1 @ 1) = (ColorForm extent: 1 @ 1) --> false > > > Wasn't this implemented > > a) simply because it looked like YAGNI? > > b) for design reasons? For example, should (Form extent: 1 @ 1) be equal to > (ColorForm extent: 1 @ 1) or not? > > c) for performance reasons? I don't know if there any guidelines for > implement #= (except that you need to implement #hash as well), but is an > equality comparison generally allowed to be an expensive operation if two > objects are equal? If two large forms have a different resolution or a > different bitmap hash, comparison will be fast, but if they are equal, we > will need to compare every single bit. Would this be okay or a no-go? > > > If implementing #= as proposed is not possible, how would you think about > implementing it as a keyword message on Form, e.g. #sameAs:? > > > The same questions apply to the AbstractSound hierarchy, too, where I'm not > sure whether two sounds being played for different duration should equal or > not. > > For a similar discussion, see also this thread: [squeak-dev] FormInspector, > or also: Text>>#= and its > consequences<http://forum.world.st/FormInspector-or-also-Text-gt-gt-and-its-consequences-td5121599.html>. > > Best, > Christoph > |
Free forum by Nabble | Edit this page |