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

Re: restricted hashes, and other readonlyness (was "clamp...")

Thread Previous | Thread Next
From:
Nick Ing-Simmons
Date:
November 3, 2001 15:07
Subject:
Re: restricted hashes, and other readonlyness (was "clamp...")
Message ID:
20011103230702.26246.2@bactrian.ni-s.u-net.com
Michael G Schwern <schwern@pobox.com> writes:
>On Sat, Nov 03, 2001 at 01:26:45PM +0000, Nick Ing-Simmons wrote:
>> I would like concrete examples of places where delete-ing keys is 
>> vital to the application.
>
>*tap tap tap*  Hello?  Is this thing on?

Certainly - so far yours is the only example that has made a reasonable
case. But was a little sketchy for my taste.

It is also missing what to me is the fundamental point.

A struct-oid is not to be thought of as a hash - if you stop thinking of 
it that way it stops hurting. The problem with pseudo-hashes was 
people treated them as hashes ... the problem with fixed-key hashes it 
people _know_ they are hashes.

If you want a hash use a hash. But can we have a cheap efficient struct-oid 
for the places where it makes sense?

"My car broke when I filled it with kerosene" is not a reason to 
mandate that all filling stations must provide lead replacement petrol
at all pumps - let alone insist all vehicles run on one fuel. 
The kerosene should never have been there, you should have known better. 
Other users (truckers, greens ...) may have different needs.

"My complicated class did not like pseudo hashes as a base class"
is no reason to say every perl construct must support exists,
let alone "must support delete so we can support exists".

I want "unleaded hashes" because they are better for my enviromnent.
If your old class needs "traditional leaded hashes" then they are still
available. But please don't insist on "lead replacement only" - that 
is more expensive than either and probably more noxious than the leaded
stuff... and smells as bad as the kerosene.

>
>Object persistence with caching.

Unless I am missing something that is not compelling.

In order for the object to have its keys "fixed" something 
has to itterate through the persistant store and enumerate the keys.
It would seem to me that while we are doing that we may as well cache
them - and hence they are all present.

-- 
Nick Ing-Simmons
http://www.ni-s.u-net.com/


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