Re^2: Class::MethodMaker, workplace politics, and patches

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.

Comment on Re^2: Class::MethodMaker, workplace politics, and patches Download Code

Replies are listed 'Best First'.
Re^3: Class::MethodMaker, workplace politics, and patches by BrowserUk (Patriarch) on Feb 12, 2005 at 10:07 UTC
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]

Replies are listed 'Best First'.

Re^3: Class::MethodMaker, workplace politics, and patches
by BrowserUk (Patriarch) on Feb 12, 2005 at 10:07 UTC

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]