Thoughts about Collections

[jeshaw2]

In another thread, Paolo asserted:

Collections collect (group) things.

I'm not sure, but I don't think he was using the word group in the same way we do when discussing the <<memberOf>> meronymic relationship.  At least, I hope not, for I'm thinking that the term Collection is better reserved and used for a gathering of objects, in a simple association, which are not part of a meronymic relationship.

However, I've seen in other texts that in order for two objects to be associated, messages must pass between them.  I kind of like that thought, but I can also visualize a vector of objects that do not intercommunicate that I might also call a collection (e.g.; things in a shopping cart).  Perhaps, this latter context, the vector is a container of objects that are not in a collection?  But then I must reconcile myself to another truthful assertion:

All containers define collections (even if only implicitly - the objects contained)

I seem to be caught in a Catch-22 with this.  Can anyone help me clarify this?

[Paolo F Cantoni]

In another thread, Paolo asserted:
Collections collect (group) things
I'm not sure, but I don't think he was using the word group in the same way we do when discussing the <<memberOf>> meronymic relationship.

Jim, so you don't have to make any assumptions :
I was using the noun  Collection: A group of objects or works to be seen, studied, or kept together.
and I was using the verb group: To place or arrange in a group

At least, I hope not, for I'm thinking that the term Collection is better reserved and used for a gathering of objects, in a simple association, which are not part of a meronymic relationship.

I think you have been offered the Eric Morecambe Gambit (Eric was a very famous British comedian - with his partner Ernie Wise):  "Get out of that - without moving!"
It seems to be you can't get a collection of things without a meronymic relation, since you automatically create a whole - the Collection.

However, I've seen in other texts that in order for two objects to be associated, messages must pass between them.  I kind of like that thought, but I can also visualize a vector of objects that do not intercommunicate that I might also call a collection (e.g.; things in a shopping cart).  Perhaps, this latter context, the vector is a container of objects that are not in a collection?  But then I must reconcile myself to another truthful assertion:
All containers define collections (even if only implicitly - the objects contained)
I seem to be caught in a Catch-22 with this.  Can anyone help me clarify this?

The message assertion is another example of how object modellers are constrained by their own language (as you concurred with the observation by my colleague Vince).

For two objects to be associated, someone/thing has to make the association.  The objects themselves never need know they are associated.  They can be associated by inference (derivation).  My brother (Luigi) is such, because he is also the son of both my mother and father.

Two objects that are associated may pass messages:
a) if they want to
b) if they can locate the associated object and their interface.

In neither case does this affect the association.

In the limiting case, the objects may be associated merely[/] because I have chosen (arbitrarily) to place them in the same collection (vector being a form of collection)

I once went to a talk on "Objects without Classes".  The presenter, a University lecturer, was going on about how his system merely created Objects and dynamically grouped them together using Attribute values.  So I asked him what he thought Classification was?  What is a Class but a collection (Classifier) of objects that share the same structure and behaviour?

What structure is the Collective whole we defined above?  A Classifier (in this case a Class).

I have previously expressed the view that Collection describes the Member_Of meronymy.  I still hold to that.

You appeared to have a problem with that.  Has my clarification resolved anything for you?

Assuming you have no further problem with Collection being the Member_Of meronymy, we can continue this (Collections) thread discussion the nature and properties of the various Collection types.

HTH,
Paolo

[jeshaw2]

Paolo;
These statements were of great help!

[SNIP]In the limiting case, the objects may be associated merely because I have chosen (arbitrarily) to place them in the same collection (vector being a form of collection)

[SNIP]The objects themselves never need know they are associated.  They can be associated by inference (derivation).

[SNIP]
It seems to be you can't get a collection of things without a meronymic relation, since you automatically create a whole - the Collection.

All my uncertainties have been resolved.

So where do we go next on collections?

[Paolo F Cantoni]

[size=13][SNIP][/size]
Assuming you have no further problem with Collection being the Member_Of meronymy, we can continue this (Collections) thread discussion the nature and properties of the various Collection types.

Go for it...

One thing where I think we might constructively start is on defining some terms in a (coding) language neutral way.

I've had trouble, in the past, getting a clear definition (with respect to collections) of the differences (if any) between :

• Iterator
  
• Enumerator
  
• Indexer

Maybe we can start with that?

Also, while we are at it.  I think we should formally define that Collection meronyms are Items (not Elements etc)

Paolo

[jeshaw2]

One thing where I think we might constructively start is on defining some terms in a (coding) language neutral way.

Yes, I can think of several terms I'd like to do this with also; Just to be sure we are all properly calibrated together.

