Re: RFC 75 (v2) structures and interface definitions

Chaim Frenkel wrote:
> 
> >>>>> "PRL" == Perl6 RFC Librarian <[email protected]> writes:
> 
> PRL>    %DataHash = unpack $mypic, $SomePackedCobolData;
> 
> Does it unpack it into the hash? Or does it keep a pointer into
> the original structure?

I'd think it would depend on if %DataHash is defined already.  For
unpack() to return a list of key/value pairs is not all that different
from just returning values the way it does now.  For unpack to return
a tied object that refers to a copy of the initial data, that is a little
bit more different but it is within possibility.

 
> What happens when a new key is added to the hash?

that may or may not be possible, I'd like to discuss it further
before declaring one way or the other.
 
> What happens if the underlying structure is overlayed?
> 
>         sysread(FOO, $SomePackedCobolData, $length);
>         %DataHash = unpack $mypic, $SomePackedCobolData;
>         sysread(FOO, $SomePackedCobolData, $length);
> 
> <chaim>

Perl data accessors generally create copies to avoid these "action at
a distance" situations such as the case where %DataHash is composed
of offsets into a scalar which gets redefined.  Perl5's unpack function
creates copies.




These issues presuppose a "closed hash" data type, and its internal
representation.  Why don't you write the RFC that answers these questions?


How would you like to see your coboldata represented and used as a
perl hash?



-- 
                          David Nicol 816.235.1187 [email protected]
           perl -e'map{sleep print$w[rand@w]}@w=<>' ~/nsmail/Inbox