Re: [Oorexx-devel] Reinstating/reactivating the ooRexx ARB? (Re: Problem with "DO...OVER" ...

[René Jansen]

I would like to have ARB meetings for ooRexx (and NetRexx, for that matter). As 
a long time has gone by without them, we would need to set those up again. 
Maybe it is best that those who would like to participate, send me their time 
zones and preferences for meeting date/time. For these meetings to be useful, 
we need an agenda. So agenda items are also welcome. 

best regards,

René.

> On 10 Nov 2016, at 17:37, Rony G. Flatscher  wrote:
> 
> 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 >> > 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 

[Oorexx-devel] Reinstating/reactivating the ooRexx ARB? (Re: Problem with "DO...OVER" ...

[Rony G. Flatscher]

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 > > 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