[Oorexx-bugs] [ oorexx-Bugs-1768271 ] \'Bag\' setlike methods

[SourceForge.net <no...@so...>]

Bugs item #1768271, was opened at 2007-08-06 06:47
Message generated for change (Comment added) made by wdashley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1768271&group_id=119701

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Classes
Group: 3.2.0
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Rony G. Flatscher (orexx)
Assigned to: Nobody/Anonymous (nobody)
Summary: \'Bag\' setlike methods

Initial Comment:
The 'Bag' class setlike methods 'difference', 'interSection', 'subSet', 'union',
and 'xor' yield wrong results, if the argument 'other' is of type 'MapCollection'.

Example with 'subSet':

----------- cut here -------------
t=.table~new
t[11]="eleven"
t[22]="twenty-two"

b=.bag~of(11)

say "b~subset(t):" b~subset(t)  /* yields: 0 */
----------- cut here -------------

The reason is that the current implementation uses 'allItems' from
'other', if 'other' is a 'Collection'. For MapCollections 'allIndexes'
should be used.

The respective code sections could be simplified in the course of fixing
this.

(I could take over this item.)


----------------------------------------------------------------------

>Comment By: David Ashley (wdashley)
Date: 2007-10-03 09:20

Message:
Logged In: YES 
user_id=931756
Originator: NO

Rick has rejected this bug and no further discussion will be responded to.
If you still feel you are correct then please contact the appeals
committee.

----------------------------------------------------------------------

Comment By: Rony G. Flatscher (orexx)
Date: 2007-10-03 09:03

Message:
Logged In: YES 
user_id=662126
Originator: YES

As you may recall my original implementation (cf. around rev. 619) of
"makeArray" was located at "Collection" and returned "allIndexes".
Reasoning: a collection is a mapping from an index to an item (index->item,
a functional dependency, FD). Clearly this was meant therefore as the
default behaviour.

To cater for the "OrderedCollection" speciality (index does not
functionally determine the item), I defined a "makeArray" that returns
"allItems" there. 

---

Now, you changed that such, that the "Collection" (default) implementation
of "makeArray" returns "allItems", whereas now the "MapCollection" got
considered as a special case such that it gained a "makeArray" of its own
which returns "allIndexes". This may mislead readers of the documentation
that the default for Collections would be that there are no FDs (functional
dependencies), because "allItems" will be returned by default.

But even so, the "makeArray" method would return "allIndexes" where there
are FDs, and "allItems" where there are not ("OrderedCollection"; but also
for "SetCollection", which does not matter as index and item are the same
object there, although that may be quite misleading).

In the context of these methods the question is what array is returned by
the "argument" collection for processing it. If one sends the "makeArray"
message to the argument collection, then the receiver object will return
the array that is appropriate for its type: it will be the "allIndexes"
array in the case of a "MapCollection", and it will be "allItems" else.

If the current implementation would employ the "makeArray" method,
everything would work correctly. 

---

As you may recall, We have discussed the collection classes a few months
ago, and in that context I supplied the links to the discussions within the
ANSI REXX committee of how the collection classes are defined for IBM's
Object REXX and why. [The central concepts to apply are the "functional
dependency" (FD) and in the case of Relation "multivalued dependencies"
(MVD), which themselves are FDs.]

The resulting RFEs and my initial implementation of the Collection methods
attempted to follow that.

---

The current implementation of 3.2.0 (rev. 860) causes existing Object
REXX/ooRexx programs to break as the results of the setlike operations, are
wrong. 

It is also therefore that I think that this is a bug which needs to be
resolved for the release version.


----------------------------------------------------------------------

Comment By: Rick McGuire (bigrixx)
Date: 2007-10-03 05:28

Message:
Logged In: YES 
user_id=1125291
Originator: NO

The original answer stands.  The issue here what portion of the
information from the source collection makes sense when applied to the
receiver collection when only portion can be retained.  This is the items,
not the indexes, that are the important pieces of information.  

----------------------------------------------------------------------

Comment By: Rony G. Flatscher (orexx)
Date: 2007-10-03 02:14

Message:
Logged In: YES 
user_id=662126
Originator: YES

Unfortunately, this *is* a bug!

A MapCollection defines a functional dependency (FD) between index and
item (index->item), therefore "allIndexes" is the significant part of it
and needs to get used. (For that very same reason "makeArray" for
"MapCollection" is defined to return "allIndexes".) 


E.g. consider the following example and its output:

------------------- cut here --------------------
parse version v
say v
   /* SetCollection */
s=.set~of("Anton",          "Berta", "Caesar")
b=.bag~of("Anton", "Anton", "Berta", "Caesar")

   /* OrderedCollection */
l=.list~of("Caesar", "Anton", "Anton", "Berta", "Berta")

   /* MapCollection */
t=.table~new
t["Anton"]="Austria"
t["Berta"]="Belgium"
t["Caesar"]="California"

call dump "s~makeArray", s~makeArray
call dump "l~makeArray", l~makeArray
call dump "t~makeArray", t~makeArray
say "----------------------"

call dump "b~union(l)", b~union(l)
call dump "b~union(t)", b~union(t)
say "----------------------"

::routine dump
  use arg title, coll
  say title":"
  do o over coll
     say "  " o
  end
  say "---"
------------------- cut here --------------------

[Using "makeArray" on the "other" argument would always return the
significant part of the "other" collection, i.e. "allIndexes" with a
"MapCollection" (and "allItems" else).]



----------------------------------------------------------------------

Comment By: Rick McGuire (bigrixx)
Date: 2007-10-02 14:29

Message:
Logged In: YES 
user_id=1125291
Originator: NO

Committed revision 857.

This was a problem in the documentation.  Any set operation where the
receiver is a collection where the index is not a significant part of the
value tuple and the argument is a Map collection needs to be using the
items for the matching, not the indexes.  The documentation has been
updated to make this clearer. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1768271&group_id=119701