Author Topic: Thoughts about Collections  (Read 9928 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Thoughts about Collections
« Reply #30 on: October 26, 2005, 04:59:40 am »
Quote
Interesting!  A Collections Wiki   ;)  I agree.  I have Excel 2003, I think the two file types are the same, but you might consider *.cvs format to allow participation by those with steam-driven (and other alternatively fueled) computers. ;D

Need we a home for Policy & Feature Definition also?
We can include a pile of things in the Workbook.

But on the subject of Wiki.  Have you tried out TiddlyWiki?  It's cute.  A Wiki in one HTML file.  Maybe we can also use that for some other stuff?

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Thoughts about Collections
« Reply #31 on: October 26, 2005, 05:03:10 am »
Quote
[size=13][SNIP][/size] but you might consider *.CSV format to allow participation by those with steam-driven (and other alternatively fuelled) computers. ;D
I'd rather not use .CSV because I wanted to add formatting (and possibly images).

Paolo
« Last Edit: October 26, 2005, 05:04:01 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 #32 on: October 26, 2005, 05:04:44 am »
Quote
Have you tried out TiddlyWiki?

No, but I'm interested.  I've come lately to the world of Wikis, Wikipedia being my only experience.

I'll check TiddlyWiki out.
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 #33 on: October 26, 2005, 06:58:31 am »
Jim,

It's up on the EA User Group site, under Shared Documents, UMLAbstractions.

Add some more entries.

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 #34 on: October 26, 2005, 07:52:29 am »
Paolo;
I can see it, but I can't save it.  I'm awaiting a UserId to the site.

I'll add to it.  First, I want to add some Policy Headings.

In the Associative column, is the heading read as isAssociative and does the "X" indicate true?
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 #35 on: October 26, 2005, 01:39:31 pm »
Quote
[size=13][SNIP][/size]
In the Associative column, is the heading read as isAssociative and does the "X" indicate true?
Yes and Yes
« Last Edit: October 26, 2005, 01:40:36 pm 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
Order Policy
« Reply #36 on: October 26, 2005, 08:40:57 pm »
Here are my thoughts on the Order Policy I mentioned earlier in this thread.

Order Policy

Collections that need an ordering of their Items are Ordered Collections.  

Ordered Collections may only contain items that, taken together, form a full order according the the collection's ordering function.  This does not and should not require the ordering function itself to realize a full order; ordering may be achieved by ways other than an ordering function.

The enumertion order of an Ordered Associative collection is a full order consistent with the partial order of the keys.  The enumeration order of an Ordered non-Associative collection is a full order consistent with the partial order of the items.

For both collection types, any remaining nondeterminism in the ordering of items must be absorbed by the Enumeration Policy.

For the Java programmer, the default Equivalence function for ordered collections is x.compareTo(y).

On a UML Class Structure diagram, Ordered Collections shall have the property string isOrdered displayed at the holonym end of the Collection/Item association.

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

KP

  • EA Administrator
  • EA Expert
  • *****
  • Posts: 2436
  • Karma: +29/-2
    • View Profile
Re: Order Policy
« Reply #37 on: October 26, 2005, 08:51:12 pm »
Quote
On a UML Class Structure diagram, Ordered Collections shall have the property string isOrdered displayed at the holonym end of the Collection/Item association.


UML 2.0 says the notation should be {ordered} rather than isOrdered (isOrdered is the name of the property)

Neil
The Sparx Team
support@sparxsystems.com

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Thoughts about Collections
« Reply #38 on: October 26, 2005, 09:13:51 pm »
OOPS!  You are correct.  I'll fix my notes.   :-[
Thanks.
« Last Edit: October 26, 2005, 10:18:10 pm by jeshaw2 »
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
Collision Policy
« Reply #39 on: October 26, 2005, 10:43:43 pm »
Here are my thoughts on the Collision Policy I mentioned earlier in this thread.

