Dirk Koopman <[EMAIL PROTECTED]> writes:
>> >
>> >$SBOL::ACCNO = $SYUS::LOGNAME;
>>
>> What doesn't exist? You have two packages and a variable in each package
>> there which of the four exist to perl.
>
>I express myself badly (not unusual). Yes, the variables exist and, even
>with strict on, cause no errors. I understand that both the packages
>(SBOL and SYUS) and the variables will have been auto-vivified in perl.
>However, the underlying 4GL(ish) will not be "connected".
>
>The real question is: whether I can intercept the process of
>vivification to do the necessary tying between the perl variable name
>and the actual underlying 4GL(ish) variable.
I am still having difficulty with your "jargon"
What is 4GL?
What is DD ?
(and even what is 'file' !)
>
>So if I can intercept the auto-vivification I can do this "behind the
>scenes".
>
>I wonder you could flesh this out a bit?
I hesitate to do that when I am far from clear we understand each other yet.
>Because: it would be quite
>straight forward for me (as part of the initialisation process) to
>create the packages by defining say the first DD entry in every file.
>
>That would create the packages and not use too much RAM.
How essential is it that perl code looks like:
>> >$SBOL::ACCNO = $SYUS::LOGNAME;
Would explict (exported) hash :
$SBOL{ACCNO} = $SYUS{LOGNAME};
do?
'tie' of %SBOL and %SYUS is much easier than
quasi-tie of %main::SBOL:: (the symbol table).
Or another trick that has been used is to overload (say) the '.' operator
$SBOL::ACCNO = $SYUS.LOGNAME;
but that only works on rhs.
>
>Dirk
