On 12.03.2010 01:42, Gil Barmwater wrote:
> OK, thanks for the explanation. I understand now why my test code failed.
>
> Rick McGuire wrote:
>
>> The rules behind the entire MAKExxxx process is that the value
>> returned must be of the type requested. That is obj~class == .array
>> in the case of makearray. A lot of this is based on the internal
>> engine taking advantage of the fact the returned object is absolutely
>> of the type indicated so that the internal C++ methods can be used
>> directly rather than have to go through the late-bound dynamic method
>> look that would be required for a more general object. There are
>> serious performance implications to opening this up for other types of
>> objects to be provided.
>>
This imposes the knowledge of interpreter implementation details on to
the shoulders of the ooRexx programmers.
A solution that would make this aspect orthogonal would be:
* define the methods/interfaces for an array/list (like at, [],
items, put, []=),
* if makeArray returns an instance of the built-in class .array use
the optimized C++ execution path, else use the non-optimized path
sending the appropriate messages.
This would eradicate the "astonishment factor" and the programmer would
be free to take full advantage of the "polymorphicness"/OO (where each
subclass is always of the type of the specialized class).
---rony
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
