Hmm, as no one has commented so far, this is in a sort of limbo.
How about reinstating/reactivating the ooRexx ARB (architecture review board
following democratic
principles) for the ooRexx project, which originally was meant to overview how
the ooRexx language
should evolve?
Language related questions like this could be gathered or presented there and
discussed.
Of course a lot of implemented concepts have not been formally put through the
ooRexx ARB in the
past. Nevertheless, there is a lot (and sound) reasoning behind why and how
concepts got
implemented, so I would think that Rick's thoughts, reasonings and knowledge
would be very helpful
there as well.
So how about reinstating/reactivating the ooRexx ARB, maybe at least after
ooRexx 5.0 got out of
beta and general available?
Any thoughts, comments?
---rony
On 07.11.2016 18:41, 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
