From @nwc10

It seems that a fairly common pairing in the perl source is​:

  tmpsv = newSV(0);
  gv_efullname3(tmpsv, gv, NULL);

or generating a new mortal and passing it in.

All functions in the gv_e?fullname{,3,4} family are ultimately wrappers
around gv_fullname4(), which currently returns void, and takes a not NULL
first argument.

It would probably reduce the core's code size to change it to return SV *,
and generate a new SV (possibly mortal) if the first argument is NULL.

Nicholas Clark

From @tonycoz

On Fri, Jan 15, 2010 at 08​:46​:43AM -0800, Nicholas Clark wrote​:

# New Ticket Created by Nicholas Clark
# Please include the string​: [perl #72108]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=72108 >

It seems that a fairly common pairing in the perl source is​:

    tmpsv = newSV\(0\);
    gv\_efullname3\(tmpsv\, gv\, NULL\);

or generating a new mortal and passing it in.

All functions in the gv_e?fullname{,3,4} family are ultimately wrappers
around gv_fullname4(), which currently returns void, and takes a not NULL
first argument.

It would probably reduce the core's code size to change it to return SV *,
and generate a new SV (possibly mortal) if the first argument is NULL.

Instead of overloading the interface, wouldn't it be better to add
extra functions that create the GV, and then calls gv_e?fullname4().

The new functions could be marked with the R flag to make sure the
returned new GV isn't ignored.

Tony

The RT System itself - Status changed from 'new' to 'open'

From @nwc10

On Mon, Jan 18, 2010 at 10​:29​:00AM +1100, Tony Cook wrote​:

On Fri, Jan 15, 2010 at 08​:46​:43AM -0800, Nicholas Clark wrote​:

It seems that a fairly common pairing in the perl source is​:

    tmpsv = newSV\(0\);
    gv\_efullname3\(tmpsv\, gv\, NULL\);

or generating a new mortal and passing it in.

All functions in the gv_e?fullname{,3,4} family are ultimately wrappers
around gv_fullname4(), which currently returns void, and takes a not NULL
first argument.

It would probably reduce the core's code size to change it to return SV *,
and generate a new SV (possibly mortal) if the first argument is NULL.

Instead of overloading the interface, wouldn't it be better to add
extra functions that create the GV, and then calls gv_e?fullname4().

The new functions could be marked with the R flag to make sure the
returned new GV isn't ignored.

That's a good point.

Do you have any suggestions for a name? [in 32 or fewer ASCII characters :-)]

Nicholas Clark

From @tonycoz

On Sun, May 30, 2010 at 02​:19​:11PM +0100, Nicholas Clark wrote​:

On Mon, Jan 18, 2010 at 10​:29​:00AM +1100, Tony Cook wrote​:

On Fri, Jan 15, 2010 at 08​:46​:43AM -0800, Nicholas Clark wrote​:

It seems that a fairly common pairing in the perl source is​:

    tmpsv = newSV\(0\);
    gv\_efullname3\(tmpsv\, gv\, NULL\);

or generating a new mortal and passing it in.

All functions in the gv_e?fullname{,3,4} family are ultimately wrappers
around gv_fullname4(), which currently returns void, and takes a not NULL
first argument.

It would probably reduce the core's code size to change it to return SV *,
and generate a new SV (possibly mortal) if the first argument is NULL.

Instead of overloading the interface, wouldn't it be better to add
extra functions that create the GV, and then calls gv_e?fullname4().

The new functions could be marked with the R flag to make sure the
returned new GV isn't ignored.

That's a good point.

Do you have any suggestions for a name? [in 32 or fewer ASCII characters :-)]

Maybe​:

  gv_new_e?fullname{,3,4}

though it sort of implies creating a new GV. Otherwise​:

  gv_e?fullname_new_sv{,3,4}

Tony

From @dcollinsn

On Sun May 30 16​:42​:19 2010, tonyc wrote​:

On Sun, May 30, 2010 at 02​:19​:11PM +0100, Nicholas Clark wrote​:

On Mon, Jan 18, 2010 at 10​:29​:00AM +1100, Tony Cook wrote​:

On Fri, Jan 15, 2010 at 08​:46​:43AM -0800, Nicholas Clark wrote​:

It seems that a fairly common pairing in the perl source is​:

tmpsv = newSV(0);
gv_efullname3(tmpsv, gv, NULL);

or generating a new mortal and passing it in.

All functions in the gv_e?fullname{,3,4} family are ultimately
wrappers
around gv_fullname4(), which currently returns void, and takes a
not NULL
first argument.

It would probably reduce the core's code size to change it to
return SV *,
and generate a new SV (possibly mortal) if the first argument is
NULL.

Instead of overloading the interface, wouldn't it be better to add
extra functions that create the GV, and then calls
gv_e?fullname4().

The new functions could be marked with the R flag to make sure the
returned new GV isn't ignored.

That's a good point.

Do you have any suggestions for a name? [in 32 or fewer ASCII
characters :-)]

Maybe​:

gv_new_e?fullname{,3,4}

though it sort of implies creating a new GV. Otherwise​:

gv_e?fullname_new_sv{,3,4}

Tony

Nicholas,

Have you made any progress on this ticket, or discovered anything that would block it? It seems to me that this is a simple request to add some functions, and a potentially time-consuming task to review the codebase and change to the new functions where applicable. Has this fallen by the wayside because the benefits are relatively minor, or because there's a problem?

--
Respectfully,
Dan Collins