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á
On 4/27/09, Miguel Enrique Cobá Martínez miguel.coba@gmail.com 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.
Michael van der Gulik wrote:
On 4/27/09, Miguel Enrique Cobá Martínez miguel.coba@gmail.com 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á
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 miguel.coba@gmail.com wrote:
From: Miguel Enrique Cobá Martínez miguel.coba@gmail.com Subject: [Newbies] Array vs OrderedCollection To: "A friendly place to get answers to even the most basic questions about Squeak." beginners@lists.squeakfoundation.org 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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 miguel.coba@gmail.com wrote:
From: Miguel Enrique Cobá Martínez miguel.coba@gmail.com Subject: [Newbies] Array vs OrderedCollection To: "A friendly place to get answers to even the most basic questions about Squeak." beginners@lists.squeakfoundation.org 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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@lists.squeakfoundation.org
-
Bert Freudenberg -
David T. Lewis -
Jerome Peace -
Michael van der Gulik -
Miguel Enrique Cobá Martínez