Bag>>#rehash missing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bag>>#rehash missing

Patrick R.
Hi everyone,

during a recent debugging session I noticed that Bag does not implement #rehash although it is, in essence, a hash-based collection and should therefore probably roughly adhere to the protocol of HashedCollection. Is there a good reason not to have #rehash on Bag?

On a similar note: HashedCollection>>#rehash is in the `private` protocol but has various senders. As even the class comment mentions the usage of #rehash, I would also propose to move it out of the `private` protocol. :)

Best wishes,
Patrick

Reply | Threaded
Open this post in threaded view
|

Re: Bag>>#rehash missing

marcel.taeumel
Hi Patrick.

+1 on adding #rehash for Bag ... although it technically depends on #contentsClass ? Hmmm...

+0.5 on making #rehash non-private. Hmm.... maybe "initialization" would be a fitting category. Well, definitely not "update" or something like that. Clients should normally not call it, right?

Best,
Marcel

Am 05.03.2021 20:12:19 schrieb Rein, Patrick <[hidden email]>:

Hi everyone,

during a recent debugging session I noticed that Bag does not implement #rehash although it is, in essence, a hash-based collection and should therefore probably roughly adhere to the protocol of HashedCollection. Is there a good reason not to have #rehash on Bag?

On a similar note: HashedCollection>>#rehash is in the `private` protocol but has various senders. As even the class comment mentions the usage of #rehash, I would also propose to move it out of the `private` protocol. :)

Best wishes,
Patrick



Reply | Threaded
Open this post in threaded view
|

Re: Bag>>#rehash missing

Nicolas Cellier
Hi all,
I understand that we can have bags broken by mutation of some
elements, and that rehash could be convenient while debugging.
But on the other hand, I see quite few senders of rehash in the image,
so I just wonder, are we gonna need it?

I think that private not only covers methods that are really private
and should not be sent by objects of other classes, it also often
means not to be sent in normal circumstances, maybe something closer
to privileged?

Le sam. 6 mars 2021 à 11:48, Marcel Taeumel <[hidden email]> a écrit :

>
> Hi Patrick.
>
> +1 on adding #rehash for Bag ... although it technically depends on #contentsClass ? Hmmm...
>
> +0.5 on making #rehash non-private. Hmm.... maybe "initialization" would be a fitting category. Well, definitely not "update" or something like that. Clients should normally not call it, right?
>
> Best,
> Marcel
>
> Am 05.03.2021 20:12:19 schrieb Rein, Patrick <[hidden email]>:
>
> Hi everyone,
>
> during a recent debugging session I noticed that Bag does not implement #rehash although it is, in essence, a hash-based collection and should therefore probably roughly adhere to the protocol of HashedCollection. Is there a good reason not to have #rehash on Bag?
>
> On a similar note: HashedCollection>>#rehash is in the `private` protocol but has various senders. As even the class comment mentions the usage of #rehash, I would also propose to move it out of the `private` protocol. :)
>
> Best wishes,
> Patrick
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Bag>>#rehash missing

marcel.taeumel
Hi Nicolas.

But on the other hand, I see quite few senders of rehash in the image,
> so I just wonder, are we gonna need it?

Hmm... I don't think that looking for senders will reveal the actual need for #rehash. Maybe broken bags remain unnoticed? At least a test with proper commentary about this issue might help users to figure out when to use #rehash. In Trunk, there are only a few, short-living examples of bags, which do not suffer from this problem. :-)

In this particular case, some of our students stumbled upon this issue in a game and did not know how to interpret the effects to figure out what's going on. ... maybe we need some kind of hash-check test (tool) for the entire environment? The biggest issue here is to learn about the correct use of hashing.

Best,
Marcel

Am 06.03.2021 23:23:56 schrieb Nicolas Cellier <[hidden email]>:

Hi all,
I understand that we can have bags broken by mutation of some
elements, and that rehash could be convenient while debugging.
But on the other hand, I see quite few senders of rehash in the image,
so I just wonder, are we gonna need it?

I think that private not only covers methods that are really private
and should not be sent by objects of other classes, it also often
means not to be sent in normal circumstances, maybe something closer
to privileged?

Le sam. 6 mars 2021 à 11:48, Marcel Taeumel a écrit :

>
> Hi Patrick.
>
> +1 on adding #rehash for Bag ... although it technically depends on #contentsClass ? Hmmm...
>
> +0.5 on making #rehash non-private. Hmm.... maybe "initialization" would be a fitting category. Well, definitely not "update" or something like that. Clients should normally not call it, right?
>
> Best,
> Marcel
>
> Am 05.03.2021 20:12:19 schrieb Rein, Patrick :
>
> Hi everyone,
>
> during a recent debugging session I noticed that Bag does not implement #rehash although it is, in essence, a hash-based collection and should therefore probably roughly adhere to the protocol of HashedCollection. Is there a good reason not to have #rehash on Bag?
>
> On a similar note: HashedCollection>>#rehash is in the `private` protocol but has various senders. As even the class comment mentions the usage of #rehash, I would also propose to move it out of the `private` protocol. :)
>
> Best wishes,
> Patrick
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Bag>>#rehash missing

Nicolas Cellier
Le lun. 8 mars 2021 à 08:23, Marcel Taeumel <[hidden email]> a écrit :

