in reply to Re: Re: Re: Re: RFC : Pragma vs. Module
in thread RFC : Pragma vs. Module

These pseudohandlers could offer the right timing semantics, I guess. But how do you go about actually calling the CHECK and INIT blocks? Trying to call Foo::INIT() is a runtime error, because no such subroutine exists. I opine that it was a mistake to allow a sub INIT {} syntax, because their semantics are entirely distinct from subroutines — in particular, you can define any number of INIT or other special blocks and they'll accumulate, instead of overriding previous ones.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re^5: RFC : Pragma vs. Module
by stvn (Monsignor) on Mar 15, 2004 at 15:10 UTC

    I agree. Personally, I never use the sub INIT {} form, I always do the block form INIT {} it makes them look (a little) more distinct in the code.

    But how do you go about actually calling the CHECK and INIT blocks?

    I would likely move the code in INIT out into another sub, and have INIT call that (allowing it to fail in mod_perl since it only produces a warning, although this would not be okay if you had set the warnings to be fatal). Then check for the mod_perl env, and push a handler that calls the sub-formerly-known-as-INIT. This is of course a simple and untested approach, but it certainly a surmountable problem.

    -stvn
      But rather than making vanilla INIT work under mod_perl you're then introducing new semantics. Which mod_perl already has: the pseudohandlers you pointed out before.

      Makeshifts last the longest.

        I am in no way capable of making vanilla INIT work in mod_perl as I am not a C programmer, nor would I have any clue as to how to do that even if i was one. :-) So my only option (as i see it) to make Class::Trait work under mod_perl would be to do something like i described. Although, to be honest, I think I am going to look into avoiding using INIT altogether in Class::Trait.

        -stvn