Re: [PHP-DEV] [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects

[Levi Morrison via internals]

On Tue, Jul 7, 2020 at 2:47 PM Michał Marcin Brzuchalski
 wrote:
>
> Hi internals,
>
> following recently added alternative to `token_get_all()` in form of a
> dedicated class `PhpToken`
> I've made a similar proposal for collecting stack traces by introducing
> `StackFrame::getTrace()`
> and `StackFrame` which replaces array with keys and values known from
> `debug_backtrace()`.
>
> To compete with easier adoption `StackFrame` implements `ArrayAccess`
> giving identical API
> to `debug_backtrace()`.
>
> A test script with deep recursion up to 1M frames uses 50% less memory than
> `debug_backtrace()`.
>
> The RFC is described here https://wiki.php.net/rfc/stack-frame-class
> It includes implementation of PoC and tests.
>
> Cheers,
> Michał Marcin Brzuchalski

Any opposition for a parameter to limit stack depth? It's something
I'd like on the old API too.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects

[Mike Schinkel]

> On Jul 7, 2020, at 4:46 PM, Michał Marcin Brzuchalski 
>  wrote:
> 
> Hi internals,
> 
> following recently added alternative to `token_get_all()` in form of a
> dedicated class `PhpToken`
> I've made a similar proposal for collecting stack traces by introducing
> `StackFrame::getTrace()`
> and `StackFrame` which replaces array with keys and values known from
> `debug_backtrace()`.
> 
> To compete with easier adoption `StackFrame` implements `ArrayAccess`
> giving identical API
> to `debug_backtrace()`.
> 
> A test script with deep recursion up to 1M frames uses 50% less memory than
> `debug_backtrace()`.
> 
> The RFC is described here https://wiki.php.net/rfc/stack-frame-class
> It includes implementation of PoC and tests.
> 
> Cheers,
> Michał Marcin Brzuchalski

Yes, excited to see this.

Would adding a method that allows getting a specific stack frame rather than 
the entire trace if you know which on you want take up less memory and/or 
perform better? 

Something like StackFrame::getFrame(1) which would be functionally equivalent 
to StackFrame::getTrace()[1]?

-Mike

[PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void

[Benas IML]

Hey internals,

I have reopened the voting. It is going to close July 22nd, 2020. I have also
added a "Why allow void return type on constructors/destructors?" section which
I hope internals are going to read and consider before voting. Thanks!

RFC:
https://wiki.php.net/rfc/make_ctor_ret_void

Best regards,
Benas

On Fri, 3 Jul 2020 at 00:12, Benas IML  wrote:
>
> Hey internals,
>
> I have opened the voting for the RFC, let's hope everything is going
> to be smooth :). If you have any other questions, let me know!
>
> RFC: https://wiki.php.net/rfc/make_ctor_ret_void
>
> Best regards,
> Benas Seliuginas

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

[Marcio Almada]

Hello Josh,

> Link to working draft: https://bit.ly/php-0001 

>From a type safety POV I'd prefer to have an interface available, the
same way we did
to the Stringable interface RFC. But I'd rather keep these engine
affecting behaviors
with the same magic method naming conventions and its `__` prefix.

So `implements Bool` + `function __toBool() : bool` is the only path that seems
entirely consistent with what we already have.

The draft doesn't mention (bool) casting behavior at the time I'm
reading it, but you do
mention the possibility. It seems necessary to me. Why wouldn't
`(bool) $my_bool_obj`
behave differently from `(string) $my_stringable_obj`?

>
> ps. If you have any feedback or information on social interactions here that 
> might help, please do let me know, normally I would have watched for a while 
> before putting my foot in - hopefully it doesn’t end up in my mouth. :)


Thanks,
Márcio Almada

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

[Josh Bruce]

Link to working draft: https://bit.ly/php-0001 

Discussion on implementing a means by which a class instance can interacted 
with syntactically as a boolean.

At this point in the discuss the only means discussed is creation of a method 
(magic or via an interface).

