Re^4: on the fly methods

Changing to $code->isa('CODE') in this case would actually break 99% of use cases...

So would changing to fileno $code, but I didn't suggest that either.

I don't really care if the naive approach satisfies 99% of the use cases for two reasons. First, I've had well-used code on the CPAN for years that tends to break in messy ways when people use quick hacks instead of well-tested, working code. Second, plenty of people pick up on bad idioms and use them without realizing where they fail and what they break. This leads to even more people breaking my code. and complaining to me and I just can't fix the problems.

I'd love to see a test case for when eval { defined &$code } fails. I couldn't come up with one. I even tried it with overloaded objects.

Comment on Re^4: on the fly methods Select or Download Code

Replies are listed 'Best First'.

Re^5: on the fly methods (put up...)
by tye (Sage) on Feb 28, 2007 at 02:21 UTC

Then write a module that provides routines (not methods) that satisfy your exacting standards or stop whining.

Most of the time when I come across these cases, I find several choices of what to do and none of them are perfect and it isn't easy to figure out if I'm overlooking some bizarre code (such as chromatic's "well-used code on the CPAN" that breaks in the face of the techniques that most people end up using).

I often punt and use UNIVERSAL::isa( $var, "TYPE" ) and assume that people who do really strange stuff can always just push @ISA, "TYPE" if they need to.

I can't afford to spend the amount of effort that you would require to support a slightly old version of Perl just to try (and probably fail) to figure out how to get my code to work with that last 1% of weird cases.

For years I've felt that Perl needed better ways to determine "is this a hash reference" and what we got was more ways to do it and other changes that made none of the ways perfect still. So now we've got lots of not perfect ways and lots of confusion.

In one case (Data::Diver), I wanted to be extra precise so I resorted to something like eval { my $x= $ref->[0]; 1 } but that can't be used to test for CODE refs (and one can still write objects that don't tollerate such very well, but I really consider such objects broken at this point).

So I test for CODE refs by using isa() as a function. And I'm sure I'll do that many more times until someone comes up with the obviously better solution. And the following isn't obviouisly better to me:

( eval { $ref->can("isa") } || \&UNIVERSAL::isa )->( $ref, "TYPE" )
[download]

because it is dang ugly and I'm not going to type that over and over (and I'm not sure that it is a 100% solution and it took me several tries to even come up with that).

I've seen people fighting about "isa" and "UNIVERSAL" and "AUTOLOAD" and I've mostly come away with the impression that AUTOLOAD is broken in design and should have instead been designed to return a code ref and there is no perfect solution to this design oversight and there are several conflicting camps about the "right" way to deal with it and I haven't seen a clear winner so I don't write code that assumes any one of those camps.

So provide the obviously better solution.

- tye

[reply]
[d/l]
[select]


There's more than one way to do things
	PerlMonks