Re^3: Seeking Wisdom: proposed fix for a broken CPAN module

It's better than it was, but it has two big problems as far as I am concerned:

As I said before I think mixing OO and functional/procedural styles in this way is almost always a bad idea. I cannot think of single instance in many years of coding where something like this would be an appropriate solution.
Since you don't use called_as_method things like OOorNO and myargs have so many caveats on their usage as to make them useless in the general case.

A few other commments after a quick skim.

Your synopsis just shows how to load the module, rather than how to use it. It doesn't mention the subroutines at all. You should be able to look at the synopsis and get a basic idea of how the module is used.

Something like is_called_as_method would be a better name for the OOorNO subroutine.

Why the bizzare, and undocumented, coercion of undef keys/values in coerce_array (which is badly named since it takes a list of values, and returns a hashref)? undef and the empty string are different values and should be treated as such.

The bulk of this module comprises a lightweight, pure-Perl emulation of the Devel::Caller library's "called_as_method()" routine which is written in C.

Why? There seems to be no point in re-inventing a wheel that works very well and replacing it with one that... well... doesn't :-).

You're subroutines fail in many cases. Consider:

Foo::foo( Foo => 12 );
Foo->foo( Foo => 12 );
[download]

This is really nasty since you can get inconsistant behaviour depending on what modules are loaded at the time. Basically, if you're first key is the same as a module name you're in trouble.

called_as_method is complex because it needs to be to work.

Comment on Re^3: Seeking Wisdom: proposed fix for a broken CPAN module Select or Download Code

Replies are listed 'Best First'.
Re: Re^3: Seeking Wisdom: proposed fix for a broken CPAN module by Tommy (Chaplain) on Jan 15, 2003 at 05:23 UTC
Since you don't use called_as_method things like OOorNO and myargs have so many caveats on their usage as to make them useless in the general case. Did you read/run the code snippets in the EXAMPLES section of the POD? Did you read the BUGS section of the POD docs for Devel::Caller? As I said before I think mixing OO and functional/procedural styles in this way is almost always a bad idea. I cannot think of single instance in many years of coding where something like this would be an appropriate solution. In theory, it's not such a mix as it might seem. I submit that, as polymorphism is one of the core principles of OO, this kind of inheritable (there's another one); shareable; importable/exportable; polymorphic interface is more extensible and useful than you claim; and more focused too. Why the bizzare, and undocumented, coercion of undef keys/values in coerce_array (which is badly named since it takes a list of values, and returns a hashref)? undef and the empty string are different values and should be treated as such The origin of this method's name has to do with what it does. One of the errors this helps avoid is also mentioned in the docs - "can't coerce array into hash at..." Be it as it may, I thought the name fitting when I wrote it that way. You have a good point about the undef-empty string observation. That should certainly be addressed in the code. Something like is_called_as_method would be a better name for the OOorNO subroutine. I don't know why I didn't see this, but as this was one of my primary questions (naming), I'm really grateful for your idea. You're subroutines fail in many cases. Consider: Foo::foo( Foo => 12 ); Foo->foo( Foo => 12 ); Did you test this? It doesn't fail in my tests or examples (which show in fact this very thing.) -- Tommy Butler, a.k.a. TOMMY	[reply]
Re^5: Seeking Wisdom: proposed fix for a broken CPAN module by adrianh (Chancellor) on Jan 15, 2003 at 17:36 UTC
Did you read/run the code snippets in the EXAMPLES section of the POD? Did you read the BUGS section of the POD docs for Devel::Caller? Yes and yes. Your code fails in several undocumented ways (see below). `called_as_method` does not. The issue with call frame optimisation for `called_as_method` would not apply for its use to implement the functionality of your routines. In theory, it's not such a mix as it might seem. I submit that, as polymorphism is one of the core principles of OO, this kind of inheritable (there's another one); shareable; importable/exportable; polymorphic interface is more extensible and useful than you claim; and more focused too. I think we are just going to have to agree to differ over this. In my experience mixing OO and functional/procedural APIs always causes more problems than it solves. The origin of this method's name has to do with what it does. In `$args = coerce_array($a, $b, $c, $d)` where is the array? :-) Coerced into what? The name does not describe what it does. Something like `list_to_hashargs` might be closer. Did you test this? It doesn't fail in my tests or examples (which show in fact this very thing.) No I didn't, since it was obvious from reading the code definition that it would fail. However, here are some tests to prove it. This isn't the only way they can foul up - try to find some more, then reconsider using `called_as_method` :-) Read more... (2 kB)	[reply] [d/l] [select]