Front page | perl.perl5.porters |
Postings from July 2012
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. -doyThread Previous | Thread Next