Front page | perl.bootstrap |
Postings from July 2000
Re: perl 6 requirements
From:
Glenn Linderman
Date:
July 31, 2000 13:50
Subject:
Re: perl 6 requirements
Message ID:
3985E6FC.B617C765@Linderman.com
Edwin, Buddha, Ted,
Each of your additions to my idea sounds better. Too bad we don't have a list
to discuss this on.
Edwin, the concept of having the formats tied to the variable names (or hash
indexes, or something) is great. Then the script author writes the data
definitions, but it is up to the implementation to choose whether to do
complete or partial unpack/pack operations, or to generate 2 functions for each
data element to read/write each data element. Certainly the latter could be
done, but is gross to have to write, and the complete pack/unpack could be done
in a couple subs, but I perceive that to be ineffecient. I wouldn't even want
to think about coding partial pack/unpack by hand, it'd be another special
purpose cache tied to each such structure... but as a general built-in
technique, if the hash entry was undef, you could call the read function for
the corresponding element. And when accessed in scalar context, call all the
write functions for modified elements.
Regarding how rigid such variables would have to be: I think a null-terminated
or counted string could be variable length, resulting in a variable length
structure. Defining null-terminated strings in both fixed and variable length
fields could be useful. And offsets to the variable length strings could be
other elements in a fixed length front portion. And then you could have
counted arrays of substruct, which could be variable length when the count
changes. I've seen parameters to APIs (some in Win32, some elsewhere) that do
stuff like that. The Win32 low-level security APIs probably have the most
complex parameters of APIs I've run across recently, if you want to see some
"real" examples.
The fixed length portions are most important, of course, as they occur much
more frequently. But the non-rigid parts could be extremely useful when
needed... but can be dealt with as simpler packs, since generally you're
dealing with a fixed-length portion followed by a bunch of variable length
strings. and you could piece things together with simple packs of these fixed
length structure/hashes.
Edwin Wiles wrote:
> Buddha Buck wrote:
> > The pack/unpack has to happen at sometime. Perhaps what would work would
> > be to create a module or core type that would remember its pack
> > format. Ideally, when used in a scalar context, it would look like its
> > packed representation; when in a hash context, like its unpacked
> > representation. Something like:
> >
> > # game message data consists of objectID; position x,y,z; orientation
> > # ux,uy,uz (up direction) and nx,ny,nz (nose direction), velocity
> > # vx,vy,vz, and acceleration ax,ay,az all as 32-bit integers in network
> > # byte order (packet size: 512B). Object ID of 0 means update complete.
> > #
> > # $packet pre-defined to have a pack format of "NNNNNNNNNNNNNNNN"
> > {
> > sysread SERVER, $packet, 512;
> > last if $packet{'objectID'} == 0;
> > $remoteobject[$packet{'objectID'}] = { %packet };
> > }
> >
> > Is that sort of what you'd like?
>
> Would this be any better than writing up your own little perl module to
> handle the task using the existing unpack/pack commands?
>
> Or could we make this a generalized perl module, with format definitions
> tied to variable names.... Hmmm... I think I'll give this a bit more of
> a look. It could be very useful to me, maybe useful for perl 6, and
> certainly useful for perl 5.
>
> For perl 5, it would certainly be a normal 'module', but for perl 6, it
> might be part of the basic distribution.
>
> I'll check the existing packages first... no need for another square
> wheel.
>
> Edwin
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html