Ability to cast is not ruled out. 

And, my limited knowledge of PHP at this depth, much less under the hood, means 
there could be a lot of unknown unknowns regarding the ways a boolean can be 
interpreted and interacted with; therefore, those may not be covered at this 
time.

I’m also not liking the overly contrived nature of the samples and will improve 
those over time should interest maintain or increase.

Cheers,
Josh

ps. If you have any feedback or information on social interactions here that 
might help, please do let me know, normally I would have watched for a while 
before putting my foot in - hopefully it doesn’t end up in my mouth. :)

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Larry Garfield]

On Tue, Jul 7, 2020, at 5:31 PM, David Rodrigues wrote:
> There are some problem by using double back slash for PHP namespace?
> 
> Eg. Instead of \PHP\String be just \\String.

Currently that's a syntax error, and I don't think we have time to change it 
before the code freeze even if we could all agree to do so.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

[Josh Bruce]



> On Jul 7, 2020, at 3:24 PM, Rowan Tommins  wrote:
> 
>> On 07/07/2020 18:13, Josh Bruce wrote:
>> Decided to put something 
>> together:https://github.com/joshbruce/external-project-proposals/blob/master/php-concepts/interact-with-instance-as-php.md
> 
> 
> Hi Josh,
> 
> Reading through this, it seems to cover a few different concepts, which are 
> certainly related, but not quite the same.
> 
> Firstly, we have interfaces such as Countable and Serializable, which don't 
> make the object act like any particular primitive type, they just customise 
> its interaction with particular functions. Iterators could potentially be 
> included in that category, too, because it's fairly easy to imagine the 
> language having multiple primitive types that can be iterated (e.g. separate 
> "list" and "dictionary" types).
> 
> ArrayAccess feels more explicitly about making an object "act like" an array, 
> but more precisely it overloads the [] operator - it doesn't allow the object 
> to be used in other contexts where arrays are allowed. More general operator 
> overloading was discussed recently, and the particular proposal put forward 
> did not pass its RFC vote. [1]
> 
>  __toString, on the other hand, only allows the object to be *converted to* a 
> string, not act like one. You can't, for instance, influence the behaviour of 
> the concatenation operator, and make "Hello" . $object . "!" return an object 
> instead of a string, or a string that doesn't begin "Hello". An __toArray 
> method was proposed recently, to mixed reaction. [2]
> 
> The other closely related topic is what is often discussed as "scalar 
> methods" or "scalar objects" - the ability to call methods on non-object 
> values, and possibly to define your own methods that can be called in this 
> way. This would seem to fit your use case with Shoop quite well: rather than 
> Shoop::array($array)->first()->unfold(), you would just call $array->first(). 
> It's fairly high on a lot of people's wish lists, but there's a lot of 
> details to get right in both design and implementation, so I strongly 
> recommend searching for previous discussions and proofs of concept before 
> diving in.
> 
> 
> [1] https://wiki.php.net/rfc/userspace_operator_overloading
> [2] https://externals.io/message/105589
> 
> -- 
> Rowan Tommins (né Collins)
> [IMSoP]
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php


All: Going to change threads now that I’m getting a better feel for the list 
environment and conventions, I think. 

Someniatko: Saw the pipes RFC a while back and really appreciate. Think both 
could have their place and developed preference (switch and if-else, for 
example). Added reference to document. See link below.

Rowan: Thanks for the feedback and links!

PHP Internals is definitely not my wheelhouse and I find myself speaking mainly 
from the developer’s perspective because I don’t know enough to speak from the 
PHP perspective. Thanks for your patience there.

First takeaway is that I should drastically reduce scope and cut-short the 
background, lay of the land, sales pitch language I’ve seen in other RFCs and 
concepts.

Second, I should consider the audience more. Most of the people on this list 
probably (read most definitely) know more about this than I do (or ever will) 
and y’all don’t need long-winded explanations and background (could be wrong). 
So, thinking less text, more code.

