in reply to Class::MethodMaker, workplace politics, and patches

I'm probably misunderstanding your post, or the POD, but doesn't this snippet from the C::MM pod indicate that when you reset something, the is_set() method return false? And isn't that the behaviour you are after? 

  my $m = MyClass->new;
  my $a, $x;

  $a = $m->a;       # *undef*
  $x = $m->a_isset; # false
  $a = $m->a(1);    # 1
  $m->a(3);
  $x = $m->a_isset; # true
  $a = $m->a;       # 3
  $a = $m->a(5);     # 5;
  $m->a_reset;
  $x = $m->a_isset; # false

[download]
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.

Replies are listed 'Best First'.
Re^2: Class::MethodMaker, workplace politics, and patches
by dragonchild (Archbishop) on Feb 11, 2005 at 19:02 UTC
    You missed the part about it having a default_ctor. Use of -default_ctor or -default changes the behavior of *_isset(). I'm not arguing the design decision, but I want to be able to turn off the optimization.

    Here's a testcase to demonstrate what I'm talking about. 

    use strict;

use Test::More 'no_plan';

package Bar;

sub new { bless {} }

package Foo;

use Class::MethodMaker [
    new => 'new',
    scalar => [
        { -type => 'Bar', -default_ctor => 'new' }, 'bar',
    ],
];

package main;

my $foo = Foo->new;
isa_ok( $foo, 'Foo' );

my $bar = $foo->bar;
isa_ok( $bar, 'Bar' );

$foo->bar_reset;
ok(
    !$foo->bar_isset,
    "No get() after reset(), so why is it set()?"
);
-----------------
ok 1 - The object isa Foo
ok 2 - The object isa Bar
not ok 3 - No get() after reset(), so why is it set()?
1..3

    [download]

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
[d/l]

      I have to say, that having read a bit more about C::MM and how it works, I disagree with teh change you are making.

      You question (in the tests) is:

    • "If I've reset() an attribute and not yet done a get() or set(), why does it test as isset()?"

      And I would say, because it has a default.

      Therefore if you did do a get(), a value would be returned, and that value would be a real value--even if it was undef because the default was set to be undef.

      So, the envisioned use of _isset is to allow the caller to determine if they will get a legitimate value when they call get()--even if when they do call it they get undef.

      But you appear to be trying to use isset() as if it were isreset(), or possibly _isdefault().

      Which may be a desirable test to be able to perform for some reason other than testing that _reset() works--which is C::MM's test suite responsibility, not yours--but if it is, then it has different semantics to _isset and should probably be a different method.

      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom