Front page | perl.perl5.porters |
Postings from July 2012
On 6 July 2012 16:38, Jesse Luehrs <doy@tozt.net> wrote: > On Fri, Jul 06, 2012 at 01:28:49PM +0100, Nicholas Clark wrote: >> On Thu, Jul 05, 2012 at 10:46:26PM -0700, Andreas J. Koenig via RT wrote: >> >> > f041cf0f9c6469c41de8b73d5f7b426710c3ff8b >> > 5f9f83be9cdcd54449f7f40db078fe367d780475 >> > We cannot bisect more! >> >> For information: >> >> $ git log f041cf0f9c6469c41de8b73d5f7b426710c3ff8b^! 5f9f83be9cdcd54449f7f40db078fe367d780475 >> commit 5f9f83be9cdcd54449f7f40db078fe367d780475 >> Author: Rafael Garcia-Suarez <rgs@consttype.org> >> Date: Tue May 22 17:23:20 2012 +0200 >> >> Fix mktables bug due to the previous overload fix >> >> Due to the previous patch, perl can't generate the operator for .= in >> package Property anymore (because fallback is '0' in that package), so >> we need to work around that; this patch implements the least intrusive >> workaround possible. >> >> commit f041cf0f9c6469c41de8b73d5f7b426710c3ff8b >> Author: Rafael Garcia-Suarez <rgs@consttype.org> >> Date: Tue Mar 20 09:17:02 2012 +0100 >> >> Lookup overloaded assignment operators when trying to swap the arguments >> >> This is in the case where we search for an overloaded operator when >> passing the AMGf_assign flag (we're executing an assignment operator >> like +=). >> >> At the very beginning of Perl_amagic_call, if the flag AMGf_noleft is >> not passed, we first try to look up the overload method corresponding >> to the assignment operator, then the normal one if fallback is >> authorized. However, if this fails, when trying later to find >> overload magic with the arguments swapped (if AMGf_noright is not >> passed), this procedure was not used and we looked up directly the base >> operation from which the assignment operator might be derived. >> As a consequence of what an operator like += might have looked >> autogenerated even when fallback=>0 was passed. >> >> This change only necessitates a minor adjustment in lib/overload.t, >> where an overloaded += method wasn't corresponding semantically to the >> overloaded + method of the same class, which can be seen as a >> pathological case. > > One more reason that I think we should revert this change. > Do you think the fix is incorrect ? It actually cleans up a part of the overload code that was not symmetrical and sanitizes the semantics of overload generation.Thread Previous | Thread Next