Hi Josep Maria, On 09.03.2025 14:40, Josep Maria Blasco wrote:
Missatge de Rony G. Flatscher <rony.flatsc...@wu.ac.at> del dia dg., 9 de març 2025 a les 14:04: (cut)1a) In order to create an ooRexx array from a stem array the following method should be added to the stem class: makeArrayFromStemArray This name makes it clear that a stem array is to be processed and that the resulting array should not have the stem value with the tail 0. (The existting stem method makeArray continues to create an array that represents all tails of a stem, including a tail with the value 0.) I'm not sure that using "makeXXX" for the message names is a good idea, because the request method of the Object class uses the "make" pattern for class conversions.Yes, that is the reason why using that name.Ah, but a class called "ArrayFromStemArray" does not exist, and that breaks the "make" semantics. Rexxref 5.4.1.18 "request" says "Any conversion method *must return an object of the requested class*. For example, makeArray must return an array" (emphasis mine). But, since there is no such thing as an ArrayFromStemArray class, this could be misleading.
Yes. The conversion method must start with "make" and be followed by the classid (a string) supplied as argument to the .Object's request method.
This protocol could be used for creating an array from a stem (by implementing a method "make" || supplied_classId_as_arg, however, there is already a makearray method defined for stem. Hence the first idea to add the variant to the name of the conversion method yielding "makeArrayFromStemArray". The reason being that .Object's request method does only accept the classid argument and by using another name that includes the intent ("fromStemArray") one could add another make conversion method to the stem class. However, I concur that a) the name becomes too long and b) probably "classid" should be an existing classid. :) Then it becomes possibel to change the name of the method tonot start with "make" hence not adhering to the request protocol.
In the meantime Gil's idea seems to be interesting. ---rony
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
