Re: It's That Time Again! The 2002 RPG Enhancement Poll

[Hans Boldt <boldt@xxxxxxxxxx>]

Douglas Handy wrote:
> Hans,
>
> Can you clarify something for me regarding enhancement #31, EVALC?
>
>
>>[ ]  31  $20  EVALC move corresponding from one data structure to
>>another.
>
>
> I'd vote for this if it can handle my environment, but I'm not sure it will.  
>I
> started a practice back on the S/34, where each physical file has a unique
> 2-character prefix used in all field names for that file.  This helped to 
>avoid
> name collissions since we did not have qualified DS naming.  Thus one file 
>might
> have fields xxCUST and xxNAME while the next has yyCUST and yyNAME, etc.
>
> In order for EVALC to move corresponding fields, the subfield names must 
>match.
> But mine never will, unless you can code something like PREFIX( '': 2 ) and 
>have
> the compiler *drop* two characters from the fieldname without replacing them.
> Or if we had a keyword to tell it to mask or ignore a given number of 
>characters
> for purposes of EVALC name matching, eg MASK(2).
>
> I don't think I'm alone in this scenario.  Is there any way EVALC can work 
>with
> conflicting prefixes on fields?  Or can PREFIX be enhanced to allow removal of
> existing prefixes?
>
> I'll spend my $20 elsewhere if EVALC would be useless to me.

Doug:  The function descriptions as listed are not cast in concrete.
  They're just a first rough cut description, and in most cases,
just represent a requirement and a proposed solution to the
requirement. One of the goals of the survey is to determine real
customer requirements, and not just the popularity of specific
proposed enhancements.

In this particular case, I'd suggest spending $20 on the item, with
an explanation written on your ballot as to what your specific need
is.  As it stands now, the description of #31 seems to suggest it
might only work with QUALIFIED data structures.  If you need more,
and I do understand your rationale, please let us know.  (Actually,
in this particular instance, you already have!)

I'm just *brainstorming* here, but one possible design might be to
have a (P) opcode extender on the EVALC opcode, which would take
prefixes specified using the PREFIX keyword into account.  And so if
you have one EDS defined with keyword PREFIX(ABC) and another with
keyword PREFIX(XYZ), an "EVALC(P) DS1=DS2;" operation would move
DS2.XYZDATA to DS1.ABCDATA.  (Although that perhaps should be the
default anyways???) This would work with externally described data
structures.  Something extra might be needed for program described
data structures, like "EVALC(P:2)"???  But then, what if source and
target have two different prefix lengths???  If that turns out to be
a popular item, we will of course spend more time fleshing out the
details.  Now is not the time to get into too much detailed design.

Cheers!  Hans