autobox

[Michele Dondi]

In a recent thread Tassilo v. Parseval said that the autobox
package/perl patch (besides pointing me to it - BTW: thanks!!) has
been rejected by p5p.

Now, I've tried it and I must say it is *cool* to say the least! So,
can anyone explain quickly the reason why it has been rejected? I know
I may ask directly there, but due to constraints of time and of lack
of technical know how on my part I'll try here: it's only a matter of
curiosity...


Michele

 

[Tassilo v. Parseval]

Also sprach Michele Dondi:

In a recent thread Tassilo v. Parseval said that the autobox
package/perl patch (besides pointing me to it - BTW: thanks!!) has
been rejected by p5p.

To be more precise, it hasn't been formerly rejected. It was discussed
in length in a time when Jarkko was very busy preparing 5.8.1.
Eventually the topic was sort of postponed but never picked up again.

Now, I've tried it and I must say it is *cool* to say the least! So,
can anyone explain quickly the reason why it has been rejected? I know
I may ask directly there, but due to constraints of time and of lack
of technical know how on my part I'll try here: it's only a matter of
curiosity...

You find the complete thread starting with this article here:

http://tinyurl.com/3cegc

Tassilo

 

[Michele Dondi]

You find the complete thread starting with this article here:

http://tinyurl.com/3cegc

TY, I've read it at length: hope they will change their mind first or
later! BTW: since it has not been mentioned in that thread, but it has
here, what goes on with qr//?!? i.e., does it return a *blessed*
refence into Regexp or does perl just fake it has? Also, I'd like to
know what those objecting that autoboxing is not consistent with
current Perl's semantics think about this particular, isolated,
instance of autoboxing...


Michele

 

[Tassilo v. Parseval]

Also sprach Michele Dondi:

TY, I've read it at length: hope they will change their mind first or
later! BTW: since it has not been mentioned in that thread, but it has
here, what goes on with qr//?!? i.e., does it return a *blessed*
refence into Regexp or does perl just fake it has?

It's a real blessed object with some qr-specific magic attached to it.

Also, I'd like to know what those objecting that autoboxing is not
consistent with current Perl's semantics think about this particular,
isolated, instance of autoboxing...

The discussion following the suggested patch was IMO not very rational.
The main reason against it appeared to be that it reminded some people
of pseudo-hashes. However, they weren't really able to give any evidence
for potential problems that could arise from it. Those examples that
were given did in fact turn out to be false alarm.

I don't know, maybe it should be put onto the agenda once again. I
wouldn't expect much from it, though. I also have the impression that the
birth of ponie has made it more difficult to get new features into Perl
as people now say that one should wait for perl5.12. This happened to me
anyway when I proposed to extend the tie() interface with stuff like
SUBSTR, INDEX etc. for which I provided an outline on how this could be
implemented.

Tassilo

 

[Michele Dondi]

[snip]
The discussion following the suggested patch was IMO not very rational.
The main reason against it appeared to be that it reminded some people
of pseudo-hashes. However, they weren't really able to give any evidence

I've noticed that, in fact! However I don't even know what
pseudo-hashes are actually... already heard about them, though!

for potential problems that could arise from it. Those examples that
were given did in fact turn out to be false alarm.

I got that impression too.

I don't know, maybe it should be put onto the agenda once again. I
wouldn't expect much from it, though. I also have the impression that the
birth of ponie has made it more difficult to get new features into Perl
as people now say that one should wait for perl5.12. This happened to me
anyway when I proposed to extend the tie() interface with stuff like
SUBSTR, INDEX etc. for which I provided an outline on how this could be
implemented.

Hmmm, that sounds interesting!


Michele

 

[Tassilo v. Parseval]

Also sprach Michele Dondi:

You find the complete thread starting with this article here:

[snip]
The discussion following the suggested patch was IMO not very rational.
The main reason against it appeared to be that it reminded some people
of pseudo-hashes. However, they weren't really able to give any evidence

I've noticed that, in fact! However I don't even know what
pseudo-hashes are actually... already heard about them, though!

You can forget about them now. They've been deprecated in perl5.8.0 and
'use fields' is now implemented on top of restricted hashes. In perl5.10
pseudo-hashes will be removed altogether.

Hmmm, that sounds interesting!

Of course it does. ;-)

I had the idea of writing a module that makes Perl scalars store their
content zlib compressed so that people could put very large strings into
them (provided that these strings can be compressed well; ordinary text
strings usually can) and trade speed for space. But then I realized that
the first time someone did

substr($compressed, 1, 1);

perl would translate that into

substr( tied($compressed)->FETCH, 1, 1 );

and that gave me no chance to only inflate the needed parts of the
string. So I had to abandon my idea.

Tassilo

 

[Michele Dondi]

Of course it does. ;-)

After your explanation below, indeed it still does, but...

I had the idea of writing a module that makes Perl scalars store their
content zlib compressed so that people could put very large strings into
them (provided that these strings can be compressed well; ordinary text
strings usually can) and trade speed for space. But then I realized that
the first time someone did

substr($compressed, 1, 1);

perl would translate that into

substr( tied($compressed)->FETCH, 1, 1 );

and that gave me no chance to only inflate the needed parts of the
string. So I had to abandon my idea.

....apart from "historical" reasons, would this really be a good
example? I must admit that I'm particularly ignorant on the matter,
but would it be easy/efficient to to "only inflate the needed parts"
of the string?!?

[Just curious, and -I stress it- ignorant! Please do not answer if you
have any higher priority]


Thanks,
Michele

 

[Tassilo v. Parseval]

Also sprach Michele Dondi:

On Tue, 27 Apr 2004 06:13:19 +0200, "Tassilo v. Parseval"


...apart from "historical" reasons, would this really be a good
example? I must admit that I'm particularly ignorant on the matter,
but would it be easy/efficient to to "only inflate the needed parts"
of the string?!?

Sadly, no. One can't just take the string and compress it into one
smaller string. It would have to happen chunkwise, otherwise parts of it
couldn't be retrieved selectively. In my draft I used this structure:

typedef struct _string {
Bytef *chunk;
uLongf size_compressed;
uLongf size_uncompressed;
uLongf size_total;
struct _string *next;
struct _string *first;
struct _string *last; /* for easier concatenation */
} STRING;

which is essentially a linked list of string chunks ('chunk' in the
above would be the compressed data) of, say, 4k bytes or so. The larger
they are, the better the compression would be. This would have allowed
to find out which chunk(s) to decompress if someone had wanted to carry
out an action on parts of the string.

My implementation hardly reached alpha status and I remember that some
data needed more memory than just using an ordinary Perl scalar. And it
was SLOW.

But it was also fun to write. It would have been a nice proof of
concept. Well, it certainly did prove that it cannot be done.

[Just curious, and -I stress it- ignorant! Please do not answer if you
have any higher priority]

As if any of the regulars here could afford to have a life of their own
beyond this group. ;-)

Tassilo