Hi Raymond,

On Sat, 18 Aug 2001 21:59:35 +0200 "Raymond Tiefenthal" <r.tiefenthal at gmx.de> wrote:
>1. Searching in collections
>Both, # indexOf: and # lastIndexOf: take an element as argument and return
>an index.
>Both, # findFirst: and # findLast: take a block as argument and return an
>index too.
># detect: takes a block and returns an element.
>I wondered why there isn't a # detectLast: counterpart. I would expect it in
>SequenceableCollection and since # detect: in class Collection depends on
>the order of # do:, I would expect it to depend on # reverseDo:.

Why? Probably someone had a use for a particular method and added it. Making everything completely regular/orthogonal is a lot of extra work.

>2. Could you explain why I would want to use class Array instead of a
>OrderedCollection for instance. I understand that ByteArray, IntegerArray
>etc. don't have objects as elements and therefore are less costly in terms
>of memory and speed. But Array has normal objects as elements. When should
>do I want to use Array?

Two reasons to use Array:
1. Array is faster than OrderedCollection.
2. Some calls to the VM require particular classes of arguments. You may not get that deep, but it's another reason.

Main reason to use OrderedCollection:
1. You don't know how big it's going to get and you like the flexibility of #add:, #addFirst:, #removeFirst and #removeLast.

>3. I was asking myself, why SortedCollection doesn't overwrite # indexOf:
>for instance, in order to perform a binary search.

I guess it never got high enough on anyone's priority list.

>4. How to figure the memory usage of an object?

First you need to decide what this means:
- The size of the object itself (size of header + size of slots)?
- Same as above, but repeated recursively for everything that the object points to?
- Something in between, like counting what the object *owns* but not what it simply *references*?

The first is fairly easy. Take a look at SystemDictionary>>spaceForInstancesOf:.

The second could be constructed from the first by iterating through every pointer in the object and counting the space occupied by the object pointed to. If the possibility of encountering the same object more than once exists, then you would need to keep track of which ones had already been counted.

The third would require a more detailed knowledge of what the pointers in the object mean. When looking at a Morph, e.g., you might want to count the submorphs, but not the owner. Etc, etc.

A reasonably close answer can often be arrived at by creating a number (10, 100, 1000...) of similar objects and seeing how much of Squeak's heap gets consumed in the process.

Cheers,
Bob