develooper Front page | perl.perl6.language.data | Postings from September 2000

Re: RFC 75 (v2) structures and interface definitions

From:
David L. Nicol
Date:
September 12, 2000 13:40
Subject:
Re: RFC 75 (v2) structures and interface definitions
Message ID:
39BE949B.5791DA03@kasey.umkc.edu
Chaim Frenkel wrote:
> 
> >>>>> "PRL" == Perl6 RFC Librarian <perl6-rfc@perl.org> 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 nicold@umkc.edu
           perl -e'map{sleep print$w[rand@w]}@w=<>' ~/nsmail/Inbox



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About