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