• Iterator
• Enumerator
• Indexer

This is a good starting point.  I'll start gathering my thought on them.

I think we should formally define that Collection meronyms are Items (not Elements etc)

Agreed.  Items is a much better term.  Elements carries too much baggage with it.

[jeshaw2]

With regard to the terms Iterator, Enumerator, & Indexer and in the context of Collections, I have the following (personal & informal) thoughts and connotations attached to them:

A work in process...

• All three terms relate to working with the Items in a Collection;
  
• All three differ in the degree of services they provide in maintaining the list of Items held by a Container;
  
• I suggest we select and define one of these terms for use at the CIM level; discarding the others.
  
• For me, Indexer carries too much baggage from the implementation level to be a good candidate.  I'd like to discard this term out of hand.
  
• At the implementation level, Collections are held in a variety of structures (vectors, linked lists, binary trees, etc.). At the CIM level, we don't wish to concern ourselves with how the Items are held, but we don't want our definition to foreclose on any structural options.
  
• I think the terms Iterator, Enumerator relate to the services provided by the container of a Collection.  
  
• I can envision a variety of specialized container types.
  
• Thus, I like the Java concept of declaring Iterators, Enumerators as an interface to a Collection.  ( Need to think a bit about the case of multiple collections held in one container.)
  
• I understand the underlying reasons, but, linguistically speaking, I don't like Java's movement from enumerator to iterator in order to enhance the services provided.
  
• For me, Iterator connotes a form of repetition.  This relates then to flow of control within a process.
  
• Enumerator connotes a presentation of things for whatever purpose I wish to apply to them.
  
• At the CIM level, I would cast my vote for Enumerator and I like the concept of it being an Interface (or a set of interface specializations);
  
• I think of the Enumeration interface as being the prime feature of an object's role as a Container.  Perhaps later we can discuss, at the PSM level, adornments on the associations between the collection and its Items relating to the nature of the structure within which the items are organized?
  
• I would suggest that our definition of an Enumerator be broad enough to include control of Item access, Ordering and inclusion within the Collection.  By Ordering I mean specification of the basis for ordering access to the Items, not the fact that the items are Ordered within the association.
  
  I offer this stream of consciousness simply as a set of discussion starting points.  Care to add your thoughts and/or comments?
  
  
  

[Paolo F Cantoni]

Jim,

I've put your original quote in Blue and my response in  Navy...
With regard to the terms Iterator, Enumerator, & Indexer and in the context of Collections, I have the following (personal & informal) thoughts and connotations attached to them:

A work in process...

