Slots vs collections

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

Slots vs collections

Noury Bouraqadi-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Slots vs collections

K K Subbu
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

Reply | Threaded
Open this post in threaded view
|

Re: Slots vs collections

Julien Delplanque-2
In reply to this post by Noury Bouraqadi-2
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Slots vs collections

Noury Bouraqadi-2
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 <[hidden email]> 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
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Slots vs collections

Richard Sargent
Administrator
On Fri, Mar 20, 2020, 06:53 Noury Bouraqadi <[hidden email]> 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 <[hidden email]> 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
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Slots vs collections

Noury Bouraqadi-2
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 <[hidden email]> wrote:

On Fri, Mar 20, 2020, 06:53 Noury Bouraqadi <[hidden email]> 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 <[hidden email]> 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
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: Slots vs collections

Tim Mackinnon
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 <[hidden email]> 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 <[hidden email]> wrote:

On Fri, Mar 20, 2020, 06:53 Noury Bouraqadi <[hidden email]> 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 <[hidden email]> 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
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: Slots vs collections

Ben Coman
In reply to this post by Noury Bouraqadi-2


On Sat, 21 Mar 2020 at 01:54, Noury Bouraqadi <[hidden email]> 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.

cheers -ben