Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: use fields; # damnit

by stvn (Monsignor)
on Aug 20, 2004 at 21:38 UTC ( #384713=note: print w/ replies, xml ) Need Help??


in reply to use fields; # damnit

The problem is that there's a general myth about fields, that that's all you're supposed to do, and that because it doesn't work, and to top it off uses pseudohashes, fields is bad.

My reason for not using fields has always been that in most of the books I was reading (Programming Perl 3rd Ed. and Damians book) would tell you about them and the 'Typed' my variables (and get my hopes up) and then tell you that they were built with pseudohashes which are an experimental feature and only to be used with caution, there might changes, etc. etc. etc. the usual warnings. Thus implying that use fields might also be a dangerous practice. I mean if it worked perfectly, more people would surely use this technique right? (at least that was my logic at the time).

So I guess my question to you (and everyone else) is, are fields really ready for real world usage? Can I get these benifits today, without the risk of using "experimental" features?

-stvn


Comment on Re: use fields; # damnit
Select or Download Code
Re^2: use fields; # damnit
by nothingmuch (Priest) on Aug 20, 2004 at 21:49 UTC
    I use it in production code. The benefit is good enough for me that I will hold back an upgrade of Perl to keep using it, if needed.

    Either way, there's already patches for compile time support in 5.9 which does not use pseudohashes. If it gets merged (and it better), 5.10 should keep the same support, and i think that's a long time from now.

    At the bottom line, nobody in their right mind will take away this feature, especially from a languge whose motto is There Is More Than One Way To Do It. The worst I can foresee is that it might change a bit.

    -nuffin
    zz zZ Z Z #!perl

      So, I am inspired, and I have been messing around with fields. But I am seeing some what seems to me to be odd behavior. (I am running perl 5.8.0 installed on Mac OS X, so maybe I need to update, if so, let me know.)

      package Brain; use strict; use warnings; use fields qw/cells/; sub new { my $pkg = shift; my $self = $pkg->fields::new(); $self->{cells} = shift; $self; } package Dog; use strict; use warnings; use fields qw/intelligence/; sub new { my $pkg = shift; my $self = $pkg->fields::new(); my Brain $brain = Brain->new(shift); $self->{intelligence} = $brain; $self; } sub getBrain { my Dog $self = shift; return $self->{intelligence}; } package main; use strict; use warnings; my Dog $dog = Dog->new(10); my Dog $brain = $dog->getBrain(); my Brain $b = $brain;
      This compiles and runs with no error or warning. Am I doing something wrong, or am I just assuming too much?

      Sorry for this question, but my Programming Perl book does not go into too much detail (at least not that I have come across yet) and the Damian OO book is at the office (and I am not). And looking over the docs for fields it is not clear either.

      -stvn
        The syntax my Dog $brain declares that $brain is a Dog, and therefore everything that can be done with $brain has to be something that a Dog can do.

        These are compile-time tests on the container $brain.

        There is no runtime check in Perl 5 about whether the value put into $brain actually is a Dog. And the following line cannot be construed as a code error - after all nothing stops someone from making a class that inherits from both Dog and Brain!

        Field checking doesn't have much to do with accessors, or ISA checks. Reading the rest of your thread, I'd like to summarize.
        package Dog; use fields qw/intelligence/ sub new { my $pkg = shift; my Dog $self = $pkg->fields::new(); $self->{intelligence} = shift; $self; } sub intelligence { my Dog $self = shift; $self->{intelligence}; }
        That's the code you're responsible for. Lets say the accessor for 'intelligence' had a typo, and accessed the field 'inteligence'. Without using fields and typed variable declarations, you would not get any erros.

        This won't compile, and is broken:

        sub intelligence { my Dog $self = shift; $self->{inteligence}; # typo }

        And normally people would write

        sub intelligence { my $self = shift; $self->{inteligence}; # typo }
        and the code would compile correctly, but is just as broken.

        useing fields is meant to help you write your classes a bit cleaner, and is a bit like trying to catch typos in variable names. Just using $foo wouldn't work normally if there's no such variable, yet perl will only complain with use strict. Using a variable to store the intelligence value, $intelligence, and typoing it the next time around to $inteligence is the best analogy I can find for getting your field names wrong, and that's where use fields; helps.

        -nuffin
        zz zZ Z Z #!perl
Re^2: use fields; # damnit
by adrianh (Chancellor) on Aug 21, 2004 at 07:57 UTC
    So I guess my question to you (and everyone else) is, are fields really ready for real world usage?

    Well, there are certainly people using it out there in the wild.

    That said, I don't and won't use them myself for three reasons.

    First, there are reasons why pseudo-hashes are being deprecated. Until the non-pseudo fields has been out for a couple of releases I'm not going to use them.

    Second, to use them we have to control the base-class. Often I'm coding in places where I don't control the base class. Since I like consistency throughout the code fields aren't that useful to me.

    Can I get these benifits today, without the risk of using "experimental" features?

    The third reason I don't use them is that I can get the benefit of compile-time field name typo checking (and other benefits too) by using Abigail's inside out objects technique - without having to touch any experimental features.

      First, there are reasons why pseudo-hashes are being deprecated. Until the non-pseudo fields has been out for a couple of releases I'm not going to use them.

      The point is that fields is guaranteed to keep working the way it does. That it uses pseudohashes is an implementation detail you are not supposed to care about.

      Of course, your objection that it requires knowledge about the implementation of the base class is valid and a good reason not to use it anyway.

      Makeshifts last the longest.

        The point is that fields is guaranteed to keep working the way it does. That it uses pseudohashes is an implementation detail you are not supposed to care about.

        Yeah I realise that :-)

        The point I was trying to make was that right now fields are implemented using pseudo-hashes. Since pseudo-hashes have problems that I want to avoid I won't be using fields until they're implemented using restricted hashes (or whatever) and the new release has been out enough for the bugs to have been stomped on.

      Adrianh, I don't understand what you mean by "we have to control the base-class." I thought the fields pragma played well with inheritance. Could you give a concrete example where this would be a problem?

      ps, I just posted a followup to this thread at Should I use Fields, InsideOuts, or Properties?.

        Adrianh, I don't understand what you mean by "we have to control the base-class." I thought the fields pragma played well with inheritance. Could you give a concrete example where this would be a problem?

        The fields pragma only plays well with classes that have also been built with the fields pragma.

        If I want to subclass a class that's based around a blessed hashref or coderef then I'm out of luck.

        Since I often code with classes than I do not control (e.g. classes from CPAN) that are not implemented with pseudohashes I can't use the fields pragma with them.

        Make sense?

        OK, I get it. Thanks.
fields-like module to facilitate arrayref objects
by davidnicol (Acolyte) on Aug 21, 2004 at 22:52 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://384713]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2014-12-22 00:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (110 votes), past polls