I reported this already (item #3151709, was opened at 2011-01-05 09:52), and I
was also surprised.
There is a note in REXXREF about sorting arrays and non-sparse arrays (page
285). I found out after reporting.
I think it's not consistent with
Do s over array
say s
end
This will show all existing items in the array. Skippning removed items
I prefer to think of, in this case, that removed items is nonexisting items and
should not be included in a sort operation, which means array will "shrink".
but it has already done that more or less, array~items will only count indexes
with values (like the do over clause),
but array~sort statment will fail if item is removed from array, if not last
item in array is removed.
As for current status shouldn't array~items return a count including removed
entries.
Some inconsistency here I think
/hex
----- Ursprungligt Meddelande -----
Från: Rony G. Flatscher <rony.flatsc...@wu-wien.ac.at>
Till: Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
Kopia:
Datum: fredag, 24 augusti 2012 12:02
Ämne: [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts ...
Yesterday I stumbled over a surprising behaviour of Array's sort, which led me
to open a bug report <https://sourceforge.net/p/oorexx/bugs/1107/>. Obviously
the sorting is working as designed, hence the reported behaviour was not
accepted as a bug.
Having slept a night over this and thinking about my utmost surprise that sort
would raise an error condition if it hits an empty array element (one without
an entry) in between, I try to summarize my thoughts about the current
behaviour, requesting a change of the design and implementation to get rid of
the surprising factor and to remove undeterminable fragility from the Array
sort.
First, the current design and implementation:
The single dimiensioned array that gets sorted must not have empty entries in
between. If the sort tries to refer to an empty slot it raises "Error
98.975:Missingarrayelementatposition xyz" and the program is ended, if the
condition does not get trapped.
Thoughts about this:
Having worked for many years sorting arrays, I was *totally surprised* about
this unexpected (because never experienced) behaviour! The surprise factor for
me was at the maximum.
There is no documentation going with sorting arrays that would communicate that
the arrays to be sorted must have no empty elements in between that I am aware
of. Therefore one cannot expect this behaviour at all. If one uses single
dimensioned arrays that get changed in routines and methods (written by others)
such that elements get removed in between, then sorting such an array all of a
sudden (and totally unforseeable) raises the above mentioned error condition,
which makes sort quite fragile for programmers IMHO. To overcome this
situation, one must advice every ooRexx programmer to do *always* a
(potentially time-consuming) makearray before sorting an array just to make
sure that the aforementioned error condition does not get raised. Finally, I
would have expected that an array with empty elements should be sortable
without a problem, therefore my utmost surprise! :)
My expectations would be simply as follows: if a single dimensioned array
contained empty elements, then sorting would work and all the empty elements
are sorted to the end of the array, no matter what the comparison method
returns. This way, after a sort, all empty elements are always at the end of
the array. (The items and size messages would remain the same.) The questions I
would have, before contemplating about filing a RFE:
am I the only one who is surprised about a failing sort on a single dimensioned
array if in between there are empty elements?
Independent of this, would it be acceptable to change the current design and
implementation of the sort such that empty elements are tolerated and put to
the end of the array (what would be arguments, thoughts that speak against such
a change)? ---rony
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
