Array vs OrderedCollection

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

Array vs OrderedCollection

Miguel Cobá
Hi all,

are there any reason to prefer:

"adding 2 objects"
array := Array with: anObject.
array := array copyWith: aSecondObject
"removing object"
array := array copyWithout: aSecondObject.

instead of:

"adding 2 objects"
oc := OrderedCollection new.
oc add: anObject.
oc add: aSecondObject.
"removing object"
oc remove: aSecondObject ifAbsent: []

This in reference to

Class >> addSubclass: and Class >> removeSubclass: methods

Thanks for any answers
Miguel Cobá
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Array vs OrderedCollection

Michael van der Gulik-2
On 4/27/09, Miguel Enrique Cobá Martínez <[hidden email]> wrote:

> Hi all,
>
> are there any reason to prefer:
>
> "adding 2 objects"
> array := Array with: anObject.
> array := array copyWith: aSecondObject
> "removing object"
> array := array copyWithout: aSecondObject.
>
> instead of:
>
> "adding 2 objects"
> oc := OrderedCollection new.
> oc add: anObject.
> oc add: aSecondObject.
> "removing object"
> oc remove: aSecondObject ifAbsent: []
>
> This in reference to
>
> Class >> addSubclass: and Class >> removeSubclass: methods


In this particular case, I think you've made a valid point. I can't
see any obvious reason why an OrderedCollection can't be used. My
first suspicion is that this code was written before
OrderedCollections were added to the system (i.e. in 1980 sometime).
It might also have been written this way to make sure that the image
could potentially run without an OrderedCollection class (e.g. when
bootstrapping an image or something).

The first three variables of Class (i.e. superclass, methodDict,
format) are special and accessed directly by the VM meaning that they
need to be carefully worked with, but as far as I know all of the
other instance variables can be toyed with. Just be careful though...
changing something here the wrong way is likely to break the compiler
or the image.

Gulik.

--
http://gulik.pbwiki.com/
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Array vs OrderedCollection

Jerome Peace
In reply to this post by Miguel Cobá


Hi Miguel,

The answer depends on what you are doing.

Arrays are compact fixed size entities. OrderedCollections are less compact and less fixed size.

If you are building a list by adding objects to it. Don't care to know the maximum size in advance. Or need a stack like object, OrderedCollections are your class of object.

Once you are done building. Know the exact size and know that few changes to the list will be needed. Array is good.

Many things should not care whether the collection is one or the other as far as messages go. Performance will usually favor Arrays when the size is not changing.

So do you want random access to your collection?
Or do you need to easily add or remove things from the ends?

It is easy to have it both ways. When the processing favors OrderedCollections use asOrderedCollection to insure the class.
When random access rather than growth is needed use asArray.

Don't care? Leave it be. Most language will work with either.

Also some objects already have preferences. Streams currently expect their contents to be Arrays.
Strings expect to be arrays of Characters.

I have found no I-can-plan-in-advance type rules for this. I find myself annoyed when the code requires I actually choose.

I usually aim for using Arrays. And if the code fights me on this I use OrderedCollections.

If I want a stack then I need ordered collection using addLast: item and removeLast for push and pop. I found this out after reading Kent Beck's book on Smalltalk best practice pattens.

Yours in curiosity and service, --Jerome Peace

--- On Sun, 4/26/09, Miguel Enrique Cobá Martínez <[hidden email]> wrote:

> From: Miguel Enrique Cobá Martínez <[hidden email]>
> Subject: [Newbies] Array vs OrderedCollection
> To: "A friendly place to get answers to even the most basic questions about Squeak." <[hidden email]>
> Date: Sunday, April 26, 2009, 5:00 PM
> Hi all,
>
> are there any reason to prefer:
>
> "adding 2 objects"
> array := Array with: anObject.
> array := array copyWith: aSecondObject
> "removing object"
> array := array copyWithout: aSecondObject.
>
> instead of:
>
> "adding 2 objects"
> oc := OrderedCollection new.
> oc add: anObject.
> oc add: aSecondObject.
> "removing object"
> oc remove: aSecondObject ifAbsent: []
>
> This in reference to
>
> Class >> addSubclass: and Class >>
> removeSubclass: methods
>
> Thanks for any answers
> Miguel Cobá
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners


   
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Array vs OrderedCollection

Miguel Cobá
In reply to this post by Michael van der Gulik-2
Michael van der Gulik wrote:

> On 4/27/09, Miguel Enrique Cobá Martínez <[hidden email]> wrote:
>> Hi all,
>>
>> are there any reason to prefer:
>>
>> "adding 2 objects"
>> array := Array with: anObject.
>> array := array copyWith: aSecondObject
>> "removing object"
>> array := array copyWithout: aSecondObject.
>>
>> instead of:
>>
>> "adding 2 objects"
>> oc := OrderedCollection new.
>> oc add: anObject.
>> oc add: aSecondObject.
>> "removing object"
>> oc remove: aSecondObject ifAbsent: []
>>
>> This in reference to
>>
>> Class >> addSubclass: and Class >> removeSubclass: methods
>
>
> In this particular case, I think you've made a valid point. I can't
> see any obvious reason why an OrderedCollection can't be used. My
> first suspicion is that this code was written before
> OrderedCollections were added to the system (i.e. in 1980 sometime).
> It might also have been written this way to make sure that the image
> could potentially run without an OrderedCollection class (e.g. when
> bootstrapping an image or something).
>
Yes I thought that, as the Array is one of the special objects, and it
was necessary to build the first version of OrderedCollection.

