Anyways as I say here I don't personally tend to use get/set methods much for personal reasons. After reading the article that I reference, you might find yourself reconsidering assumptions on OO design as well. But that is neither here nor there.
First some detailed comments. On clear programmer mistakes (calling a method as a function) you are not raising an error. That is an error and should be caught ASAP. Secondly I don't like the overloading of the return value. If I am returning to a scalar the result of getting a list of values, that will work fine until that array only has one element, then my code breaks. DWIM is something I am cautious of. If getting single values works, then single values will come up in scalar context. Thirdly attributes do not play well with inheritance in your model unless everyone is everywhere using your get/set routines. To me that is too restrictive.
About DBI, your understanding is only somewhat correct. If you wish to build a string SQL statement you would use NULL for null and "" for an empty string. However when querying from the database you get NULL as undef. Conversely if you use placeholders as DBI recommends, then you slam an undef value into the execute and you will populate the database with NULL values. In short, undef is Perl's version of NULL and both the native input and output respect that.
Finally I tend to consider APIs that needlessly restrict your data representations as somewhat to very broken. They are, at the least, an area of fragility that can lead to broken code. Certainly I work to avoid that, and I think my code is better for that decision.
Now here is (untested) a fragment of code that corresponds roughly to your get, implemented closer to how I would do it:
Since this is untested, there may be obvious typos. But this fixes all of the issues I identified and does some other things. First of all since raise is a method call, it is overridable. Secondly _get is a method call that can be overridden. Classes that want to have attributes accepted that don't fit with this _get can just write their own method, that then defaults to SUPER->_get. That way they can add things like computed fields.use Carp; sub get { my $self = shift; my @ret = map $self->_get($_), $self->coerce_args(@_); wantarray ? @ret : $ret[0]; } sub _get { my $self = shift; my $field = shift; exists $self->{"attrib_$field"} ? $self->{"attrib_$field"} : $self->raise("Object '$self' does not have attribute $field"); } sub raise { shift; goto &confess; }
Basically the watchword here is that if you want to get configurability, insert a method call. Place them roughly where you think people would want "hooks" into what you are doing, and you will get the configurability without having to code anything. An alternate way of thinking about it is that a method call already is a lookup into a dispatch table. So rather than code your own dispatch table that people need to interact with by your rules, just make a method call...
In reply to Re (tilly) 8: To sub or not to sub, that is the question?
by tilly
in thread To sub or not to sub, that is the question?
by tachyon
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |