Re^3: do separate hashes share common keys?

Mark Jason Dominus gave a talk about the life and death of pseudohashes. (I’d heard of them but had no idea what they actually were before seeing this video.)

I infer from it that fields.pm originated as a convenient interface for pseudohashes and that after they went away fields.pm was kept around mainly for backwards compatibility and reworked to use restricted hashes.

I’d never played with fields.pm before, but I spent a few minutes with it just now and I can guess why it’s not very popular: it doesn't make much of an object. It doesn’t auto-generate accessors or a constructor. (Code is pasted below.) The attempted method call $blurple->blue blows up because there's no blue method. Also, the copy of %params into %{$self} will blow up if you pass any parameter name other than "red", "green", or "blue".

#!/usr/bin/perl

package RGBColor {
    use fields qw(red green blue);

    sub new {
        my RGBColor $self = shift;
        my %params = @_;

        unless (ref $self) {
            $self = fields::new($self);
        }

        %{$self} = %params;
        return $self;
    }
}

my $blurple = RGBColor->new(red => 75, blue => 200, green => 0);

print "blurple's blue is $blurple->{blue}\n";
print "blurple's blue is " . $blurple->blue ."\n";  # kaboom, no such 
+method
[download]

– Aaron
Preliminary operational tests were inconclusive. (The damn thing blew up.)

Comment on Re^3: do separate hashes share common keys? Select or Download Code

Replies are listed 'Best First'.
Re^4: do separate hashes share common keys? by LanX (Saint) on Feb 14, 2021 at 22:06 UTC
you missed to declare "blurple" as of type RGBColor use strict; use warnings; warn "running"; package RGBColor { use fields qw(red green blue); sub new { my RGBColor $self = shift; my %params = @_; unless (ref $self) { $self = fields::new($self); } %{$self} = %params; return $self; } } my RGBColor $blurple = RGBColor->new(red => 75, blue => 200, green => +0); print "blurple's blue is $blurple->{blue}\n"; $blurple->new(red => 175, blue => 100, green => 100); print $blurple->{orange}; ### BANGS AT COMPILETIME print "blurple's blue is $blurple->{blue}\n"; [download] OUTPUT `No such class field "orange" in variable $blurple of type RGBColor at +d:/tmp/pm/t_fields_pm.pl line 35. Compilation exited abnormally with code 255 at Sun Feb 14 23:04:10` [download] runs fine after uncommenting the orange line `running at d:/tmp/pm/t_fields_pm.pl line 5. blurple's blue is 200 blurple's blue is 100` [download] Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l] [select]
Re^5: do separate hashes share common keys? by bliako (Abbot) on Feb 15, 2021 at 19:57 UTC
`my RGBColor $self = shift;` Is this "typing" standard? First time I have seen this (excuse my ignorance).	[reply] [d/l]
Re^6: do separate hashes share common keys? by LanX (Saint) on Feb 15, 2021 at 20:11 UTC
> Is this "typing" standard? Well, it's documented, see `my`: `my TYPE VARLIST : ATTRS` But this is (unfortunately) the only use case (I'm aware of) Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l]
Re^4: do separate hashes share common keys? by LanX (Saint) on Feb 14, 2021 at 20:26 UTC
From memory of old experiments: I think "fields" means attributes not methods. And it's supposed to "boom" if an attribute is missing or typoed, even at compile time. So it's rather a hash with frozen keys (not "Yet Another OO Model"). But yes, the sparse documentation invites to misinterpretations. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^5: do separate hashes share common keys? by jcb (Parson) on Feb 14, 2021 at 22:20 UTC
I believe that Radiola is correct that fields was intended as an interface to pseudo-hashes. I remember documentation urging the use of fields because it was specifically intended as a forwards-compatible interface that would still work after pseudo-hashes were removed. Pseudo-hashes seem to have been recognized as a bad idea almost as soon as they were implemented. You are also correct that fields has nothing to do with object methods; Radiola is confused on this point, although the documentation is also confusing here, since `fields` is documented in OO terms.	[reply] [d/l]

OUTPUT