Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > prevent further hash auto-vivification

Reply
Thread Tools

prevent further hash auto-vivification

 
 
Ben Morrow
Guest
Posts: n/a
 
      11-25-2006

Quoth Uri Guttman <(E-Mail Removed)>:
> >>>>> "BM" == Ben Morrow <(E-Mail Removed)> writes:

>
> BM> Quoth http://www.velocityreviews.com/forums/(E-Mail Removed):
> >>
> >> dear perl experts: how can I stop perl from auto-vivifying new keys in
> >> a hash? this seems like something that everyone would want as an
> >> optional feature in an object oriented context, isn't it? sincerely,

>
> BM> As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
> BM> from being added in any way (including autoviv). This feature was added
> BM> to support OOP, IIRC (it is a replacement for the deprecated pseudohash
> BM> semantics).
>
> i wouldn't say hash locking had anything to do with psuedo hashes.
> psuedos were intended to be a fast way to do object and look up their
> attributes. it was an unholy mess and was rightly ripped out of perl (i
> think it was finally removed in 5.8 after being deprecated for years).


No, they were removed in 5.9.

> maybe the locked hashes are useful to various OO implementation styles
> (inside out object don't need that AFAIK) but they aren't similar to
> psuedo hashes in any way i can see.


As of 5.9 fields.pm is implemented in terms of locked hashes instead of
phashes. This is what they were added to perl for: to keep the
'attribute checking' nature of phashes, which was deemed to be a benefit
of using fields.pm.

IOO don't use locked hashes; but as of 5.10 they will (or can, anyway)
use Anno's new 'fieldhashes', which cope correctly with
threads/overloading/re-blessing.

Ben

--
The cosmos, at best, is like a rubbish heap scattered at random.
Heraclitus
(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Brian McCauley
Guest
Posts: n/a
 
      11-25-2006

Uri Guttman wrote:
> >>>>> "BM" == Ben Morrow <(E-Mail Removed)> writes:

>
> BM> Quoth (E-Mail Removed):
> >>
> >> dear perl experts: how can I stop perl from auto-vivifying new keys in
> >> a hash? this seems like something that everyone would want as an
> >> optional feature in an object oriented context, isn't it? sincerely,

>
> BM> As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
> BM> from being added in any way (including autoviv). This feature was added
> BM> to support OOP, IIRC (it is a replacement for the deprecated pseudohash
> BM> semantics).
>
> i wouldn't say hash locking had anything to do with psuedo hashes.
> psuedos were intended to be a fast way to do object and look up their
> attributes. it was an unholy mess and was rightly ripped out of perl (i
> think it was finally removed in 5.8 after being deprecated for years).
>
> maybe the locked hashes are useful to various OO implementation styles
> (inside out object don't need that AFAIK) but they aren't similar to
> psuedo hashes in any way i can see.


....appart from the obvious similarity that pseudo-hashes had fixed keys
in exactly the same way as locked hashes have.

 
Reply With Quote
 
 
 
 
ivowel@gmail.com
Guest
Posts: n/a
 
      11-25-2006

thank you, everybody. Ben---this was exactly what I wanted.

Regards,

/iaw


Ben Morrow wrote:
> Quoth (E-Mail Removed):
> >
> > dear perl experts: how can I stop perl from auto-vivifying new keys in
> > a hash? this seems like something that everyone would want as an
> > optional feature in an object oriented context, isn't it? sincerely,

>
> As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
> from being added in any way (including autoviv). This feature was added
> to support OOP, IIRC (it is a replacement for the deprecated pseudohash
> semantics).
>
> Ben
>
> --
> Raise your hand if you're invulnerable.
> [(E-Mail Removed)]


 
Reply With Quote
 
Uri Guttman
Guest
Posts: n/a
 
      11-25-2006
>>>>> "BM" == Brian McCauley <(E-Mail Removed)> writes:

BM> Uri Guttman wrote:
>> >>>>> "BM" == Ben Morrow <(E-Mail Removed)> writes:

>>

BM> Quoth (E-Mail Removed):
>> >>
>> >> dear perl experts: how can I stop perl from auto-vivifying new keys in
>> >> a hash? this seems like something that everyone would want as an
>> >> optional feature in an object oriented context, isn't it? sincerely,

>>

BM> As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
BM> from being added in any way (including autoviv). This feature was added
BM> to support OOP, IIRC (it is a replacement for the deprecated pseudohash
BM> semantics).
>>
>> i wouldn't say hash locking had anything to do with psuedo hashes.
>> psuedos were intended to be a fast way to do object and look up their
>> attributes. it was an unholy mess and was rightly ripped out of perl (i
>> think it was finally removed in 5.8 after being deprecated for years).
>>
>> maybe the locked hashes are useful to various OO implementation styles
>> (inside out object don't need that AFAIK) but they aren't similar to
>> psuedo hashes in any way i can see.


BM> ...appart from the obvious similarity that pseudo-hashes had fixed keys
BM> in exactly the same way as locked hashes have.

but they weren't 'fixed'. you could always modify the hash in the 0 slot
of the psuedohash's array after creation. only the predefined keys would
be properly converted at compile time but keys added later could still
be looked up at runtime (and even more slowly than a regular hash!). so
psuedohashes didn't completely lock up the attributes anyhow.

uri

--
Uri Guttman ------ (E-Mail Removed) -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
 
Reply With Quote
 
Uri Guttman
Guest
Posts: n/a
 
      11-26-2006
>>>>> "BM" == Ben Morrow <(E-Mail Removed)> writes:


BM> As of 5.9 fields.pm is implemented in terms of locked hashes instead of
BM> phashes. This is what they were added to perl for: to keep the
BM> 'attribute checking' nature of phashes, which was deemed to be a benefit
BM> of using fields.pm.

BM> IOO don't use locked hashes; but as of 5.10 they will (or can, anyway)
BM> use Anno's new 'fieldhashes', which cope correctly with
BM> threads/overloading/re-blessing.

i tend to not use much inheritance as i prefer delegation in
general. objects owning objects makes more sense to me than objects
being a variant of another object. with delegation you don't worry about
sharing attributes and you should have no issues with those last issues
you mentioned. also delegation is a looser coupling than inheritance and
i am very much in favor of that.

uri

--
Uri Guttman ------ (E-Mail Removed) -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
 
Reply With Quote
 
Ben Morrow
Guest
Posts: n/a
 
      11-26-2006

Quoth Uri Guttman <(E-Mail Removed)>:
> >>>>> "BM" == Ben Morrow <(E-Mail Removed)> writes:

>
>
> BM> As of 5.9 fields.pm is implemented in terms of locked hashes instead of
> BM> phashes. This is what they were added to perl for: to keep the
> BM> 'attribute checking' nature of phashes, which was deemed to be a benefit
> BM> of using fields.pm.
>
> BM> IOO don't use locked hashes; but as of 5.10 they will (or can, anyway)
> BM> use Anno's new 'fieldhashes', which cope correctly with
> BM> threads/overloading/re-blessing.
>
> i tend to not use much inheritance as i prefer delegation in
> general. objects owning objects makes more sense to me than objects
> being a variant of another object. with delegation you don't worry about
> sharing attributes and you should have no issues with those last issues
> you mentioned.


Threads and GC will still be an issue. When a variable is cloned to
create a new thread, its refaddr changes, so you need a CLONE method to
deal with that; and when a variable is destroyed its fields will not be,
so you need a DESTROY method to handle that. Fieldhashes handle both
those cases for you, cleanly.

Ben

--
I have two words that are going to make all your troubles go away.
"Miniature". "Golf".
[(E-Mail Removed)]
 
Reply With Quote
 
Uri Guttman
Guest
Posts: n/a
 
      11-27-2006
>>>>> "BM" == Ben Morrow <(E-Mail Removed)> writes:

BM> Quoth Uri Guttman <(E-Mail Removed)>:
>> >>>>> "BM" == Ben Morrow <(E-Mail Removed)> writes:

>>
>>

BM> As of 5.9 fields.pm is implemented in terms of locked hashes instead of
BM> phashes. This is what they were added to perl for: to keep the
BM> 'attribute checking' nature of phashes, which was deemed to be a benefit
BM> of using fields.pm.
>>

BM> IOO don't use locked hashes; but as of 5.10 they will (or can, anyway)
BM> use Anno's new 'fieldhashes', which cope correctly with
BM> threads/overloading/re-blessing.
>>
>> i tend to not use much inheritance as i prefer delegation in
>> general. objects owning objects makes more sense to me than objects
>> being a variant of another object. with delegation you don't worry about
>> sharing attributes and you should have no issues with those last issues
>> you mentioned.


BM> Threads and GC will still be an issue. When a variable is cloned to
BM> create a new thread, its refaddr changes, so you need a CLONE method to
BM> deal with that; and when a variable is destroyed its fields will not be,
BM> so you need a DESTROY method to handle that. Fieldhashes handle both
BM> those cases for you, cleanly.

all these side issues are why i push event loops over threads. but
enough of that for now.

uri

--
Uri Guttman ------ (E-Mail Removed) -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
 
Reply With Quote
 
cmic
Guest
Posts: n/a
 
      11-27-2006
Hello.
(E-Mail Removed) a écrit :

> thank you, everybody. Ben---this was exactly what I wanted.


I'm sorry to a bit too late. Can I add something (and forgive me if it
I'm wrong )
There is a module called Tie::Hash::FixedKeys which can do the work for
you. If you try to insert a key which is not "authorized", Perl will
throw a run-time warning.

http://www.annocpan.org/~DAVECROSS/T...h/FixedKeys.pm

Not tested, though.
--
cmic just another Perl user (not a Guru)

>
> Regards,
>
> /iaw
>
>
> Ben Morrow wrote:
> > Quoth (E-Mail Removed):
> > >
> > > dear perl experts: how can I stop perl from auto-vivifying new keys in
> > > a hash? this seems like something that everyone would want as an
> > > optional feature in an object oriented context, isn't it? sincerely,

> >
> > As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
> > from being added in any way (including autoviv). This feature was added
> > to support OOP, IIRC (it is a replacement for the deprecated pseudohash
> > semantics).
> >
> > Ben
> >
> > --
> > Raise your hand if you're invulnerable.
> > [(E-Mail Removed)..uk]


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
hash of hash of hash of hash in c++ rp C++ 1 11-10-2011 04:45 PM
Hash#select returns an array but Hash#reject returns a hash... Srijayanth Sridhar Ruby 19 07-02-2008 12:49 PM
How to prevent duplicated entry in array of the hash Cyrus Perl Misc 19 12-22-2006 09:34 PM
How to prevent duplicated entry in array of the hash Cyrus Perl Misc 1 12-20-2006 11:47 PM
Part 2: How to prevent duplicated entry in array of the hash ...please Cyrus Perl Misc 1 12-20-2006 11:45 PM



Advertisments