× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Simon Coulter wrote:
 >...
>>These are the items that are $50 and over:
>>[ ]   8  $50  Allow dynamic resizing of arrays and multi-occurrence DS.
>>[ ]  12  $50  Multiple-dimension arrays (expressions only).
>>[ ]  23  $80  Allow expressions as parameters to keywords.
>>[ ]  24  $80  Full null field support.
>>[ ]  25  $80  Procedure name overloading based on parm types.
>
>
> But I want them all !!  :-)  Not really, I do want three of them.  I can
> accept the pricing on most of them but #23 seems extremely overpriced.
>...

Actually, I suspect #23 is still underpriced.  We've investigated it
a number of times, and it always ends up bigger than we first
thought.  Oh, we know how to do the work.  It's a matter of calling
the existing expression parser for keyword parameters, but using a
different exit for the token emit function.  It's the implementation
of that function that's the biggie.  We basically have to handle all
of the expression tokens emitted by the expression parser, even ones
that don't make sense for static expressions.

This all goes back to the original plan for implementing RPG IV.
D-Specs were considered a big priority, and so they were implemented
first.  Expressions weren't as much a priority, and started with
less attention than they really deserved.  And there was indeed a
risk that they wouldn't even make it into the language!  (At least,
we implemented the keyword parser in a flexible manner, and we were
able to use it later for F-Specs, and even H-Specs.)

Hindsight is of course 20/20, and in retrospect, we should have put
more attention on the expression parser, and used that in the
implementation of keyword processing.  But at the time, the plan did
make sense considering the prevailing conditions.

Regarding expressions as keyword arguments, yes, it would be very
nice.  But generally, every time we see some specific requirement,
we've always found some easier solution to implement the
requirement.  Right now, personally, I'm not aware of any specific
requirement that would justify the resources required to implement
this one enhancement.  Yes, of course it would be nice.  But at what
cost?

Cheers!  Hans





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.