Hi, Suppose I have an instance variable referencing a collection of booleans. I want to have all elements of the collection be stored as bits. Is there a way I can express it using slots? This idea can be generalized to other types of slots. Noury
On 20/03/20 4:54 PM, N. Bouraqadi wrote:
Hi,
Suppose I have an instance variable referencing a collection of booleans. I want to have all elements of the collection be stored as bits. Is there a way I can express it using slots?
What do the bits represent? Is there an ordering among these booleans? You could use a Set of integers (for ordinals) or symbols (for cardinals like flags). HTH .. Subbu
Hello, There is a work in progress prototype slot named BooleanSlot in the Slot-Example package built-in the image. I think this slot does what you want. So, the answer is yes, it is possible to do that. But you will need to fix todos left in BooleanSlot methods. Julien Le 20/03/20 à 12:24, N. Bouraqadi a écrit :
Hi,
Suppose I have an instance variable referencing a collection of booleans. I want to have all elements of the collection be stored as bits. Is there a way I can express it using slots?
This idea can be generalized to other types of slots.
Noury
Thanks Julien. So, what I did experienced is because BooleanSlot is work in progress. To address my issue using slots, I guess collections should implement asBit method (Sent by BooleanSlot). Noury
On 20 Mar 2020, at 13:56, Julien Delplanque <julien.delplanque@inria.fr> wrote:
Hello,
There is a work in progress prototype slot named BooleanSlot in the Slot-Example package built-in the image.
I think this slot does what you want.
So, the answer is yes, it is possible to do that. But you will need to fix todos left in BooleanSlot methods.
Julien
Le 20/03/20 à 12:24, N. Bouraqadi a écrit :
Hi,
Suppose I have an instance variable referencing a collection of booleans. I want to have all elements of the collection be stored as bits. Is there a way I can express it using slots?
This idea can be generalized to other types of slots.
Noury
On Fri, Mar 20, 2020, 06:53 Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Thanks Julien. So, what I did experienced is because BooleanSlot is work in progress. To address my issue using slots, I guess collections should implement asBit method (Sent by BooleanSlot).
Noury, when modelling something like this, think whether "all collections should implement asBit". I've added the word all, of course. There are so many possible collections for which #asBit wouldn't make sense that I would conclude the hypothesis to be incorrect. Even if you were to implement it on a single collection class, such as Array, there are still so many examples where #asBit could not apply. Perhaps, there could be an e.g. Bits class in the Collection hierarchy. But, even then, it seems to me that there are so many inherited methods that wouldn't make sense. What would be the use of #do:? What would #select: mean? You get the idea. An alternative possibility, and not the only one, is to model the bits as part of an integer, small or large. Of course, for performance, a ByteArray might be a good way to store bits. It has the benefit that every instance *can* represent bits. But, the inherited API operates on the bytes, not the bits. Encapsulation may be the answer. e.g. a Bits object that holds a ByteArray and provides the API that is needed. That's a rather long answer, admittedly.
Noury
On 20 Mar 2020, at 13:56, Julien Delplanque <julien.delplanque@inria.fr> wrote:
Hello,
There is a work in progress prototype slot named BooleanSlot in the Slot-Example package built-in the image.
I think this slot does what you want.
So, the answer is yes, it is possible to do that. But you will need to fix todos left in BooleanSlot methods.
Julien
Le 20/03/20 à 12:24, N. Bouraqadi a écrit :
Hi,
Suppose I have an instance variable referencing a collection of booleans. I want to have all elements of the collection be stored as bits. Is there a way I can express it using slots?
This idea can be generalized to other types of slots.
Noury
Hi Richard, My example was about having a collection of bits. So, #do: and #select: do continue to have the very same semantics. The whole point is to save memory behind the scenes, while keeping the same API. Consider a very large matrix of booleans. It would save memory to store booleans as bits. There is of course the "normal" way of doing it, by changing the implementation. But, with slots, it should be possible to use an instance 2DArray. Noury
On 20 Mar 2020, at 15:34, Richard Sargent <richard.sargent@gemtalksystems.com> wrote:
On Fri, Mar 20, 2020, 06:53 Noury Bouraqadi <bouraqadi@gmail.com <mailto:bouraqadi@gmail.com>> wrote: Thanks Julien. So, what I did experienced is because BooleanSlot is work in progress. To address my issue using slots, I guess collections should implement asBit method (Sent by BooleanSlot).
Noury, when modelling something like this, think whether "all collections should implement asBit". I've added the word all, of course. There are so many possible collections for which #asBit wouldn't make sense that I would conclude the hypothesis to be incorrect. Even if you were to implement it on a single collection class, such as Array, there are still so many examples where #asBit could not apply.
Perhaps, there could be an e.g. Bits class in the Collection hierarchy. But, even then, it seems to me that there are so many inherited methods that wouldn't make sense. What would be the use of #do:? What would #select: mean? You get the idea.
An alternative possibility, and not the only one, is to model the bits as part of an integer, small or large.
Of course, for performance, a ByteArray might be a good way to store bits. It has the benefit that every instance *can* represent bits. But, the inherited API operates on the bytes, not the bits.
Encapsulation may be the answer. e.g. a Bits object that holds a ByteArray and provides the API that is needed.
That's a rather long answer, admittedly.
Noury
On 20 Mar 2020, at 13:56, Julien Delplanque <julien.delplanque@inria.fr <mailto:julien.delplanque@inria.fr>> wrote:
Hello,
There is a work in progress prototype slot named BooleanSlot in the Slot-Example package built-in the image.
I think this slot does what you want.
So, the answer is yes, it is possible to do that. But you will need to fix todos left in BooleanSlot methods.
Julien
Le 20/03/20 à 12:24, N. Bouraqadi a écrit :
Hi,
Suppose I have an instance variable referencing a collection of booleans. I want to have all elements of the collection be stored as bits. Is there a way I can express it using slots?
This idea can be generalized to other types of slots.
Noury
Wow - I hadnât quite understood the implications here- can you explain that 2DArray reference a bit more? I keep thinking slots are cool but havenât quite spotted when to use them and this seems like a compelling example that I havenât quite grasped... Tim
On 20 Mar 2020, at 17:54, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi Richard,
My example was about having a collection of bits. So, #do: and #select: do continue to have the very same semantics. The whole point is to save memory behind the scenes, while keeping the same API. Consider a very large matrix of booleans. It would save memory to store booleans as bits. There is of course the "normal" way of doing it, by changing the implementation. But, with slots, it should be possible to use an instance 2DArray.
Noury
On 20 Mar 2020, at 15:34, Richard Sargent <richard.sargent@gemtalksystems.com> wrote:
On Fri, Mar 20, 2020, 06:53 Noury Bouraqadi <bouraqadi@gmail.com> wrote: Thanks Julien. So, what I did experienced is because BooleanSlot is work in progress. To address my issue using slots, I guess collections should implement asBit method (Sent by BooleanSlot).
Noury, when modelling something like this, think whether "all collections should implement asBit". I've added the word all, of course. There are so many possible collections for which #asBit wouldn't make sense that I would conclude the hypothesis to be incorrect. Even if you were to implement it on a single collection class, such as Array, there are still so many examples where #asBit could not apply.
Perhaps, there could be an e.g. Bits class in the Collection hierarchy. But, even then, it seems to me that there are so many inherited methods that wouldn't make sense. What would be the use of #do:? What would #select: mean? You get the idea.
An alternative possibility, and not the only one, is to model the bits as part of an integer, small or large.
Of course, for performance, a ByteArray might be a good way to store bits. It has the benefit that every instance *can* represent bits. But, the inherited API operates on the bytes, not the bits.
Encapsulation may be the answer. e.g. a Bits object that holds a ByteArray and provides the API that is needed.
That's a rather long answer, admittedly.
Noury
On 20 Mar 2020, at 13:56, Julien Delplanque <julien.delplanque@inria.fr> wrote:
Hello,
There is a work in progress prototype slot named BooleanSlot in the Slot-Example package built-in the image.
I think this slot does what you want.
So, the answer is yes, it is possible to do that. But you will need to fix todos left in BooleanSlot methods.
Julien
Le 20/03/20 à 12:24, N. Bouraqadi a écrit :
Hi,
Suppose I have an instance variable referencing a collection of booleans. I want to have all elements of the collection be stored as bits. Is there a way I can express it using slots?
This idea can be generalized to other types of slots.
Noury
On Sat, 21 Mar 2020 at 01:54, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi Richard,
My example was about having a collection of bits. So, #do: and #select: do continue to have the very same semantics. The whole point is to save memory behind the scenes, while keeping the same API. Consider a very large matrix of booleans. It would save memory to store booleans as bits. There is of course the "normal" way of doing it, by changing the implementation. But, with slots, it should be possible to use an instance 2DArray
What is the 2D-ness of a collection of bits. Have you considered Bitmap? The original paper discusses bit-fields. I'm not sure how that maps to current Pharo implementation. http://scg.unibe.ch/archive/papers/Verw11bFlexibleObjectLayouts.pdf cheers -ben
participants (7)
-
Ben Coman -
Julien Delplanque -
K K Subbu -
N. Bouraqadi -
Noury Bouraqadi
-
Richard Sargent -
Tim Mackinnon