Ovid ha scritto:
--- Giacomo Cerrai <[EMAIL PROTECTED]> wrote:
With accessor methods this would be considerably more verbose:
foo({param => $val,
fields => { $SomeClass->FIELDNAME1 => $val1,
$SomeClass->FIELDNAME2 => $val2,
...
$SomeClass->FIELDNAMEn => $valn,
},
});
...
foreach my $field ($SomeClass->FIELD4, $SomeClass->FIELD2, ...,
$SomeClass->FIELD10) {
...
This becomes quickly unreadable and is not lazy.
Furthermore every fieldname access is a method call which is too much
overhead, especially when you have many fields to deal with.
A couple of problems here.
Yes, methods can sometimes be more verbose than variables, but Java
made a huge mistake by violating encapsulation. However, at least in
Java you get a little bit of type safety (not much, but some).
Just one note.
It's not clear from my post, I should have put a 'package SomeClass' or
$self->foo but the code above is in-class code, not meant as client code
(although you cannot prevent that).
It's important to optimize for correctness first. Readability *must*
come after correctness because if a program is incorrect, whether or
not it's legible is small consolation.
Also, if you're doing a huge amount of work with basic getter/setters,
perhaps revisiting your object heirarchy is worthwhile. The more I've
learned about OO, the more I've learned that it's about behaviors, not
Sorry again, I probably chose a wrong example.
I never do heavy get/set inside class hierarchies, and do almost no
get/setting at all from client code, it would be wrong.
The FIELDNAMEs above are names of fields that your class code uses to
refer to fields inside private data structures. You rarely set them, and
nobody outside the class (or subclasses) should ever even get them.
about data. Looking at data instead of behaviors can really hamper
effectiveness in OO systems because you become tied to the data when
what you really want is modeling of your problem domain's rules.
Since I agree with your comments it means I've not been clear regarding
the purpose of the module.
I totally agree with using accessor methods for class members in general.
In fact this is what I myself do most of the times. Sometimes though, I
use both accessor methods and package variables.
This module is meant for those times when I rely on package vars.
- Syntax convenience and time efficiency
The data I'm talking about are mostly logically constant data, which
you access very often and multiple times in the same statement.
Maybe you're crunching a db dump and speed matters.
I wish I could state those datamembers are 'really' constant, for
cleaness and efficiency, my module doesn't do that of course.
use constant is not an option either. It does not allow for inheritance
(access via object methods to those constants is not ok for the same
reasons i'm putting forward) and you loose on the syntax far too often.
You cannot interpolate into strings, cannot slice arrays and subscript
hashes with the standard syntax.
- It's a different approach
Apart from this, I think it would be cool and why not, reasonable,
to be able to inherit package variables.
Sometimes it can be useful, just don't misuse the feature.
regards,
Giacomo
Cheers,
Ovid