• All three terms relate to working with the Items in a Collection;
  [/color]For the purposes of the discussion I'm going to propose the following definitions:
  Iterate: To say or perform again; repeat  Thus Iterator: Something we use to repeatedly access the collection.  In particular, the process of moving from one item to the next is repeatable.
  Enumerate: To count off or name one by one; list  It's not clear to me what the difference is between an Enumerator an Iterator.  In this context.
  Index: To guide, point out, or otherwise facilitate reference  This would appear to be the ability to randomly access something.
  
  • All three differ in the degree of services they provide in maintaining the list of Items held by a Container;[/color]  Yes, in principle, but as I said above, there seems to be precious little difference between some - maybe we will be able to tease out sufficient difference
    
    • I suggest we select and define one of these terms for use at the CIM level; discarding the others.[/color]  I don't agree here.  we need to keep those terms which have meaning in the CIM
      
      • For me, Indexer carries too much baggage from the implementation level to be a good candidate.  I'd like to discard this term out of hand.[/color]  My feeling is that (taking the cue from C#) if we are able to access a collection as though it was an Array (conceptual of course!), then Indexer is a valid term.  In particular, if we choose to iterate through the Array using the Indexer, it doesn't stop it being an Indexer.
        
        • At the implementation level, Collections are held in a variety of structures (vectors, linked lists, binary trees, etc.). At the CIM level, we don't wish to concern ourselves with how the Items are held, but we don't want our definition to foreclose on any structural options.[/color]  Here I think you hit the nail squarely on the head!  What I'm trying to do with this thread (and by the sound of it so are you) is to determine which forms of collections have validity in the Conceptual domain and which are purely implementation mechanisms?  What transformations are possible between the conceptual collections and their implementations so that the implementation does not violate any contracts that are in place at the conceptual level?
          
          • I think the terms Iterator, Enumerator relate to the services provided by the container of a Collection.[/color]  I don't want to use the term Container (since I don't believe we've established that every Collection is a Container - only that every Container has a Collection), perhaps Collector (or Collection holonym).  I'd now add Indexer the list.
            
            • I can envision a variety of specialized container types.[/color]  Yes (but Collectors), as discussed above
              
              • Thus, I like the Java concept of declaring Iterators, Enumerators as an interface to a Collection.  ( Need to think a bit about the case of multiple collections held in one container.)[/color]  Yes.  Now getting back to Containers,  For the moment it might be useful to consider that every Container has a Collection.  That collection might be a Collection of Collections!  I have a container of jelly beans (of various colours).  I therefore have a Collection of jelly beans.  But do I also have a collection of black jelly beans (my favourite!).  I suspect I don't, unless I have separated them into their own bag within the original container.  Thoughts?
                
                • I understand the underlying reasons, but, linguistically speaking, I don't like Java's movement from enumerator to iterator in order to enhance the services provided.[/color]  I agree.
                  
                  • For me, Iterator connotes a form of repetition.  This relates then to flow of control within a process.[/color]  Agreed, see my comments above
                    
                    • Enumerator connotes a presentation of things for whatever purpose I wish to apply to them.[/color]  I'm not so sure.  I didn't like using Enumerator for Collections since it has such a strong affinity with Enumerations.  Then I suddenly realised that an Enumeration is an Ordered Set!  In my view, Iterator should be the principle interface to any Collection.  If the Collection meets certain criteria (that is, can behave like an Enumeration), we can also use the Enumerator
                      
                      • At the CIM level, I would cast my vote for Enumerator and I like the concept of it being an Interface (or a set of interface specializations);[/color]  See comments above
                        
                        • I think of the Enumeration interface as being the prime feature of an object's role as a Container.  Perhaps later we can discuss, at the PSM level, adornments on the associations between the collection and its Items relating to the nature of the structure within which the items are organized?
                          
                        • I would suggest that our definition of an Enumerator be broad enough to include control of Item access, Ordering and inclusion within the Collection.  By Ordering I mean specification of the basis for ordering access to the Items, not the fact that the items are Ordered within the association.[/color]  Can you clarify?
                          I offer this stream of consciousness simply as a set of discussion starting points.  Care to add your thoughts and/or comments?
                          
                          Done...
                          
                          Wotyafink?
                          
                          Paolo

[jeshaw2]

For the purposes of the discussion I'm going to propose the following definitions:
Iterate: To say or perform again; repeat  Thus Iterator: Something we use to repeatedly access the collection.  In particular, the process of moving from one item to the next is repeatable.
Enumerate: To count off or name one by one; list  It's not clear to me what the difference is between an Enumerator an Iterator.  In this context.
Index: To guide, point out, or otherwise facilitate reference  This would appear to be the ability to randomly access something.

This was essentially the point at which I started with my thoughts.  

When you suggest objects of type Iterator, Indexer, and Enumerator, I'm envisioning  objects which interact with collections in specialized ways.  Is the abstractions of such objects what you are attempting to get at?

Rambling on a bit more...

When I include a collection within my model, at the CIM level,  I generally have a need to either impact the collection itself or interact with a subset of its items.  I either want to Modify the list of items in the collection (add, remove, count, etc.), Notify the items of some event (as in the publish/subscribe pattern), or Request a service of the Items (including a simple value mapping service).  All of these are facilitated by messages which are Synchronous or Asynchronous.  My desire is to see to it that these messages are sent to their targeted Items.  I don't care how the messages are sent, how the Items are organized within the collection, nor the technology or route the messenger takes to effect delivery (unless the problem domain is the delivery of messages).  In fact, in some cases, I don't even care if the message is successfully delivered or responded to.

I design, therefore, to the collector's interface which effects the delivery to the identified recipient(s) using the technologies and methodologies of the collector's choice.  I prefer not to become too dependent upon the collector itself.

I would suggest that our definition of an Enumerator be broad enough to include control of Item access, Ordering and inclusion within the Collection.  By Ordering I mean specification of the basis for ordering access to the Items, not the fact that the items are Ordered within the association.  Can you clarify?

Yes.  In another thread you said

isOrdered defines whether the Collection maintains an internal ordering based upon the identifier of the items such that a sequential traversal of the items will yield and ordered sequence.

My thought was to be able to request an Enumeration (Ordered set   ) with an ordering not maintained internally by the collector; such ordering to be specified in the request.

I think the terms Iterator, Enumerator relate to the services provided by the container of a Collection.  I don't want to use the term Container (since I don't believe we've established that every Collection is a Container - only that every Container has a Collection), perhaps Collector (or Collection holonym).

Good point! I agree.  However, I'm having difficulty thinking in terms of Index, Iterate, or Enumerate at the CIM level.  They seem to be denizens of a lower abstraction level.

