[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [regrep - RIM draft 02 comment] Compendium
Diego Ballve wrote: > Farrukh Najmi wrote: > >> Richard Martell wrote: >> >>> 5 [ADVISORY] In 2.8.1 perhaps change values to type Set<LongName> >>> instead of Bag, since duplicate values don't appear to be meaningful >>> in this context. >> >> >> >> Duplicate for values of a Slot do make sense. For example lets say >> the Slot values store the Gender of each student in a class. I know >> it is a dumb example but thats the best I can think of at present. >> Suggest no change. > > > Set, Bag or Sequence? I'd rather have sequence there, since it is more > powerful than Set or Bag (i.e., you can represent a Set or a Bag in a > Sequence but not the other way; you can randomize the order of an > ordered collection after you get it, but it might not be possible to > reorder an unordered collection to the same order it had on creation > time). +1 Diego makes an excellent point. Set or Bag do not maintain order but Sequence does and sequence is often important in Slot values. BTW here is a brief definition borrowed from [1] of each in case it is not clear: Set: An object of class *set of* /X/ holds an unordered collection of objects of class /X/ with duplicates prohibited. Bag: An object of class *bag of* /X/ represents a similar collection except that duplicates (and multiple instances in general) are permitted. Sequence: An object of class *sequence of* /X/ is like a *bag of */X/ except that it is ordered, so we can enquire what value is at a particular position in the sequence (just like indexing into an array). [1] http://www.eschertech.com/tutorial/chapter2/class_collection.htm I propose we accept teh change to use Sequence instead of Bag or Set in draft 03 > > We have discussed this about a year ago, I think, and by that time the > use-case I had was that my value was longer than LongName, so I > created extra logic in the client to break the value into many > LongName (there's a flaw for searches, for instance, but anyway). For > that I needed the registry to keep the order and not to return the > objects in random order. > +1 Order is important for Slot values in many cases (including one above) and does not hurt where it is not important. -- Regards, Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]