Collision Policy

A collision policy comes into play in two circumstances:
  • When deriving a new collection from an existing collection, where the derivation-operation arguments propose content that collide with the existing content.; and,
  • When mutating an existing collection where the mutation-operation arguments propose content that collide with the existing content.

    A non-Associative Collection collision occurs between an existing item x and a proposed mutated or new item y if x is equivalent to y according to the equivalence function of the existing collection.  Collisions in an Associative Collection are always in terms of the keys only.

    In general, the three collision policies are multi, replacing, and unique. There are  two policy specification & notation approaches possible, only one of which is supported by the UML 2 Superstructure:

    The UML supports only the isUnique property which is notated by {unique}. isUnique = true is the default property value, but its appearance as a notation on the diagrams is optional.  The isUnique = true case says that:
  • In non-associative Collections, multiple items having the same value are not allowed; and,
  • In Associative Collection, multiple items having the same key-values are not allowed.  UML does not specify how collisions are resolved.

    An extension to the UML might be made to support, in an XOR relationship with isUnique, the additional (if you'll allow use of the term) Collision properties of isReplacing and isMulti.
  • multi simply says collisions aren't a conflict.  Put 'em both in the newly constructed/mutated collection.
  • replacing says that proposed contents are included instead of the existing contents it collides with.
  • unique says a collision throws an exception rather than constructing a new, or mutating and existing collection.

    Notations of {multi}, {replacing}, and {unique} seem reasonable.  Again, a default of isUnique = true is also reasonable.

    A collision notation on a derivation-operation of the existing collection specifies that the derived collection is consistent with the specified collision policy (even though the existing collection is not).  The default is that the derived collection has the same collision policy as the existing collection.

    A collision notation at the holonym end of the Collection/Item Association specifies that the existing collection is consistent with the specified collision policy.

    Your thoughts?
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 #40 on: October 27, 2005, 08:08:32 am »
Quote
It's up on the EA User Group site, under Shared Documents, UMLAbstractions.
 
Add some more entries.
I've added some entries  :)

I'm wondering if you would consider all of the Sets to be Associative since, via an Indexer, one may 'retrieve the item numbers "Peanut Butter" '?  I put a grayed out X in the spreadsheet.
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: Collision Policy
« Reply #41 on: October 27, 2005, 09:48:28 am »
[onFurhterReflection]

Perhaps unique is a Homonym: same word, different meaning?

On an association, unique is a promise of the collection's nature, but on a mutator-operation it is a constraint upon the possible outcomes of the mutation, and on an derivation-operation it is a collision resolution specification within the derived collection?

If so, this would impact my logic on where it would be reasonable to use Replacing and Multi.

[/onFurhterReflection]
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 #42 on: October 27, 2005, 03:13:37 pm »
Quote
I've added some entries  :)

I'm wondering if you would consider all of the Sets to be Associative since, via an Indexer, one may 'retrieve the item numbers "Peanut Butter" '?  I put a grayed out X in the spreadsheet.
I've added some more back.   I'm happy to have Sets as Associative.  Is it possible to have an Associative Collection that doesn't allow Ordinal manipulation?  If so, we need another column.

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 #43 on: October 27, 2005, 04:36:22 pm »
Quote
Is it possible to have an Associative Collection that doesn't allow Ordinal manipulation?  If so, we need another column.
 Can you expand on what Ordinal manipulation might entail?

BTW, I just made indexed lists immutable. :)
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 #44 on: October 27, 2005, 05:24:16 pm »
Paolo

Quote
I'm happy to have Sets as Associative.

Actually, I was hoping you'd talk me out of it; because now, what is the difference between a set and a map  ???  Is it that a map has an explicit key and a set has a derived key (derived from the item's position)?  :-/

Perhaps the Indexer is an object that derives a map, which is associative, from an existing set which is non-associative?   :-/
Verbal Use Cases aren't worth the paper they are written upon.