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

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

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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 :-)