Finally have a chance to add my thoughts on this. When I read the
reference on DO OVER, I would not expect an UNKNOWN method to satisfy
the required condition so, to me, this is not a bug. However, I can see
the that the opposite view might have some merit. I would suggest
opening an RFE instead of a bug report for further discussion.
I also think that the choice to use the REQUEST ("ARRAY") mechanism
rather than simply sending MAKEARRAY directly was not done without some
thought. If the collection does not have a MAKEARRAY method (nor an
UNKNOWN method that handles a MAKEARRAY message), sending MAKEARRAY will
result in an error message like "Object collection does not understand
message MAKEARRAY" which will confuse the user since all he/she wrote
was DO OVER, the MAKEARRAY having been sent "under the covers". Using
REQUEST("ARRAY") instead, allows the more informative (to me) error
message 98.913: Unable to convert object collection to a single
dimension array value.
If I had encountered this error in a program I was writing, I would
either 1) have added a MAKEARRAY method to the class for the collection
rather than putting the code in the UNKNOWN method or 2) modified the DO
OVER to look like "do o over u~makearray" which allows the UNKNOWN
method to return an array which can then be processed by the DO OVER.
Gil B.
On 11/7/2016 12:41 PM, Rony G. Flatscher wrote:
On 06.11.2016 17:35, Erich Steinböck wrote:
rexxref says that for DO OVER Collection, a MAKEARRAY method is
required, but that's not the full story: Rexx uses the
REQUEST("ARRAY") mechanism to do the conversion, which will send a
MAKEARRAY message, and if no such method exists, will fail (as
documented) without testing for an UNKNOWN method.
Well, sending a message that is not implemented, but an UNKNOWN method
exists in the searched classes will invoke the UNKNOWN method in lieu.
For the sender it does not make a difference whether a message was
served by a method implemented by the same name or by the UNKNOWN
method. This makes ooRexx very powerful (as it does Smalltalk from
which this concept is probably drawn).
The REQUEST-protocol in the object class states (from the ooRexx 5.0.0
beta reference):
5.1.4.17. request
request( classid )
Returns an object of the classid class, or .nil if the request
cannot be satisfied.
This method first compares the identity of the object's class (see
the id method of the Class
class) to classid. If they are the same, the receiver object is
returned as the result. Otherwise,
request tries to obtain and return an object satisfying classid
/*by sending the receiver object the*//*
*//*conversion message make with the string classid appended
(converted to uppercase)*/. For example,
/a //request("string")//message causes a makeString message to be
sent/.*/If the object does not/**/
/**/have the required conversion method, request returns .nil./*
The question also occurs here what the meaning of "does not have the
required conversion method": does that imply that it must physically
exist or does that imply that such a conversion message should be
served successfully?
The conversion methods cause objects to produce different
representations of themselves.
The presence or absence of a conversion method defines an object's
capability to produce the
corresponding representations. For example, lists can represent
themselves as arrays, because they
have a makeArray method, but they cannot represent themselves as
directories, because they do
not have a makeDirectory method. Any conversion method must return
an object of the requested
class. For example, makeArray must return an array. The language
processor uses the makeString
method to obtain string values in certain contexts; see Section
4.2.11, “Required String Values”.
Also, in this context, DO WITH...OVER should probably use the a
request("supplier") message, where the current collection classes
having a "mere" supplier method should get a synonymous method
"makesupplier" in order to match the request protocol.
Whether this is in fact working as designed (but should probably be
better documented) I'm not sure.
Maybe others can chime in and give their perspective, point-of-view as
feedback to be taken into account.
---rony
On Sun, Nov 6, 2016 at 3:34 PM, Rony G. Flatscher
<rony.flatsc...@wu.ac.at <mailto:rony.flatsc...@wu.ac.at>> wrote:
The DO...OVER statement allows one to iterate over a collection.
To do so a MAKEARRAY is requested and the resulting array is then
iterated over.
It seems, that the code in DO...OVER does not send the MAKEARRAY
message, if it does not find that method in the receiver object,
irrespectible whether an UNKNOWN method is available that may
step in and return that array upon request.
Here is a Rexx program demonstrating this problem, bug:
t=.test~new tArr=t~makearray~toString(,"/") say "tArr:" tArr
do o over t say o end say "---" u=.uuu~new
uArr=u~makearray~toString(,"/") say "uArr:" uArr do o over u
say o end say "---" *::class test ::method makearray*return ("one",
"two",
"three") *::class uuu****::method unknown* use arg methName,
methArgs /*if methName="MAKEARRAY" then return ("one", "two",
"three")*/ say "in" self"::unknown, about to raise a syntax
condition" raise syntax 98.913 array (self)
The class "TEST" implements the MAKEARRAY method and the
DO...OVER succeeds.
The class "UUU" does not implement the MAKEARRAY method, but an
UNKNOWN method that returns an array, if a MAKEARRAY message was
received. Here, DO...OVER causes a 98.913 syntax error, which
aborts the program!
Here is the output of running the above program:
F:\test\oorexx\makearray>test1 tArr: one/two/three one two
three --- uArr: one/two/three 13 *-* do o over u Error 98
running F:\test\oorexx\makearray\test1.rex line 13: Execution
error. Error 98.913: Unable to convert object "an UUU" to a
single-dimensional array value.
It may be the case that the interpreter tries to optimize by
checking for the existence of a MAKEARRAY method in the receiving
object and if not found short-circuiting by raising the syntax
error. Instead it should let the UNKNOWN mechanism to get
exercised, such that it becomes possible to delegate the
execution of such unknown messages (like MAKEARRAY in the class
UUU above) by other code, which is the purpose of the UNKNOWN
mechanism in the first place.
This is with ooRexx 5.0.0 beta, not sure about previous versions.
If there are no counter arguments, then I will file a bug report
for this in the tracker.
---rony
P.S.: "DO WITH index i and item o" works by supplying the
SUPPLIER method explicitly or implicitly by the UNKNOWN method.
Here is an example for that variant:
t=.test~new say "tArr:" tArr do with index idx item o over t
say "index:" idx "item:" o end say "---" u=.uuu~new say
"uArr:" uArr do with index idx item o over u say "index:" idx
"item:" o end say "---" *::class test* *::method supplier*
return .supplier~new((1,2,3), ("one", "two", "three"))
*::class uuu****::method unknown* use arg methName, methArgs
/*if methName="SUPPLIER" then return .supplier~new((1,2,3),
("one", "two", "three"))*/ say "in" self"::unknown, about to
raise a syntax condition" raise syntax 98.913 array (self)
Output (no runtime error):
F:\test\oorexx\makearray>test2 tArr: TARR index: one item: 1
index: two item: 2 index: three item: 3 --- uArr: UARR index:
one item: 1 index: two item: 2 index: three item: 3 ---
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Gil Barmwater
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
