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

Replies are listed 'Best First'.
Re^2: Is "ref($class) \|\| $class" a bad thing? by kscaldef (Pilgrim) on Jul 12, 2004 at 17:19 UTC
The point, such as it is, is that in order to cover all three possible evaluations of the conditional, you have to make that meaningless call. This, of course, sucks. Now, probably the answer is that 100% code coverage isn't always possible or desirable. On the other hand, I've seen large (hundreds of classes) systems where every constructor included `ref $class \|\| $class`, and nowhere was any of them ever called using an existing instance. So, that's just silly. If you never use the constructor in this way, you might as well just drop it. As a minor side-effect, you get your code coverage a little higher, and maybe that makes your manager happy or something.	[reply] [d/l]
Re^2: Is "ref($class) \|\| $class" a bad thing? by stvn (Monsignor) on Jul 12, 2004 at 17:24 UTC
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	[reply] [d/l] [select]
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
Re^6: Is "ref($class) \|\| $class" a bad thing? by stvn (Monsignor) on Jul 12, 2004 at 22:29 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]


Syntactic Confectionery Delight
	PerlMonks