Re^3: Distinguish between missing and undefined arguments with subroutine signatures (semipredicate problem)

[LanX]

> combined getter/setter ... Return the value when called without an additional arg,

from my experience are mutators written in a way to always return the value.

> A call with an undefined arg clears the attribute - just like in my example.

OK ... but in that case why do you have a default value at all?

Anyway, if you want to allow to set to undef and don't wanna introspect @_ , then you're stuck in a kind of semipredicate problem.

Such problems can be solved in Perl by setting a new "impossible"° object MISSING as default, like

use constant MISSING => bless {}, "MyPackg::__Missing__"

and later

sub mutator ($value = MISSING) { ...BODY... }

(untested)

If you see that an arguments equals to that "impossible" value blessed into your own private namespace below "MyPackg", you can be sure that it wasn't used by accident.

HTH! :)

update

clearer rewording, clearer code

°) of course it's possible that such a value is used, but extremely unlikely without intend.

[jo37]

use constant MISSING => bless {}, "MyPackg::__Missing__"

That's a very good solution.

Thx.

[LanX]

> That's a very good solution.

Thanks, that's my favorite solution for the semipredicate problem. :)

But in this particular case, I'd say checking @_ is better.

[jo37]

OK ... but in that case why do you have a default value at all?

I don't want a default value. To my understanding it is needed for an optional value argument in a signature.

[LanX]

> To my understanding it is needed for an optional value argument in a signature.

Ah ... I see. Using a slurpy parameter @settings will solve this and fits much better into your use-case.

from perlsub

After positional parameters, additional arguments may be captured in a slurpy parameter. The simplest form of this is just an array variable:

sub foo ($filter, @inputs) {
    print $filter->($_) foreach @inputs;
}

[jo37]

Using a slurpy parameter @settings will solve this and fits much better into your use-case.

Sadly, it does not. I already considered this. It does not prevent the sub from being called with more arguments than allowed.