> The first three variables of Class (i.e. superclass, methodDict,
> format) are special and accessed directly by the VM meaning that they
> need to be carefully worked with, but as far as I know all of the
> other instance variables can be toyed with. Just be careful though...
> changing something here the wrong way is likely to break the compiler
> or the image.
>
I don't have plans of modify those methods, just searching for
implementations of parent/child pointers and in a thread, someone
mentioned those methods as a good implementation.

> Gulik.
>

Thank you,
Miguel Cobá
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Array vs OrderedCollection

Miguel Cobá
In reply to this post by Jerome Peace
Jerome Peace wrote:

>
> Hi Miguel,
>
> The answer depends on what you are doing.
>
> Arrays are compact fixed size entities. OrderedCollections are less compact and less fixed size.
>
> If you are building a list by adding objects to it. Don't care to know the maximum size in advance. Or need a stack like object, OrderedCollections are your class of object.
>
> Once you are done building. Know the exact size and know that few changes to the list will be needed. Array is good.
>
> Many things should not care whether the collection is one or the other as far as messages go. Performance will usually favor Arrays when the size is not changing.
>
> So do you want random access to your collection?
> Or do you need to easily add or remove things from the ends?
>
> It is easy to have it both ways. When the processing favors OrderedCollections use asOrderedCollection to insure the class.
> When random access rather than growth is needed use asArray.
>
> Don't care? Leave it be. Most language will work with either.
>
> Also some objects already have preferences. Streams currently expect their contents to be Arrays.
> Strings expect to be arrays of Characters.
>
> I have found no I-can-plan-in-advance type rules for this. I find myself annoyed when the code requires I actually choose.
>
> I usually aim for using Arrays. And if the code fights me on this I use OrderedCollections.
>
> If I want a stack then I need ordered collection using addLast: item and removeLast for push and pop. I found this out after reading Kent Beck's book on Smalltalk best practice pattens.
>
> Yours in curiosity and service, --Jerome Peace

Thanks for your advise. I think that as the array is a VM-aware type, it
is implemented as native code. Maybe that is not the case with the
ordered colection, that is byte code compiled.

But besides that, a OrderedCollection is more versatile than an Array.
Anyway, I think that for my code, as is more focused to adding and
removing objects and for this, an OrderedCollection is the best choice.

Thank you again,
Miguel Cobá

>
> --- On Sun, 4/26/09, Miguel Enrique Cobá Martínez <[hidden email]> wrote:
>
>> From: Miguel Enrique Cobá Martínez <[hidden email]>
>> Subject: [Newbies] Array vs OrderedCollection
>> To: "A friendly place to get answers to even the most basic questions about Squeak." <[hidden email]>
>> Date: Sunday, April 26, 2009, 5:00 PM
>> Hi all,
>>
>> are there any reason to prefer:
>>
>> "adding 2 objects"
>> array := Array with: anObject.
>> array := array copyWith: aSecondObject
>> "removing object"
>> array := array copyWithout: aSecondObject.
>>
>> instead of:
>>
>> "adding 2 objects"
>> oc := OrderedCollection new.
>> oc add: anObject.
>> oc add: aSecondObject.
>> "removing object"
>> oc remove: aSecondObject ifAbsent: []
>>
>> This in reference to
>>
>> Class >> addSubclass: and Class >>
>> removeSubclass: methods
>>
>> Thanks for any answers
>> Miguel Cobá
>> _______________________________________________
>> Beginners mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
>      
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Array vs OrderedCollection

David T. Lewis
On Sun, Apr 26, 2009 at 10:08:54PM -0500, Miguel Enrique Cob? Mart?nez wrote:

> Jerome Peace wrote:
> >
> >Hi Miguel,
> >
> >The answer depends on what you are doing.
> >
> >Arrays are compact fixed size entities. OrderedCollections are less
> >compact and less fixed size.
> >
> >If you are building a list by adding objects to it. Don't care to know the
> >maximum size in advance. Or need a stack like object, OrderedCollections
> >are your class of object.
> >
> >Once you are done building. Know the exact size and know that few changes
> >to the list will be needed. Array is good.
> >
> >Many things should not care whether the collection is one or the other as
> >far as messages go. Performance will usually favor Arrays when the size is
> >not changing.
> >
> >So do you want random access to your collection?
> >Or do you need to easily add or remove things from the ends?
> >
> >It is easy to have it both ways. When the processing favors
> >OrderedCollections use asOrderedCollection to insure the class.
> >When random access rather than growth is needed use asArray.
> >
> >Don't care? Leave it be. Most language will work with either.
> >
> >Also some objects already have preferences. Streams currently expect their
> >contents to be Arrays.
> >Strings expect to be arrays of Characters.
> >
> >I have found no I-can-plan-in-advance type rules for this. I find myself
> >annoyed when the code requires I actually choose.
> >
> >I usually aim for using Arrays. And if the code fights me on this I use
> >OrderedCollections.
> >
> >If I want a stack then I need ordered collection using addLast: item and
> >removeLast for push and pop. I found this out after reading Kent Beck's
> >book on Smalltalk best practice pattens.
> >
> >Yours in curiosity and service, --Jerome Peace
>
> Thanks for your advise. I think that as the array is a VM-aware type, it
> is implemented as native code. Maybe that is not the case with the
> ordered colection, that is byte code compiled.

