develooper Front page | perl.perl5.porters | Postings from October 2001

Re: Clamp, wherefor art thou

Thread Previous | Thread Next
Nick Ing-Simmons
October 30, 2001 11:25
Re: Clamp, wherefor art thou
Message ID:
Jeffrey Friedl <> writes:
>Nick Ing-Simmons wrote:
>|> I think that allowed (but not existing) entries in HV could be represented
>|> by having an HE but with its SV * being Nullsv - or perhaps a pointer
>|> to a "special" SV
>In the patch I submitted, Pl_sv_undef is used (as per Tim's suggestion
>when the thread appeared before). It's a very clean approach.

Ah yes I remember if SV * is &PL_sv_undef then it is allowed but does 
not exist, while if SV * is pointer to another SV which has SvOK off 
then it exists but is undefined. Safer than Nullsv - any code which 
was poking at HEs and does not understand the new convention sees 
the entry as existing but undef rather than coredumping following Nullsv.

>|> I don't think special casing "scalar keys" is necessary - the allowed keys
>|> are counted so the existing count in the header is fine.
>I suppose that there's no real "right" answer to this, but it makes sense to
>me to have "scalar keys" return the same number as items you get back with
>an array "keys". 

That would be the case either way. Without the special casing keys %hash
would return the allowed keys. (Which as I think about it is quite useful
- it can answer the question what can I put in this hash ?)

So I propose we _define_ keys on a read-only hash to return the allowed 
keys (i.e. ones which have HEs) - this should just "fall out" of existing 
code and data structures. 

If you really need it one could write a utility function that did:

   grep {exists $h{$_}} keys %h

>With Tim's suggestion, it's implemented w/o additional
>storage overhead, and no real computational overhead[*]
>Once it's in the core, you can export it to the user however you like,
>providing ways to get the number of keys there, allowed, existing, etc...
>|> What I really do not like is the 'Clamp' name - it does not suggest to me
>|> anything vaguely like the proposed semantics.
>With the core-only patch, it allows people to export the functionality as
>they wish. I'm sure that as people play with it and see what others do, a
>clear winner will emerge that will probably be better than anything I/we
>could design "by committee".

Soon or later the 'modules' Committee is going to rule on the name(s) 
anyway - it is probably worth thrashing the interface a bit longer here.

>      Jeffrey
>[*]The way the counts are implemented in the patch I just submitted is
>fairly light weight (one extra integer increment per hash element addition
>or subtraction), 

and an extra word (8%) in every hash header. If I have millions of hash based 
objects that is fair amount of extra memory.

>but I just thought of a way that it could be done with no
>overhead for those operations in the normal (non-clamp) case. I'll either
>make the change to the next patch, or make an incremental patch if the
>previous one gets applied......
Nick Ing-Simmons

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About