Author Topic: Thoughts about Collections  (Read 9927 times)

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Thoughts about Collections
« on: October 21, 2005, 12:46:12 pm »
In another thread, Paolo asserted:
Quote
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:
Quote
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?

« Last Edit: October 21, 2005, 12:49:38 pm by jeshaw2 »
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Thoughts about Collections
« Reply #1 on: October 21, 2005, 05:47:05 pm »
Quote
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
Quote
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.
Quote
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
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Thoughts about Collections
« Reply #2 on: October 21, 2005, 06:34:22 pm »
Paolo;
These statements were of great help!

Quote
[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?
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Thoughts about Collections
« Reply #3 on: October 21, 2005, 07:16:58 pm »
Quote
[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
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Thoughts about Collections
« Reply #4 on: October 21, 2005, 08:06:48 pm »
Quote
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.

Quote
  • Iterator
  • Enumerator
  • Indexer
This is a good starting point.  I'll start gathering my thought on them.

Quote
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.
Verbal Use Cases aren't worth the paper they are written upon.

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Thoughts about Collections
« Reply #5 on: October 22, 2005, 07:06:11 am »
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?


« Last Edit: October 22, 2005, 07:09:01 am by jeshaw2 »
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Thoughts about Collections
« Reply #6 on: October 22, 2005, 06:52:59 pm »
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
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Thoughts about Collections
« Reply #7 on: October 23, 2005, 07:18:46 pm »
Quote
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.

Quote
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
Quote
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.

Quote
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.

Verbal Use Cases aren't worth the paper they are written upon.

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Thoughts about Collections
« Reply #8 on: October 23, 2005, 08:27:26 pm »
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
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Thoughts about Collections
« Reply #9 on: October 23, 2005, 08:59:07 pm »
Quote
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
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Thoughts about Collections
« Reply #10 on: October 24, 2005, 12:09:20 am »
Sounds good to me!  ;) but for Enumerator I didn't ask for the peanut butter I asked for its location.

bruce
« Last Edit: October 24, 2005, 12:11:01 am by sargasso »
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Thoughts about Collections
« Reply #11 on: October 24, 2005, 12:52:28 am »
Quote
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 nth 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
« Last Edit: October 24, 2005, 12:56:51 am by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Thoughts about Collections
« Reply #12 on: October 24, 2005, 07:16:29 am »
Quote
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. :)
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Thoughts about Collections
« Reply #13 on: October 24, 2005, 02:34:10 pm »
Quote
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
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Thoughts about Collections
« Reply #14 on: October 24, 2005, 03:57:15 pm »
Paolo;

Everything made sense and I agree with everything  up to this point...
Quote
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? ???
Verbal Use Cases aren't worth the paper they are written upon.