Re^2: Is "ref($class) || $class" a bad thing?

I am not sure I understand your point. I think you are trying to say that

$class = ref($class) || $class;
[download]

is no better/worse than

my $class = shift;
bless {}, $class;
[download]

which is quite true, and since that is also a common idiom which will produce the same issue, then maybe that is not so good either.

In all cases, $class is undef, and when bless is passed undef it blesses into main. It might (and I stress might, because I am not so sure of this) make sense if when bless encountered undef in its second argument, that it treated it as a one-argument bless instead (which would result in blessing into the current package).

-stvn

Comment on Re^2: Is "ref($class) \|\| $class" a bad thing? Select or Download Code

Replies are listed 'Best First'.
Re^3: Is "ref($class) \|\| $class" a bad thing? by chromatic (Archbishop) on Jul 12, 2004 at 19:52 UTC
I'm suggesting (as I think your conclusion supports) that if you have to abuse your API to test the possibilities that your code should support, you have a mismatch somewhere. There are reasons to call methods as subroutines in tests, but those are rare. If you've not violated Liskov substitutability, you can probably subclass appropriately. (If you have violated LSP, you should rethink your design. :)	[reply]
Re^4: Is "ref($class) \|\| $class" a bad thing? by stvn (Monsignor) on Jul 12, 2004 at 20:42 UTC
I'm suggesting (as I think your conclusion supports) that if you have to abuse your API to test the possibilities that your code should support, you have a mismatch somewhere. Well, if you want to support `Foo::new()` then it would not be abusing the API, it would be testing a feature. If you want to punish those who abuse your API, then I think it is appropriate to test it for the error/exception. However, if test it because you just want 100% coverage, then you probably just need to relax. I guess my feeling is that I want to punish those who abuse my API, maybe that is not so perl-ish, and maybe its a little control-freaky, but I like knowing that my module will perform as expected under both intended and unintended conditions. -stvn	[reply] [d/l]
Re^5: Is "ref($class) \|\| $class" a bad thing? by chromatic (Archbishop) on Jul 12, 2004 at 21:20 UTC
That's the part that confuses me. What does the "class or object method?" check in the constructor have to do with the "method or function call?" question? I think these are two different things altogether, but the original post and your previous comment here make me wonder if you think they're different.	[reply]
Re^6: Is "ref($class) \|\| $class" a bad thing? by stvn (Monsignor) on Jul 12, 2004 at 22:29 UTC
Re^7: Is "ref($class) \|\| $class" a bad thing? by chromatic (Archbishop) on Jul 12, 2004 at 23:26 UTC
Some notes below your chosen depth have not been shown here
Re^3: Is "ref($class) \|\| $class" a bad thing? by eric256 (Parson) on Jul 12, 2004 at 20:03 UTC
Would `$class = ref($class) \|\| $class \|\| __PACKAGE__;` make it work in that case? ___________ Eric Hodges	[reply] [d/l]
Re^4: Is "ref($class) \|\| $class" a bad thing? by dragonchild (Archbishop) on Jul 12, 2004 at 20:09 UTC
How does that fix `Foo::new( {} )`? ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply] [d/l]