Thanks to both Rony and Jean-Louis for your comments. Here are some
additional thoughts I've had as a result.
When the problem to be solved is converting one type of ordered
collection to another, as it was when I started working on this, then
the overriding principle is maintaining the order of the items. In
fact, for the list, queue and circularqueue classes, the index is only
relevant as it supplies the order of the items. And there can be no
'holes' for those classes. Arrays are different in that there may be a
relationship between the index and the item and there might be missing
indices. My approach was to treat all arrays the same way as the other
classes - the sequence/order was what was significant and not the value
of the index. So a 'sparse' array is effectively made non-sparse when
it is the source and a resulting array can never be 'sparse' (even if
the source was a 'sparse' array).
If one starts with the problem being converting an array to a stem
(array) or a stem (array) to an array, then one cannot necessarily
assume that the order is the only important thing. Stem instances are
more like mapped collections where there is a relationship between the
tail (index) and the item. (NB there is a toDirectory method defined
for them.) So then one must decide what to do where the source is
'sparse'. If the source is an array, there are two choices - ignore the
missing indices and create a stem (array) that just contains the items
in the array in the same order - or create a stem that maps the array
index to the tail value. If the source is a stem, there is a third
possibility - the stem might have a 'default' value defined. My
implementation does not distinguish that case and either supplies the
(defined) default value or the derived name for missing tail values. If
it is deemed important to make a distinction between those cases, we
will need to discuss how that should be specified. And, finally, the
choice of "sparse" as the name of the second argument is now clearly
less than ideal so we should come up with an alternative.
On 3/15/2025 7:58 AM, Jean Louis Faucher wrote:
On 15 Mar 2025, at 11:36, Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
Any comments from others reading this group?
Maybe 2 comments.
1)
I find the term “sparse” misleading.
when the target is an ordered collection, the target is never sparse:
no hole in the indexes thanks to ~appendAll or ~append
when the target is a stem, the target can be sparse
dumping a Stem:
# 1: index=[0] val: [5]
# 2: index=[3] val: [hi (3)]
# 3: index=[1] val: [hi (1)]
On the source side, it seems that “sparse” means "only include tail
values that are defined”
But see 2), it’s not the case when no default value.
2)
when not parse ("-- pass 2 -- supplying a second argument …")
If I put in comment the assignment of default value, then I get
dumping a XRRAY:
# 1: index=[1] val: [hi (1)]
# 2: index=[2] val: [S.2]
# 3: index=[3] val: [hi (3)]
# 4: index=[4] val: [S.4]
# 5: index=[5] val: [S.5]
dumping a Stem:
# 1: index=[0] val: [5]
# 2: index=[2] val: [S.2]
# 3: index=[1] val: [hi (1)]
# 4: index=[5] val: [S.5]
# 5: index=[4] val: [S.4]
# 6: index=[3] val: [hi (3)]
I would expect
dumping a XRRAY:
# 1: index=[1] val: [hi (1)]
# 2: index=[2] val: [hi (3)]
dumping a Stem:
# 1: index=[0] val: [5]
# 2: index=[3] val: [hi (3)]
# 3: index=[1] val: [hi (1)]
because S.2, S.4 and S.5 denote undefined values.
But that would be the mode “sparse”…
An attempt to summarize the cases:
casetargetsource
1ordered collectionordered collection
2ordered collectionstem
3stemordered collection
4stemstem
casesparse parameter
1no effect
2true: only include tail values that are defined
false: include all possible tail values
3no effect
4true: the new stem will be sparse if the stem is sparse
false: the new stem won't be sparse even if the stem is sparse
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