[sargasso]

I think all three access items are necessary - at an abstract level...

Client: "Where's the peanut butter?"

Indexer: "On the middle shelf in the fridge"
Iterator: "Look at the contents of each shelf in the fridge until you find it."
Enumerator: "Remove and inspect each object in the fridge until you find one that's labelled peanut butter, then you'll know where it was"

Notice that i have ordered them by decreasing "power",  IOW the Indexer has a lot of power as it knows something about the collection (and the container), the Iterator knows something about the structure of the container but little about the collection, the Enumerator only knows
that the collection exists in the container.

There are probably lots of examples where the power stucture could be different, but I hold that all are necessary.


bruce

[Paolo F Cantoni]

I think all three access items are necessary - at an abstract level...

Client: "Where's the peanut butter?"

Indexer: "On the middle shelf in the fridge"
Iterator: "Look at the contents of each shelf in the fridge until you find it."
Enumerator: "Remove and inspect each object in the fridge until you find one that's labelled peanut butter, then you'll know where it was"

Notice that i have ordered them by decreasing "power",  IOW the Indexer has a lot of power as it knows something about the collection (and the container), the Iterator knows something about the structure of the container but little about the collection, the Enumerator only knows
that the collection exists in the container.

There are probably lots of examples where the power structure could be different, but I hold that all are necessary.
bruce

Great Example!  But...  IMO

Indexer: "On the middle shelf in the fridge"
Iterator: "Look at the contents of each shelf in the fridge until you find it."
Enumerator: "These two items are peanut butter"

I think if we ensure that Enumerator applies only to Enumerations (Ordered Sets) then we can be rigorous.

We might say the Iterator knows nothing about the Item.  The Enumerator knows that the Item can be Enumerated and returns a subset of the collection.  I think (and this is a repetition of my point in the earlier post) that you can only apply an Enumerator to an Enumerable collection (that is, contains items that can be classified by a simple Enumeration).  It has been put to me that such an Enumerator is, by definition, a filter.  I think this is a reasonable proposition.

In C#, you can have string Indexers that would do the job of: Find me the item marked Peanut Butter.  Note, I said marked (or labelled).  In my view, the Enumerator knows the Type.


Paolo

[sargasso]

Sounds good to me!   but for Enumerator I didn't ask for the peanut butter I asked for its location.

bruce

[Paolo F Cantoni]

Sounds good to me!   but for Enumerator I didn't ask for the peanut butter I asked for its location.
 
bruce

Good point Gunga Din...
Collection is: Items in the fridge (therefore Index is Item number)

Indexer: use this to retrieve the item numbers labeled "Peanut Butter"
Iterator: use this to iterate through the collection looking for items labelled "Peanut Butter" or of type Peanut_Butter (or both)
Enumerator: use this to return the subset of items of type Peanut_Butter

The Indexer uses some search strategy to locate the items (usually get me the n^th item).
The Iterator uses a repetetive stepping through the items.
The Enumerator applies a filter to the list.

The Indexer and Enumerator are essentially declarative, the Iterator is essentially procedural.

Paolo

[jeshaw2]

In C#, you can have string Indexers that would do the job of: Find me the item marked Peanut Butter.  Note, I said marked (or labelled).  In my view, the Enumerator knows the Type.

I lost you here...

Does your use of the word type mean an object's classifier/data type or are you referring to the attribute values shared by members in a <<memberOf>> relationship?  I'm with you if the term is used in the latter sense.

[Paolo F Cantoni]

I lost you here...

Does your use of the word type mean an object's classifier/data type or are you referring to the attribute values shared by members in a <<memberOf>> relationship?  I'm with you if the term is used in the latter sense.

Yes Jim,
I think it's the latter sense is what I'm meaning.  This is a bit of thinking on-the-fly...

Essentially, I'm trying to make a distinction between a name given to something (like Jim, Paolo, bruce etc) and some categorisation (Senior, Youth, Adult, Baby) for which I can ascribe an Enumeration.

I previously said, we should use Enumerator for Enumerations.  This requires that each Item in the Collection has the Attribute that is the Enumeration.

Now, I suspect that if the collection is mixed, it may not need the same Attribute in each Item, but it must be there (and only one of) for the Enumerator to work.

Make sense?  It is on-the-fly.

Paolo

[jeshaw2]

Paolo;

Everything made sense and I agree with everything  up to this point...

it may not need the same Attribute in each Item, but it must be there (and only one of) for the Enumerator to work.

I agree with what I think you said, but I'm not sure that what you think you said is what I think you said.  Can you fly a bit slower?