Re: Is it morally wrong to use consant's as methods in a package?

The current implementation of constants pretty much sucks anyway, since it fails in so many places (HERE docs, hash keys, and anywhere else that barewords are stringified). The way you're talking about using it is basically to treat it as an obfuscated method generator. Why not just code the methods explicitly, so that people don't have to know about the implementation of the constant pragma to understand your code?

Comment on Re: Is it morally wrong to use consant's as methods in a package?

Replies are listed 'Best First'.
Re(2): Is it morally wrong to use consant's as methods in a package? by dmmiller2k (Chaplain) on Mar 13, 2002 at 18:58 UTC
I agree that Perl's idea of constants sucks. It is probably because there ain't no such thing as a constant in perl that the whole inlined subroutine thing emerged; it was probably stumbled upon by some hapless developer, and grew into common usage from there. The short answer to the original question, which I thought I saw you alluding to the first time I read your response, is that using constants as methods pretty much does away with the compiler's inlining optimization (since a method lookup must now be done at runtime), which is most of why to do it in the first place. The whole namespace argument doesn't hold up since it is far clearer to say, `Module::CONST_VALUE` (and get the benefit of inlining, as well) than `$objOfSomeHardToDetermineType->CONST_VALUE`. dmm If you GIVE a man a fish you feed him for a day But, TEACH him to fish and you feed him for a lifetime	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re(2): Is it morally wrong to use consant's as methods in a package?
by dmmiller2k (Chaplain) on Mar 13, 2002 at 18:58 UTC

I agree that Perl's idea of constants sucks. It is probably because there ain't no such thing as a constant in perl that the whole inlined subroutine thing emerged; it was probably stumbled upon by some hapless developer, and grew into common usage from there.

The short answer to the original question, which I thought I saw you alluding to the first time I read your response, is that using constants as methods pretty much does away with the compiler's inlining optimization (since a method lookup must now be done at runtime), which is most of why to do it in the first place.

The whole namespace argument doesn't hold up since it is far clearer to say, Module::CONST_VALUE (and get the benefit of inlining, as well) than $objOfSomeHardToDetermineType->CONST_VALUE.

dmm

If you GIVE a man a fish you feed him for a day
But, TEACH him to fish and you feed him for a lifetime

[reply]
[d/l]
[select]