Re: Other Globals in %once

On Wed, 28 Apr 2004, David Wheeler wrote:

> On Apr 28, 2004, at 4:47 PM, Dave Rolsky wrote:
>
> > Well, first of all, _we_ only have control over the Mason request
> > object var (and the Apache request var, too), so this wouldn't really
> > have helped with Bricolage, because Mason can't set those for you.
>
> Yes it does, because I use set_global() to tell Mason to set them. So
> it does, but only after the %once block has executed.

If you're calling set_global _before_ executing a component, then those
globals should be available in the <%once> block.  If they're not, that's
a bug, I think.

> Yes, so my point is that you're not really avoiding problems by
> disallowing it, but you are preventing folks from, for example, using a
> function component to determine what to assign to a persistent (that
> is, %once block) variable by calling it with $m->comp(). This is a drag
> in low persistence environments such as a single Bricolage burn.
>
> So I return to my original question: What are the downsides to my
> setting up those globals before Mason does? That is, of not using
> set_global()?

Hmm, there is no downside, is there?  In fact, I'd say that's a better way
to do it:

  {
      local $In::Package::burner = $self;

      ... # exec comp
   }

That looks better than calling set_global, I'd say.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click