Re: var watcher behaviour

On Tue, Feb 08, 2000 at 05:26:08PM +0100, [email protected] wrote:
> Hm, on the other hand, while writing this a thought arrived: this special kind of
> difficulties only occurs if I watch READ access, doesn't it? If I would have limited
> the watcher to write accesses, only a single callback would have been performed. So
> I assume most variable watchers will watch write access. So the problem could be
> "solved" by documenting that it is EXTREMELY difficult to use READ var watchers,
> that a user should expect MANY callback invokations which almost noone can predict,
> and that he should check the events "got" attribute very carefully in such callbacks
> to avoid multiple actions for the same event. (Of course, this is only a solution if
> we can be sure that ALL perl statements which MODIFY a variable result in only ONE
> internal write access. Am I right?)

How's this?

  Var watchers generate events when the given variable is read from or
  written to.  As perl is a concise language, it is often difficult to
  predict when a variable will be read.  For this reason, variable
  watchers should poll for writes unless you know what you are doing.

> > The implicit join does another read of the variable.
> 
> Ah, thanks for your research!
> 
> I assume the second implicit join() was optimized by the runtime engine?

Eh?  Which join are you talking about?  When you have:

  warn "a"."b"."c";

It turns into:

  warn join('',"a","b","c");

-- 
"May the best description of competition prevail."
           via, but not speaking for Deutsche Bank