Front page | perl.perl5.porters |
Postings from August 2010
On Wed, Aug 4, 2010 at 23:45, Jan Dubois <jand@activestate.com> wrote: > On Wed, 04 Aug 2010, demerphq wrote: >> On 29 July 2010 18:23, Abigail <abigail@abigail.be> wrote: >>> On Fri, Jul 16, 2010 at 12:18:48AM +0200, demerphq wrote: >>>> I agree, and I think that Jan's comment: >>>> >>>> <quote> My personal opinion is that any FETCH magic or overloaded >>>> operator that has observable side effects is essentially broken and >>>> abusing a feature. You can always use a function or method call if >>>> you need exact control over how your code is being called. </quote> >>>> >>>> should, after appropriate editing, be added to the documentation for >>>> tie as well. >>> >>> I *strongly* disagree with this sentiment. >>> >>> Part of the appeal of a tied variable is that you can throw it at a >>> piece of code you do not control (or do not want to change). >>> >>> Saying one could just replace uses with a function or method call >>> would have been a great argument when the tieing mechanism was first >>> introduced - but we're way past this point now. >> >> IMO this is FUD. >> >> This is about ties with observable side effects. Not about using ties at all. > > I don't think it is FUD, but I consider it wishful thinking. > Abigail already found 14 test cases where his assumption doesn't > hold, and I'm sure there are plenty more (I already posted one > earlier in this thread, that is not covered by his new tests). > > It will be very hard to get the core to call FETCH only once per > "logical access" to a variable, and it will be *impossible* to get this > right for most CPAN modules containing XS code. You are lucky if XS code > gets magic handling right to begin with, but to make sure you never call > FETCH more than once is really hard, given that it may be called as a > side effect of some other operation (like using SvIV(sv), which may call > sv_2iv(), which may call FETCH magic). > > It will also be almost impossible to write comprehensive tests for this > behavior, even just for the core, as we will not only have to cover all > code paths, but all code paths with all the different combinations of > flags on each SV. For example the number of FETCH calls for ++ is 2 if > the sv is SvNOK, but not SvIOK, but only 1 in most other cases. > > So while we could strive to come as close as possible to the ideal of > calling FETCH only once per logical access, we should still warn users > that having a FETCH with side effects *is* very brittle in Perl and > should be avoided. I don't think the point is that we should *guarantee* that FETCH will only be called once per "logical access". But that we shouldn't make any guarantees *at all*. I.e. explicitly document that if you write a tie class you shouldn't depend on how many times FETCH and friends are called, since they may be called by the core at unexpected times, and those times may change without warning in future releases. That'd leave the core free to change or optimize the internal tie semantics, and any module that breaks as a result could get the "I told you so" treatment. This is a good policy for internal APIs in general. E.g. the perlreapi will often call your callbacks unexpectedly and seemingly redundantly. When you write the callbacks you have to anticipate that and write code that doesn't break down as a result of a callback being called 1 or 10 times.Thread Previous | Thread Next