Finally, as I see more of the landscape and given conversations are 
low-bandwidth (long form, text-only), trying to cover more than one thing would 
most likely distract at best and block at worst.

So, gonna go after defining a boolean return value for a class. (At least for 
now.)

Updated: https://bit.ly/php-0001

Thank you again for the feedback and links.

Cheers,
Josh

ps. The ability to call methods on non-object values is interesting and could 
definitely be helpful for Shoop. The main frustration for me when using Shoop 
is the inability to just drop the pointer into a condition and have it work. :)

pps. The operator overloading feels like Swift…nice feature...that would 
definitely be helpful. While it doesn’t do the array thing itself, I would be 
able to implement ArrayAccess and Iterator on it, yeah? At which point it could 
feel like an array (if I skimmed properly) - throw in __toString and we have 
the Pym primitive. :)

Re: [PHP-DEV] Re: [RFC] Nullsafe operator

[Ilija Tovilo]

> Just curious, do you plan on putting this to a vote in near time? The
> feature freeze is coming soon.

There's a remaining complication with references which I had limited
time to work on. This doesn't technically need to be fixed to start
the vote but if it can't be solved reasonably it would have to be
described in the RFC which is why I'm hesitant.

I'll invest some time over the next few days so that I can hopefully
start the vote by the end of the week. If I can't find a solution I
might delay the RFC for PHP 8.1.

Ilija

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Nullsafe operator

[someniatko]

> I've reworded some things and added more information on short
> circuiting. Functionality wise the RFC has remained the same.
>
> Since there was little negative feedback I'd like to put this feature
> to a vote in ~1 week. If you have any concerns or criticism please let
> me know in time.

Just curious, do you plan on putting this to a vote in near time? The
feature freeze is coming soon.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

[someniatko]

> This would seem to fit your use case with Shoop quite well:
> rather than Shoop::array($array)->first()->unfold(), you would just call
> $array->first(). It's fairly high on a lot of people's wish lists, but
> there's a lot of details to get right in both design and implementation,
> so I strongly recommend searching for previous discussions and proofs of
> concept before diving in.

We don't need methods on non-scalar objects, if we have [pipe
operator](https://wiki.php.net/rfc/pipe-operator-v2): sth like `$array
|> array_first(?)`. This would allow much greater flexibility.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Stephen Reay]

> On 8 Jul 2020, at 13:16, Michał Marcin Brzuchalski 
>  wrote:
> 
> Hi Stephen,
> 
> śr., 8 lip 2020 o 07:09 Stephen Reay  napisał(a):
> 
>> ...
>> IMO (and I know it’s not universal) acronyms should remain upper case.
>> Camel case is about upper casing the first letter of each word. The letters
>> of an acronym are all the first letters of words, thus DOM not Dom, etc.
>> 
> 
> It doesn't really matter much though, since core symbols are already known
> on runtime so symbol resolution works by case insensitive manner.
> So it's only a matter of preference on documentation side.
> 
> namespace Foo\Bar {
>class BaZ {}
> }
> namespace {
>var_dump(new foo\bar\baz());
> }
> 
> Cheers,
> --
> Michał Marcin Brzuchalski

Hi Michal,

I realise that - I was replying to a specific question about bike shedding the 
capitalisation - that it works in other cases is irrelevant IMO.

Cheers

Stephen 
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Michał Marcin Brzuchalski]

Hi Stephen,

śr., 8 lip 2020 o 07:09 Stephen Reay  napisał(a):

> ...
> IMO (and I know it’s not universal) acronyms should remain upper case.
> Camel case is about upper casing the first letter of each word. The letters
> of an acronym are all the first letters of words, thus DOM not Dom, etc.
>

It doesn't really matter much though, since core symbols are already known
on runtime so symbol resolution works by case insensitive manner.
So it's only a matter of preference on documentation side.

namespace Foo\Bar {
class BaZ {}
}
namespace {
var_dump(new foo\bar\baz());
}

Cheers,
--
Michał Marcin Brzuchalski