develooper Front page | perl.perl5.porters | Postings from December 2013

[perl #115736] newATTRSUB_flags has an undocumented bitfield/flags and misc about newATTRSUB

Thread Previous | Thread Next
From:
James E Keenan via RT
Date:
December 14, 2013 00:30
Subject:
[perl #115736] newATTRSUB_flags has an undocumented bitfield/flags and misc about newATTRSUB
Message ID:
rt-4.0.18-23413-1386980998-730.115736-15-0@perl.org
On Wed Nov 14 20:05:06 2012, sprout wrote:
> On Wed Nov 14 18:33:58 2012, bulk88 wrote:
> > This is a bug report for perl from bulk88@hotmail.com,
> > generated with the help of perlbug 1.39 running under perl 5.17.6.
> >
> >
> > -----------------------------------------------------------------
> > [Please describe your issue here]
> >
> > In
> >
> http://perl5.git.perl.org/perl.git/commitdiff/7e68c38b607a044ee5879e316bb8a7347284ec8e
> > Father Chrysostomos added a flags parameter to newATTRSUB. The flags
> > parameter is undocumented and is using plain numeric flags
> >
> http://perl5.git.perl.org/perl.git/blob/09c759566a430d381e168ae0530363f206c90715:/op.c#l7325
> > . Can I request that flags param either be renamed to a bool or t/f
> > param parameter that described what is does, or a macro define be
> > made
> > to give that 1 a readable name?
> >
> > I'd like to do some cleanup of newATTRSUB_flags but that line is
> > bothering me since I might (I don't have a full plan right now in my
> > head for what I'll change) have to write (flags & 1) more times than
> > it
> > already is written.
> 
> The only reason for that flags parameter is that, while newATTRSUB’s
> interface might be perfect for the parser, it is extremely unhelpful
> if
> you already have a GV you want to add the new sub to.
> 
> So I just did the quickest thing.
> 
> I have tried about three times to break newATTRSUB into smaller
> reusable
> subs so that gv.c:S_maybe_add_coresub doesn’t have to go through
> newATTRSUB at all, but with no success.  (My attempts just made things
> more complicated.)  That would still be a good thing, if possible, to
> avoid code duplication between newATTRSUB and newMYSUB.
> 
> >
> > I am leaning towards a t/f than a "flags" since there is only 1 flag
> > right now (see end for more detailed rambling) and since
> > newATTRSUB_flags isn't public, it can be renamed or upgraded back to
> > _flags from _bool or _x (x=extended)  (guessing names) in the future
> > if
> > more flags will need to be added, but I dont know the future or have
> > a
> > clear cut implementation (names, or t/f vs flags, or future flags) in
> > my
> > head.
> 
> That’s fine with me.
> 
> >
> > Here are the callers of the "old" newATTRSUB in blead
> > Perl_newSUB
> > Perl_pmruntime (2 calls)
> > Perl_utilize
> > Perl_newANONATTRSUB
> > Perl_yyparse
> >
> > As a side discussion to consider, I might (not decided/more research)
> > replace their calls to newATTRSUB with newATTRSUB_flags (or whatever
> > it
> > is renamed to if it looses its "flags") to avoid indirection, leaving
> > newATTRSUB strictly as an export or converting newATTRSUB to a macro
> > (CPAN grep gives me ~4 distros that use newATTRSUB).
> 
> If you want to remove the extra sub call (gcc optimises it away, BTW),
> I
> would suggest leaving those callers alone and making newATTRSUB a
> macro.
> 
> >
> > Since Father Chrysostomos authored that commit, I am CCing him.
> 
> No need to do that, as I see almost everything that goes through RT.


bulk88, Father C:  Can we get an update on the status of this ticket?

Thank you very much.
Jim Keenan

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=115736

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About