|
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.
| [reply] |
|
|
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.
| [reply]
[d/l] |
|
|
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!
| [reply]
[d/l] |
|
|
|
|
|
|
|
|
|
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.
| [reply]
[d/l]
[select] |
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.
| [reply] |
|
|
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.
| [reply] |
|
|
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
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?
| [reply] |
|
|
| [reply] |
fields-like module to facilitate arrayref objects
by davidnicol (Acolyte) on Aug 21, 2004 at 22:52 UTC
|
| [reply] |