Re: Sweetest Accessor?

Xiong Changnian <please@xxxxxxxxxx> wrote in comp.lang.perl.misc:
In article <56ut5uF2ammm2U1@xxxxxxxxxxxxx>,
anno4000@xxxxxxxxxxxxxxxxxxxxxx wrote:

Many fields
take values that happen to be false...

Well, yes; depends on your application. The stuff I'm doing now, this
doesn't usually come up. I make it *not* come up.

Well, your question came around as being about the style of general-
purpose accessors. I would not recommend a general-purpose accessor
that doesn't transfer certain values.

[snip]

I particularly don't
care for mixing shift and @_ in the same sub -- visually.

Why?

I'd like to respond to your question but I'm not sure how; it's just a
stylistic or gut feeling. For complex subs, I like the idiom of shifting
all the params into my variables; it puts a nice little self-documenting
declaration block up top.

That isn't tied to shifting. The most self-documenting way of
parameter assignment would have to be:

my ( $name, $age, $occupation) = @_;

Shifting parameters off @_ is done for various reasons:

- You want to deal with each parameter individually before you
enter the body of the sub

my $name = shift || 'anonymous';
my $age= shift || 0;
my $occupation = $default_occupation[ $age];

- You want to get things out of the way and deal with the
remaining arguments uniformly

my $mode = shift;
for ( @_ ) { # ...

- In method calls, you shift off the invocant (class or object)
to make the content of @_ conform to the parameters given at
the call site;

$obj->meth( $name, $age, $occupation);

# corresponds to

my $obj = shift;
my ( $name, $age, $occupation) = @_;

Now that I've been fooling around awhile, I'm
starting to see the limitations and inefficiencies in this and I'm
trying things the other way. One bone I have to pick with @_ is that it
allows me to clobber the actual param, which I generally don't want to
do. Also, after a lifetime of subscripting, I'm straining now to avoid
it. On the other hand, there are elegant @_ and $_[$n] approaches.

These are usually restricted to small (one-line) subs. If anything
substantial goes on in the sub body, assignment of parameters to
named variables is the norm. Unless you *want* to change an argument,
or do other things that don't work on a copy.

BTW, shift() as such doesn't stop you from changing a parameter.
"

If it makes me look like a more reasonable person, my generic new shifts
for the class, then passes @_ to init.

Right, that's one of the cases I mentioned. And congratulations for
providing a separate initializer. It's all too often forgotten.

[snip lvalue, except]

the calling context. Throw in prototypes and a little overloading and I
can imagine writing some lucid code in the caller. Now, if I could only

You can't throw prototypes into an OO design. Prototypes are ignored
in method calls. In general, prototypes appear to introduce more
problems than they solve. It is true that they let you (sometimes)
design a particularly intuitive interface. Restrict prototypes to
such cases, don't use them as a matter of course.

Overloading goes a much longer way in the direction of intuitive
interfaces, but is also not without problems. In a general-purpose
class the user should be able to opt out of overloading.

Anno
.

Relevant Pages

  • Re: marine subroutine
    ... but you get a warning like: ... Use Prototypes at the beginning of your file if you want to write the ... sub foo { ... my $s = shift; ...
    (perl.beginners)
  • Re: marine subroutine
    ... but you get a warning like: ... Use Prototypes at the beginning of your file if you want to write the ... sub foo { ... my $s = shift; ...
    (perl.beginners)
  • Re: Module help
    ... Subroutine prototypes, like "" here, generally cause more harm than ... sub are_these_arrays_equal { ... my $one = shift; ...
    (perl.beginners)
  • sitemap generator for Perl
    ... I want to run the sitemap generator ... Returns the minimum number of links to traverse from the root URL of ... my $class = shift; ...
    (perl.beginners)
  • Re: Re: Difficult shift from 1st to 2nd
    ... >> There is the possibility your clutch isn't disengaging enough, ... check your shifter pedal to make sure that it is clamped ... So the shifter drum has to be rotated further to shift ... >> second than it has to move shifting from second to third, ...
    (rec.motorcycles.tech)