More than once, I've wished that pack/unpack were extensible to user-defined types. Upon scanning the RFC's, I found several relating to the pack and unpack system.

But, if the whole pack/unpack thing is moved out of the core, why does there have to be only one way to do it?.

That is, suppose the existing pack/unpack functions were supplied externally and you pulled it in, if desired, with use Legacy::Packing qw/pack unpack/;. You could have a totally different, unrelated, body of code to implement something fancy like RFC 142. There could be many different modules for this purpose.

OK, now here's my meta-feature.

Define a overall standard way to register types used for packing/unpacking. All pack/unpack type of modules would look in this same place for these definitions.

So, suppose I write class MyType and include methods to serialize and unserialize in a binary form. As the creator of that class, registering this fact once should make it available to any packing module.

Perhaps, ${^PACKING}{MyType}= [\&from_sub, \&to_sub ]; (using the current Perl5 syntax).

Now whether someone uses RFC 142's module and refers to that typename in a definition, or someone does a (hypothetical) Legacy::Packing->addtype (e => 'MyType');, that definition is available and more importantly, written by that type's provider.

—John

Replies are listed 'Best First'.
Re: Perl 6 wish list: pack/unpack meta-feature
by tadman (Prior) on Jul 26, 2001 at 08:28 UTC
    You could, of course, just make a better unpack and turn it into a module. I would think that adding user defined types would slow down unpack, which would make this kind of move very unpopular with people who's business revolves around packing/unpacking a lot of binary data.

    I have to admit that at times I'm also a little frustrated by the limitations of pack, especially when you don't have the sort of "stream" methods that you can get, say, in C++, where you can really go to town.

    Applying the TMTOWTDI principle, this would mean that the "traditional" way would be fast, but limited, and the "new" way, which is extensible, would be "better" at the expense of speed.

    The function names here are, of course, just for the example: 
    use Super::Unpack;

my ($foo,$lola,$glarb) = super_unpack ('int int MyType');
my ($foo,$lola,$glarb) = super_unpack (qw [ int int MyType]);
my ($foo,$lola,$glarb) = super_unpack (@spec);
my ($foo,$lola,$glarb) = super_unpack ('network unsigned int','short',
+'MyType');

    [download]
    With a few pre-defined "internal" types, such as 'int', 'long', and 'unsigned short', you could go places really quickly.

    Then this new module could be a Perl6 standard-issue thing, assuming people were open to this sort of idea.
[reply]
[d/l]
      There are several proposals for improvements to the traditional unpack, and a significant one for a new design. You ought to read that RFC.

      My point is that if it's moved out of the core, why be limited to just one "official" one?

      Also, I don't think adding user-defined types to traditional unpack would slow it down one iota. Consider: internally it switches on the letter and jumps to suitable code for that. Adding more entries for more letters will have no effect on the stuff that's already there.

      —John

[reply]
Re: Perl 6 wish list: pack/unpack meta-feature (boo)
by boo_radley (Parson) on Jul 26, 2001 at 17:36 UTC
    Here's something vaguely related in State of the Onion --
    Larry mentioned that overloading was a headache; you hate it in languages that have it, and you hate it when languages don't have it. Sometimes there are gratuitous abuses of overloading, such as C++'s left-shift operator to add more arguments to a function. The overloading system will be a lot cleaner, by specifying operators as special method names. The vtable system will be leveraged to provide overloading on objects. There will also be overloading hooks in printf so that new formats can be defined.

    he's probably open to the idea of custom (un)pack formats if he plans on custom printf formats, if the two aren't part & parcel.
[reply]
      I agree, if he's open to one he should like the other too. But I don't think they’re "part & parcel".

      We already have user-defined objects in printf, by virtue of their string-ize overload. %s will basically tell any object to render itself in the default manner.

      What I suppose he's talking about are formats like d for decimal and h for hex. Maybe define a way to specify rectangular or polar for complex numbers, for example.

      —John

[reply]

Back to Meditations