>
> Hi Nicolas.
>
> > But on the other hand, I see quite few senders of rehash in the image,
> > so I just wonder, are we gonna need it?
>
> Hmm... I don't think that looking for senders will reveal the actual need for #rehash. Maybe broken bags remain unnoticed? At least a test with proper commentary about this issue might help users to figure out when to use #rehash. In Trunk, there are only a few, short-living examples of bags, which do not suffer from this problem. :-)
>
> In this particular case, some of our students stumbled upon this issue in a game and did not know how to interpret the effects to figure out what's going on. ... maybe we need some kind of hash-check test (tool) for the entire environment? The biggest issue here is to learn about the correct use of hashing.
>
> Best,
> Marcel
>

Sure, Bag problems have great chances to get unnoticed because Bags
are rarely used in practice.
However, it's not a problem of Bag per se, it's a problem of using
HashedCollection in general in case when we do not restrict object
mutations...
My sentiment was that rehash was more a utility method than something
needed with regard to standard usage of rehash currently in image.
But of course, if you think that it's a useful utility (pleonasm ?), just go.

> Am 06.03.2021 23:23:56 schrieb Nicolas Cellier <[hidden email]>:
>
> Hi all,
> I understand that we can have bags broken by mutation of some
> elements, and that rehash could be convenient while debugging.
> But on the other hand, I see quite few senders of rehash in the image,
> so I just wonder, are we gonna need it?
>
> I think that private not only covers methods that are really private
> and should not be sent by objects of other classes, it also often
> means not to be sent in normal circumstances, maybe something closer
> to privileged?
>
> Le sam. 6 mars 2021 à 11:48, Marcel Taeumel a écrit :
> >
> > Hi Patrick.
> >
> > +1 on adding #rehash for Bag ... although it technically depends on #contentsClass ? Hmmm...
> >
> > +0.5 on making #rehash non-private. Hmm.... maybe "initialization" would be a fitting category. Well, definitely not "update" or something like that. Clients should normally not call it, right?
> >
> > Best,
> > Marcel
> >
> > Am 05.03.2021 20:12:19 schrieb Rein, Patrick :
> >
> > Hi everyone,
> >
> > during a recent debugging session I noticed that Bag does not implement #rehash although it is, in essence, a hash-based collection and should therefore probably roughly adhere to the protocol of HashedCollection. Is there a good reason not to have #rehash on Bag?
> >
> > On a similar note: HashedCollection>>#rehash is in the `private` protocol but has various senders. As even the class comment mentions the usage of #rehash, I would also propose to move it out of the `private` protocol. :)
> >
> > Best wishes,
> > Patrick
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Bag>>#rehash missing

marcel.taeumel
How would you compare (in-place) #sort: and #rehash considering their utility?

Best,
Marcel

Am 08.03.2021 11:42:35 schrieb Nicolas Cellier <[hidden email]>:

Le lun. 8 mars 2021 à 08:23, Marcel Taeumel a écrit :

>
> Hi Nicolas.
>
> > But on the other hand, I see quite few senders of rehash in the image,
> > so I just wonder, are we gonna need it?
>
> Hmm... I don't think that looking for senders will reveal the actual need for #rehash. Maybe broken bags remain unnoticed? At least a test with proper commentary about this issue might help users to figure out when to use #rehash. In Trunk, there are only a few, short-living examples of bags, which do not suffer from this problem. :-)
>
> In this particular case, some of our students stumbled upon this issue in a game and did not know how to interpret the effects to figure out what's going on. ... maybe we need some kind of hash-check test (tool) for the entire environment? The biggest issue here is to learn about the correct use of hashing.
>
> Best,
> Marcel
>

Sure, Bag problems have great chances to get unnoticed because Bags
are rarely used in practice.
However, it's not a problem of Bag per se, it's a problem of using
HashedCollection in general in case when we do not restrict object
mutations...
My sentiment was that rehash was more a utility method than something
needed with regard to standard usage of rehash currently in image.
But of course, if you think that it's a useful utility (pleonasm ?), just go.

> Am 06.03.2021 23:23:56 schrieb Nicolas Cellier :
>
> Hi all,
> I understand that we can have bags broken by mutation of some
> elements, and that rehash could be convenient while debugging.
> But on the other hand, I see quite few senders of rehash in the image,
> so I just wonder, are we gonna need it?
>
> I think that private not only covers methods that are really private
> and should not be sent by objects of other classes, it also often
> means not to be sent in normal circumstances, maybe something closer
> to privileged?
>
> Le sam. 6 mars 2021 à 11:48, Marcel Taeumel a écrit :
> >
> > Hi Patrick.
> >
> > +1 on adding #rehash for Bag ... although it technically depends on #contentsClass ? Hmmm...
> >
> > +0.5 on making #rehash non-private. Hmm.... maybe "initialization" would be a fitting category. Well, definitely not "update" or something like that. Clients should normally not call it, right?
> >
> > Best,
> > Marcel
> >
> > Am 05.03.2021 20:12:19 schrieb Rein, Patrick :
> >
> > Hi everyone,
> >
> > during a recent debugging session I noticed that Bag does not implement #rehash although it is, in essence, a hash-based collection and should therefore probably roughly adhere to the protocol of HashedCollection. Is there a good reason not to have #rehash on Bag?
> >
> > On a similar note: HashedCollection>>#rehash is in the `private` protocol but has various senders. As even the class comment mentions the usage of #rehash, I would also propose to move it out of the `private` protocol. :)
> >
> > Best wishes,
> > Patrick
> >
> >
>
>