-
Notifications
You must be signed in to change notification settings - Fork 560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ref and other ops are inefficient in boolean context #10706
Comments
From @timbunceCreated by @timbunce[16:05] timbunce: code like "if ref $foo" is far more expensive than it needs to be because ref() still creates a new SVPV when called in a boolean context. [16:11] Zefram: but ref($foo)'s truth value isn't as simple as most people expect, so it's approximately never what a programmer actually wants In boolean context, pp_ref would check the pv returned by sv_reftype in Perl Info
|
From @jkeenanOn Fri, 08 Oct 2010 13:29:35 GMT, timbo wrote:
Tim Bunce proposed this approach more than six years ago. Can anyone respond? Thank you very much. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Sat, Dec 31, 2016 at 04:09:30PM -0800, James E Keenan via RT wrote:
I've just pushed the commit shown below as davem/boolref. The repeep() code in my commit is separate from similar code that puts I'm open to suggestions for other ops which could benefit from being commit 9108e50 add an OPpREF_BOOL flag to OP_REF -- |
From @iabynOn Tue, Jan 03, 2017 at 01:22:08PM +0000, Dave Mitchell wrote:
I've since done this a different way. First I've pushed the following set commit bec5a1b [MERGE] redo boolean context which fixes some bugs and adds a general framework for supporting boolean- Then I've pushed the following branch as davem/boolref2 which I intend to commit a83d533 make OP_REF support boolean context I've had a quick look though our ops list to see what other ops might Anyway, I'll look further into doing other ops after 5.26. -- |
From @iabynOn Fri, Jan 06, 2017 at 04:44:27PM +0000, Dave Mitchell wrote:
which I've now pushed as v5.27.0-127-gba75e9a -- |
From @iabynOn Fri, Jan 06, 2017 at 04:44:27PM +0000, Dave Mitchell wrote:
Which I've now done and just pushed with this merge commit: commit c1a6686 [MERGE] various boolean-related optimisations -- |
From @cpansproutOn Thu, 27 Jul 2017 03:50:56 -0700, davem wrote:
Why does that need to be the case? Why cannot PL_sv_zero have just the SvIOK flag on? Does it matter that \(%h && $foo) now returns a reference to a read-only value when %h is empty? (If so, that can be solved by turning on PADTMP on PL_sv_zero.)
index(...) >= 0 is also quite common. -- Father Chrysostomos |
From @cpansproutOn Thu, 27 Jul 2017 16:14:18 -0700, sprout wrote:
I think it does matter. grep(1,@list_with_one_item) returning a mutable 1 and grep(1,@list_with_zero_items) returning a read-only variable is the kind of icky inconsistency that I tried hard to eliminate. -- Father Chrysostomos |
From @iabynOn Thu, Jul 27, 2017 at 04:22:47PM -0700, Father Chrysostomos via RT wrote:
because the first time you do, e.g. @a=(); PL_sv_zero gets upgraded to an SvPOK() PVIV anyway.
Won't setting PADTMP cause PL_sv_zero's PVX buffer to be stolen? Or is -- |
From @cpansproutOn Fri, 28 Jul 2017 04:35:26 -0700, davem wrote:
It is not done on a R/O var. -- Father Chrysostomos |
From @iabynOn Fri, Jul 28, 2017 at 10:09:09AM -0700, Father Chrysostomos via RT wrote:
Now done. commit 02960b5 set SVs_PADTMP flag on PL_sv_zero -- |
From @iabynOn Thu, Jul 27, 2017 at 04:14:18PM -0700, Father Chrysostomos via RT wrote:
I've now added comparison variant like that with v5.27.2-102-g400ffcf. -- |
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#78288 (status was 'resolved')
Searchable as RT78288$
The text was updated successfully, but these errors were encountered: