[prev in list] [next in list] [prev in thread] [next in thread]
List: perl5-porters
Subject: Re: Should core support reftype, refaddr, weaken?
From: demerphq <demerphq () gmail ! com>
Date: 2020-05-29 12:18:51
Message-ID: CANgJU+XBQHy1Rk1bUMxw3QmDoPQ-vHFwvzATahYgnpvjti-8kQ () mail ! gmail ! com
[Download RAW message or body]
On Fri, 29 May 2020 at 12:39, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:
> On Fri, 29 May 2020 08:43:46 +0200
> demerphq <demerphq@gmail.com> wrote:
>
> > Nonsense. It doesn't "support" them. They are undocumented
> > side-effects of our value caching strategy. Where does the *perl*
> > docs say we have dualvars? Where does it discuss them? Scalar::Util
> > isnt an answer, its NOT the core, even if its bundled with the core.
> > So can we do away with that argument please? It doesn't hold water.
>
> Alright; well I'm happy to put dualvars on the side for now. Between
> you and haarg there seems to be some objection to making it official
> core API. I can continue to copypaste my polyfill function around
> between XS files to handle it.
>
>
> But I'd like to continue on this question of Scalar::Util not being
> core. If that really is the case, then there are a bunch of other
> things that core also doesn't support, but are in very widespread use:
>
> * reftype
> * refaddr
>
I consider these core. We changed the core to make them more efficient
even. Also to a certain exent reftype() is deprecated in fact of Ref::Util
90% of the time.
>
> * weaken, isweak, etc..
>
Yeah, this is a real edge case. As in the same argument applies to them as
does reftype()/refaddr() to a certain extent. Support was added to the core
to make them work, but we never really embraced them in the core or IMO
they would be full on SV types and not their weird hybrid thing they
currently are. I would be a lot more ok with adding them to the core than
dualvar personally.
>
> * blessed
>
Core.
>
> If it isn't the case that Scalar::Util represents official core API
> policy, then it seems that core doesn't actually provide pureperl users
> any way to operate on reference types/addresses (i.e. to see through the
> weird cloak that is `ref` on a blessed reference), nor to operate on
>
Fair argument, although i would say that they are basically optimizations
of operations you could perform in pure perl using ref() and regexes, along
with overload::StrVal().
Whereas something like a dualvar cant be constructed from just perl
semantics.
> weakrefs at all. But I am pretty sure that those things are officially
> supported operations by core. A *lot* of CPAN uses these things that
> even if we hadn't intended to claim them supported, we're now stuck
> having to continue to handle them as we do now. If core hadn't intended
> to support dualvars either, then it is perhaps pure luck that nowhere
> near as much of CPAN is using those, as compared these other functions.
>
> I wonder if then, we should look at moving some of these operations
> into proper core ops in order to delineate what parts of Scalar::Util
> (which is at least shipped /with/ core even if it isn't part of the
> /usr/bin/perl binary itself), so that users can have a clearer picture
> of what is and isn't officially supported interface.
>
> I've already somewhat dealt with `blessed` by adding the `isa` keyword,
> so I'd be happy to additionally look into moving any of the other parts
> of Scalar::Util API into being proper core keywords. E.g. I know I have
> a lot of code that uses Scalar::Util only to obtain `weaken`, so I
> could imagine a new version on a new perl which just turned
>
> use Scalar::Util `weaken`;
>
> into effectively
>
> use feature 'weaken';
>
> to operate on a real core OP_WEAKEN.
>
>
> Should we make a list of all the functions and divide them into those
> we're happy with and those we're not?
>
I like this idea.
Yves
ps: I apologize for using the jerkish term "nonsense". The position I
responded to wasn't nonsense. I think this covid incarceration is making
prone to excessive emotion in my emails even for me. My apologies.
--
perl -Mre=debug -e "/just|another|perl|hacker/"
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr">On Fri, 29 May 2020 at 12:39, Paul "LeoNerd" \
Evans <<a href="mailto:leonerd@leonerd.org.uk">leonerd@leonerd.org.uk</a>> \
wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On Fri, 29 May 2020 08:43:46 +0200<br> demerphq \
<<a href="mailto:demerphq@gmail.com" target="_blank">demerphq@gmail.com</a>> \
wrote:<br> <br>
> Nonsense. It doesn't "support" them. They are undocumented<br>
> side-effects of our value caching strategy. Where does the *perl*<br>
> docs say we have dualvars? Where does it discuss them? Scalar::Util<br>
> isnt an answer, its NOT the core, even if its bundled with the core.<br>
> So can we do away with that argument please? It doesn't hold water.<br>
<br>
Alright; well I'm happy to put dualvars on the side for now. Between<br>
you and haarg there seems to be some objection to making it official<br>
core API. I can continue to copypaste my polyfill function around<br>
between XS files to handle it.<br>
<br>
<br>
But I'd like to continue on this question of Scalar::Util not being<br>
core. If that really is the case, then there are a bunch of other<br>
things that core also doesn't support, but are in very widespread use:<br>
<br>
* reftype<br>
* refaddr<br></blockquote><div><br></div><div>I consider these core. We changed \
the core to make them more efficient even. Also to a certain exent reftype() is \
deprecated in fact of Ref::Util 90% of the time.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
* weaken, isweak, etc..<br></blockquote><div><br></div><div>Yeah, this is a real \
edge case. As in the same argument applies to them as does reftype()/refaddr() to a \
certain extent. Support was added to the core to make them work, but we never really \
embraced them in the core or IMO they would be full on SV types and not their weird \
hybrid thing they currently are. I would be a lot more ok with adding them to the \
core than dualvar personally.</div><div> <br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
* blessed<br></blockquote><div><br></div><div>Core.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
If it isn't the case that Scalar::Util represents official core API<br>
policy, then it seems that core doesn't actually provide pureperl users<br>
any way to operate on reference types/addresses (i.e. to see through the<br>
weird cloak that is `ref` on a blessed reference), nor to operate \
on<br></blockquote><div><br></div><div>Fair argument, although i would say that they \
are basically optimizations of operations you could perform in pure perl using ref() \
and regexes, along with overload::StrVal(). </div><div><br></div><div>Whereas \
something like a dualvar cant be constructed from just perl semantics.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> weakrefs at all. But I am pretty sure that \
those things are officially<br> supported operations by core. A *lot* of CPAN uses \
these things that<br> even if we hadn't intended to claim them supported, \
we're now stuck<br> having to continue to handle them as we do now. If core \
hadn't intended<br> to support dualvars either, then it is perhaps pure luck that \
nowhere<br> near as much of CPAN is using those, as compared these other \
functions.<br> <br>
I wonder if then, we should look at moving some of these operations<br>
into proper core ops in order to delineate what parts of Scalar::Util<br>
(which is at least shipped /with/ core even if it isn't part of the<br>
/usr/bin/perl binary itself), so that users can have a clearer picture<br>
of what is and isn't officially supported interface.<br>
<br>
I've already somewhat dealt with `blessed` by adding the `isa` keyword,<br>
so I'd be happy to additionally look into moving any of the other parts<br>
of Scalar::Util API into being proper core keywords. E.g. I know I have<br>
a lot of code that uses Scalar::Util only to obtain `weaken`, so I<br>
could imagine a new version on a new perl which just turned<br>
<br>
use Scalar::Util `weaken`;<br>
<br>
into effectively<br>
<br>
use feature 'weaken';<br>
<br>
to operate on a real core OP_WEAKEN.<br>
<br>
<br>
Should we make a list of all the functions and divide them into those<br>
we're happy with and those we're not?<br></blockquote><div><br></div><div>I \
like this idea.</div><div><br></div><div>Yves <br></div></div><div>ps: I apologize \
for using the jerkish term "nonsense". The position I responded to \
wasn't nonsense. I think this covid incarceration is making prone to excessive \
emotion in my emails even for me. My apologies.</div><div><br></div>-- <br><div \
dir="ltr" class="gmail_signature">perl -Mre=debug -e \
"/just|another|perl|hacker/"</div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic