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
