--- TSa <[EMAIL PROTECTED]> wrote:
> Daniel Ruoso wrote:
> > In fact, I doubt that there's a way to completely avoid any
> possible
> > side effects on this closures. as the very first line of the
> closure
> > shows:
> >
> > $_.inside_of(...)
> >
> > This is a plain method call, there's no way to tell if this method
> > will change anything inside the object or not.
>
> Well, we could use something to the effect of const methods in C++.
> That is we have a trait on a method that prevents changes of the
> object. And these could be the only ones allowed in where blocks.
The problem Daniel mentions is that in a dynamic language like Perl,
you just can't prevent side-effects. Consider:
eval $foo;
Does that have side effects or not? There's no way to know and yet
there are plenty of examples one could potentially construct which
would have non-obvious side-effects.
I would love to be able to introspect the code to know whether or not
any operators or keywords with known side-effects are in a given block
of code, but even then that would depend on the context (of the code,
not Perl's "context"). For example, should the pre/postfix '++' be
listed as having a side-effect?
sub side_effect { return $_[0]++ }
sub no_side_effect { my $x = shift; return $x++ }
In Perl 6, since arguments to subs would have to be specifically
written as 'is rw', we might be able to minimize this issue, but I
don't know if we can stop it.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
