develooper Front page | perl.perl5.porters | Postings from November 1999

Re: [PATCH 5.005_62] First round of unpack

Thread Previous | Thread Next
From:
Ilya Zakharevich
Date:
November 2, 1999 18:41
Subject:
Re: [PATCH 5.005_62] First round of unpack
Message ID:
19991102214104.A74@monk.mps.ohio-state.edu
On Wed, Oct 27, 1999 at 03:14:35PM -0400, Joshua N Pritikin wrote:
> >        $packed = pack 't', \%data;
> >        system 'foo', $packed;
> > 
> >        $data = unpack 't', shift;
> 
> Ilya, if this is where you are leading then why not advocate including
> Storable in the main tarball instead?

Simple:  AFAIU, Storable is useless for many tasks.  Say, it is
useless in the above example, since with Storable $packed is almost
guarantied to contain an embedded '\0'.

The needs of marshalling are very different for different
targets, which leads a need to write a marshall/unmarshall code
for each of this targets.  Now let us look: can this be simplified?

The answer is YES: one needs different marshalling code, but this does
not mean that one needs different unmarshalling code!  How one would
write a "universal" unmarshaller?  Obviously, one needs to store
unmarshalling instructions together with stringified data.

This leads to unpack 't' which I wrote.  

Note that the current version I have comes together with a matched
pack 't', but pack-t is very primitive and restricted.  As usual, what
is important is to have a well-designed *extractor*.  Given this, one
can write different "compressors" which all will work with the same
extractor and will answer different needs.  Say, I'm sure one can
easily add an option to Storable and FreezeThaw to generate data in
the format of such an extractor.

And I'm pretty sure that the format supported by unpack 't' is both
flexible enough and efficient enough, so that it is good for almost
any application.

Now: why in the core?  One of the reasons is that it deserves it
;-). for other reasons see below.

Why not in a module?  The closest Perl interface to extraction is
unpack().  Reusing existing infrastructure of unpack() allows to write
unmarshalling code in 170 additional lines of C.  It increases the
size of unpack() PP-handler by 1/6th only.  Doing it in a separate
compilation unit will make things much more complicated and
error-prone.

And again: (un)marshalling *belongs* to pack()/unpack().  It is
exactly the semantic of these operations.

And: the stuff added to pp.c is only 4 times the stuff for the support
for BER integers.  Now compare the usefulness of these features.  ;-)

Hope this helps,
Ilya

Thread Previous | Thread Next


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