Array is an ordinary class, just like OrderedCollection. The VM is aware
of class Array only in the sense that it has hooks to create instances of
Array from within the VM, but the actual instances are objects just like
other object.

> But besides that, a OrderedCollection is more versatile than an Array.
> Anyway, I think that for my code, as is more focused to adding and
> removing objects and for this, an OrderedCollection is the best choice.

Yes, good choice.

Dave
 
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Array vs OrderedCollection

Miguel Cobá
David T. Lewis wrote:

> On Sun, Apr 26, 2009 at 10:08:54PM -0500, Miguel Enrique Cob? Mart?nez wrote:
>> Jerome Peace wrote:
>>> Hi Miguel,
>>>
>>> The answer depends on what you are doing.
>>>
>>> Arrays are compact fixed size entities. OrderedCollections are less
>>> compact and less fixed size.
>>>
>>> If you are building a list by adding objects to it. Don't care to know the
>>> maximum size in advance. Or need a stack like object, OrderedCollections
>>> are your class of object.
>>>
>>> Once you are done building. Know the exact size and know that few changes
>>> to the list will be needed. Array is good.
>>>
>>> Many things should not care whether the collection is one or the other as
>>> far as messages go. Performance will usually favor Arrays when the size is
>>> not changing.
>>>
>>> So do you want random access to your collection?
>>> Or do you need to easily add or remove things from the ends?
>>>
>>> It is easy to have it both ways. When the processing favors
>>> OrderedCollections use asOrderedCollection to insure the class.
>>> When random access rather than growth is needed use asArray.
>>>
>>> Don't care? Leave it be. Most language will work with either.
>>>
>>> Also some objects already have preferences. Streams currently expect their
>>> contents to be Arrays.
>>> Strings expect to be arrays of Characters.
>>>
>>> I have found no I-can-plan-in-advance type rules for this. I find myself
>>> annoyed when the code requires I actually choose.
>>>
>>> I usually aim for using Arrays. And if the code fights me on this I use
>>> OrderedCollections.
>>>
>>> If I want a stack then I need ordered collection using addLast: item and
>>> removeLast for push and pop. I found this out after reading Kent Beck's
>>> book on Smalltalk best practice pattens.
>>>
>>> Yours in curiosity and service, --Jerome Peace
>> Thanks for your advise. I think that as the array is a VM-aware type, it
>> is implemented as native code. Maybe that is not the case with the
>> ordered colection, that is byte code compiled.
>
> Array is an ordinary class, just like OrderedCollection. The VM is aware
> of class Array only in the sense that it has hooks to create instances of
> Array from within the VM, but the actual instances are objects just like
> other object.
>
Thanks for the explanation, I had the idea that the array was internally
something special and diferent than the other clases.

Miguel Cobá

>> But besides that, a OrderedCollection is more versatile than an Array.
>> Anyway, I think that for my code, as is more focused to adding and
>> removing objects and for this, an OrderedCollection is the best choice.
>
> Yes, good choice.
>
> Dave
>  
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Array vs OrderedCollection

Bert Freudenberg
On 27.04.2009, at 14:12, Miguel Enrique Cobá Martínez wrote:

>> I had the idea that the array was internally something special and  
>> diferent than the other clases.


It is not a special kind of class, but Array is different than  
OrderedCollection from the VM's point of view.

If you look at the class definition of Array you see it uses  
"variableSubclass:" whereas OrderedCollection uses the "simple"  
"subclass:" definition. That means that OrderedCollection only has  
"named" fields (its instance variables), but Array has "indexed" fields.

If you use #at: with an OrderedCollection, it sends #at: to its  
instance variable named "array". Using #at: on an Array accesses that  
indexed field directly. So to Smalltalk code the both behave quite  
similarly.

If a VM primitive method works on an object, it accesses its fields  
directly and not by sending messages. So if a primitive method expects  
an object with indexed fields, you cannot substitute an  
OrderedCollection. But it does not have to be an instance of Array,  
any class with indexable fields would do (*).

So Array is not special, you can make your own kind of indexable  
collection using the "variableSubclass:" definition. This is rarely  
needed (much easier to use Arrays) but you can do it.

- Bert -

(*) unless the primitive author (no pun intended) took a shortcut and  
actually declared the function to require an Array instance. The  
correct way is to check wether the class has the right format, not its  
class name._______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners