On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote:
>
>
> On 19.3.2025 16:04:06, Rob Landers wrote:
>> On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
>>> Okay, I see the point with LSP. I'm not sure whether we need to preserve
>>> LSP for that specific scenario, but neither can I say that w
On Thu, Mar 20, 2025, 18:58 Rob Landers wrote:
>
>
> On Thu, Mar 20, 2025, at 16:41, Bob Weinand wrote:
>
>
> Am 20.03.2025 um 16:28 schrieb Rob Landers :
>
>
>
>
> On Thu, Mar 20, 2025, at 16:12, Bob Weinand wrote:
>
>
> Am 20.03.2025 um 15:51 schrieb Rob Landers :
>
>
>
>
> On Wed, Mar 19,
Am 20.03.2025 um 15:51 schrieb Rob Landers :
On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote:
On 19.3.2025 16:04:06, Rob Landers wrote:
On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
Okay, I see the point with LSP. I'm not sure whether we need to preserve LSP
for that specific scena
Am 20.03.2025 um 16:28 schrieb Rob Landers :
On Thu, Mar 20, 2025, at 16:12, Bob Weinand wrote:
Am 20.03.2025 um 15:51 schrieb Rob Landers :
On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote:
On 19.3.2025 16:04:06, Rob Landers wrote:
On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
Hello,
I'm now deep into the rabbit hole of trying out "\" as the separator. It does
give some nice ergonomics when using the nested/inner classes, and I really
like it much better than ":>", but the amount of technical debt I have run into
is enormous. For now, my implementation will probably
On 26 March 2025 00:22:47 GMT, Rob Landers wrote:
>
>To be clear, I'm not trying to be difficult. As you mentioned, these were all
>things I had to think about for nested classes too. I know how nested classes
>work and why. How file-private would work, on the other hand, I have put
>little
On 25 March 2025 20:29:16 GMT, Rob Landers wrote:
> Personally, I'd feel that file-private should be kept as simple as possible
> and limit it to "top-level" things, but that doesn't necessarily have to be
> the case. If we did allow it on methods/properties, when mixing it with
> regular vi
Why not just add structs at this point? It's almost like we don't want to
acknowledge that structs are a thing.
On Tue, Mar 25, 2025, at 3:29 PM, Rob Landers wrote:
> File-private, in my mind, is different; such as when the classes are
> distinctly unrelated with respect to each other, but nobody else should
> be able to instantiate or use the private class. It is like it doesn't
> exist outside that fil
On Tue, Mar 25, 2025, at 23:20, Rowan Tommins [IMSoP] wrote:
>
>
> On 25 March 2025 21:23:48 GMT, Rob Landers wrote:
> >
> >> If we didn't have "protected", would you ask the same about "protected
> >> private"? "fileprivate" would be just another access level, not something
> >> you'd combine
On Tue, Mar 25, 2025, at 6:59 AM, Rob Landers wrote:
>> When I say module scope, I'm referring to something along the lines that
>> Arnaud and I were exploring a while back. tldr, "cluster of files with a
>> common namespace root, which can get loaded together." It was mostly about
>> perform
On 25 March 2025 21:23:48 GMT, Rob Landers wrote:
>
>> If we didn't have "protected", would you ask the same about "protected
>> private"? "fileprivate" would be just another access level, not something
>> you'd combine with existing ones.
>
>Actually, probably yes :) Mostly just to ask for c
On Tue, Mar 25, 2025, at 22:05, Rowan Tommins [IMSoP] wrote:
>
>
> On 25 March 2025 20:29:16 GMT, Rob Landers wrote:
> > Personally, I'd feel that file-private should be kept as simple as possible
> > and limit it to "top-level" things, but that doesn't necessarily have to be
> > the case. I
On Tue, Mar 25, 2025, at 19:51, Larry Garfield wrote:
> On Tue, Mar 25, 2025, at 6:59 AM, Rob Landers wrote:
>
> >> When I say module scope, I'm referring to something along the lines that
> >> Arnaud and I were exploring a while back. tldr, "cluster of files with a
> >> common namespace root,
On Mon, Mar 24, 2025 at 5:12 PM Larry Garfield wrote:
> On Mon, Mar 24, 2025, at 3:47 AM, Rob Landers wrote:
>
> > On Sun, Mar 23, 2025, at 16:17, Larry Garfield wrote:
>
> >> I've been following this thread with interest, and at the moment I'm
> >> honestly undecided. I certainly see the use
On Mon, Mar 24, 2025, at 3:47 AM, Rob Landers wrote:
> On Sun, Mar 23, 2025, at 16:17, Larry Garfield wrote:
>> I've been following this thread with interest, and at the moment I'm
>> honestly undecided. I certainly see the use cases for this functionality
>> (whatever it gets named), but as a
On Thu, Mar 20, 2025, at 16:41, Bob Weinand wrote:
>
>> Am 20.03.2025 um 16:28 schrieb Rob Landers :
>>
>>
>>
>> On Thu, Mar 20, 2025, at 16:12, Bob Weinand wrote:
>>>
Am 20.03.2025 um 15:51 schrieb Rob Landers :
On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote
On Thu, Mar 20, 2025, at 16:12, Bob Weinand wrote:
>
>> Am 20.03.2025 um 15:51 schrieb Rob Landers :
>>
>>
>>
>> On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote:
>>>
>>>
>>> On 19.3.2025 16:04:06, Rob Landers wrote:
On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
> Okay, I se
On 19.3.2025 16:04:06, Rob Landers wrote:
On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
Okay, I see the point with LSP. I'm not sure whether we need to
preserve LSP for that specific scenario, but neither can I say that
we should ignore it.
(Effectively implementing LSP would mean tha
On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
> Hey,
>
> On 17.3.2025 19:58:39, Rob Landers wrote:
>> On Mon, Mar 17, 2025, at 19:05, Bob Weinand wrote:
> . The idea that extending the parent class doesnt no inherit the child
> classes doesnt make sense to me.
> As then if you e
Hey,
On 17.3.2025 19:58:39, Rob Landers wrote:
On Mon, Mar 17, 2025, at 19:05, Bob Weinand wrote:
. The idea that extending the parent class doesnt no inherit the
child classes doesnt make sense to me.
As then if you extend a parent class and call a function of that
class which could rely on t
On Fri, 14 Mar 2025, Bilge wrote:
> On 14/03/2025 21:08, Rowan Tommins [IMSoP] wrote:
> > On 14/03/2025 17:37, Rob Landers wrote:
> > > What about a hybrid approach? Maybe something like `\\` that Tim
> > > suggested?
> >
> > As a perfect example of this, check out how the second paragraph is
>
Hey Rob,
On 17.3.2025 17:53:26, Rob Landers wrote:
On Mon, Mar 17, 2025, at 16:30, fennic log wrote:
2. As with any syntax change and new operator there needs to be very
careful consideration, do we need a new operation, or could `::` if
the parent is static or `->` if the class is initialized
On Mon, Mar 17, 2025, at 19:05, Bob Weinand wrote:
> Hey Rob,
>
> On 17.3.2025 17:53:26, Rob Landers wrote:
>> On Mon, Mar 17, 2025, at 16:30, fennic log wrote:
>>> 2. As with any syntax change and new operator there needs to be very
>>> careful consideration, do we need a new operation, or cou
On 17 March 2025 18:05:49 GMT, Bob Weinand wrote:
>I have not grasped any single argument in favour of \, except "other languages
>are doing it too", "existing tooling splitting on backslash would continue to
>work" and "we could use the existing use statement as is".
This wording feels a bi
On Mon, Mar 17, 2025, at 12:29, Rowan Tommins [IMSoP] wrote:
> On 17/03/2025 10:37, Alexandru Pătrănescu wrote:
>>> From what I understand of the proposal, the calling code won't know
>>> anything different based on it being "nested" or "namespaced", it will just
>>> see a class with a long nam
On Mon, Mar 17, 2025, at 16:30, fennic log wrote:
>
> On Wed, 5 Mar 2025 at 23:14, Rob Landers wrote:
>> __
>> Hello PHP Internals,
>>
>> I'd like to introduce my RFC for discussion:
>> https://wiki.php.net/rfc/short-and-inner-classes
>>
>> This RFC defines a short class syntax as well as the
On Wed, 5 Mar 2025 at 23:14, Rob Landers wrote:
> Hello PHP Internals,
>
> I'd like to introduce my RFC for discussion:
> https://wiki.php.net/rfc/short-and-inner-classes
>
> This RFC defines a short class syntax as well as the ability to nest
> classes inside another class. This introduces an un
> Le 15 mars 2025 à 12:53, Rowan Tommins [IMSoP] a écrit
> :
>
>
>
> On 14 March 2025 23:37:08 GMT, Rob Landers wrote:
>> I could get behind `::`, but I feel that it introduces human ambiguity. I
>> don't believe it would introduce compiler ambiguity, but as a human, I have
>> to hope the
On 17/03/2025 10:37, Alexandru Pătrănescu wrote:
From what I understand of the proposal, the calling code won't
know anything different based on it being "nested" or
"namespaced", it will just see a class with a long name with some
punctuation in.
The problem for me is not auto
On Mon, Ma0r 17, 2025 at 9:56 AM Rowan Tommins [IMSoP]
wrote:
>
>
> On 17 March 2025 07:11:23 GMT, Rob Landers wrote:
>
>
> > Which one it resolves to would depend on how you implement autoloading
>
>
> That's just the same as having the same class defined in two files on disk
> - PHP doesn't kn
On 17 March 2025 07:11:23 GMT, Rob Landers wrote:
>
>namespace Outer;
>
>class Inner {}
>
>And
>
>class Outer {
> class Inner {}
>}
>
>These would both resolve to the same class name for Outer\Inner.
That's the frame challenge: is that actually a good thing, because it makes the
description
On Sat, Mar 15, 2025, at 12:53, Rowan Tommins [IMSoP] wrote:
>
>
> On 14 March 2025 23:37:08 GMT, Rob Landers wrote:
> >I could get behind `::`, but I feel that it introduces human ambiguity. I
> >don't believe it would introduce compiler ambiguity, but as a human, I have
> >to hope the prog
Claude, exactly! By using '::' you cannot distinguish between a class and a
function. So this is not an option because it leads to a headache. Just my
2 cents
On Sun, Mar 16, 2025 at 11:08 PM Claude Pache
wrote:
>
>
> Le 15 mars 2025 à 12:53, Rowan Tommins [IMSoP] a
> écrit :
>
>
>
> On 14 Marc
On Fri, Mar 14, 2025, at 17:09, Ilija Tovilo wrote:
> Hi Bob
>
> On Thu, Mar 13, 2025 at 11:36 PM Bob Weinand wrote:
> >
> > On 6.3.2025 23:20:37, Ilija Tovilo wrote:
> >
> > > I would also like to echo what has been said about the :: operator,
> > > which feels out of place. I understand that
Hi Rob
Without looking too deep (yet) into the details, I'm generally in favor of the
idea.
What I'm less in favor of is the implementation choice to expose the inner
class as a property/const and using a fetch mode to grab it.
That feels quite weird to me honestly. How did you arrive at this ch
Hi
Am 2025-03-06 07:23, schrieb Rob Landers:
So, technically, they aren’t required to be in the same RFC; but also,
they complement each other very well.
They really should be separate RFCs then. Your RFC text acknowledges
that in the very first sentence: “two significant enhancements to the
On 14/03/2025 21:18, Bilge wrote:
Just because some (incompetent) developers cannot grasp proper
escaping should have no bearing whatsoever on language design.
The main problem is not "grasping" it, it's the inconvenience of having
to do it at all, and the "ugliness" (subjective, obviously) o
Hi Bob
On Thu, Mar 13, 2025 at 11:36 PM Bob Weinand wrote:
>
> On 6.3.2025 23:20:37, Ilija Tovilo wrote:
>
> > I would also like to echo what has been said about the :: operator,
> > which feels out of place. I understand that \ comes with additional
> > autoloading challenges, namely requiring a
Hey Ilija,
On 6.3.2025 23:20:37, Ilija Tovilo wrote:
I would also like to echo what has been said about the :: operator,
which feels out of place. I understand that \ comes with additional
autoloading challenges, namely requiring a fallback autoloading
strategy that currently does not conform to
On Sat, Mar 15, 2025, at 00:21, Rowan Tommins [IMSoP] wrote:
> On 05/03/2025 23:11, Rob Landers wrote:
> >
> > I'd like to introduce my RFC for discussion:
> > https://wiki.php.net/rfc/short-and-inner-classes
>
>
> As a user, I find the concept of inner classes quite confusing.
>
> However, I
Hey Rob,
On 6.3.2025 00:11:22, Rob Landers wrote:
Hello PHP Internals,
I'd like to introduce my RFC for discussion:
https://wiki.php.net/rfc/short-and-inner-classes
A small note on the Reflection section: it should include a method
giving you an array of all contained ReflectionClasses:
$r
On 14 March 2025 23:37:08 GMT, Rob Landers wrote:
>I could get behind `::`, but I feel that it introduces human ambiguity. I
>don't believe it would introduce compiler ambiguity, but as a human, I have to
>hope the programmers are using a style that makes it obvious what are inner
>classes a
On Sat, Mar 15, 2025, at 01:01, Rob Landers wrote:
>
>
> On Sat, Mar 15, 2025, at 00:21, Rowan Tommins [IMSoP] wrote:
>> On 05/03/2025 23:11, Rob Landers wrote:
>> >
>> > I'd like to introduce my RFC for discussion:
>> > https://wiki.php.net/rfc/short-and-inner-classes
>>
>>
>> As a user, I fi
On Fri, Mar 14, 2025, at 19:16, Bob Weinand wrote:
> Hey Rob,
>
> On 6.3.2025 00:11:22, Rob Landers wrote:
>> Hello PHP Internals,
>>
>> I'd like to introduce my RFC for discussion:
>> https://wiki.php.net/rfc/short-and-inner-classes
> A small note on the Reflection section: it should include a
On 15.3.2025 00:21:32, Rowan Tommins [IMSoP] wrote:
On 05/03/2025 23:11, Rob Landers wrote:
I'd like to introduce my RFC for discussion:
https://wiki.php.net/rfc/short-and-inner-classes
As a user, I find the concept of inner classes quite confusing.
However, I was looking at some code ea
On 05/03/2025 23:11, Rob Landers wrote:
I'd like to introduce my RFC for discussion:
https://wiki.php.net/rfc/short-and-inner-classes
As a user, I find the concept of inner classes quite confusing.
However, I was looking at some code earlier and thought an "inner enum"
would be useful, to
On 14/03/2025 21:08, Rowan Tommins [IMSoP] wrote:
On 14/03/2025 17:37, Rob Landers wrote:
What about a hybrid approach? Maybe something like `\\` that Tim
suggested?
As a perfect example of this, check out how the second paragraph is
rendered wrong here: https://externals.io/message/126589#12
On 14/03/2025 17:37, Rob Landers wrote:
What about a hybrid approach? Maybe something like `\\` that Tim
suggested?
I'm surprised nobody has pointed out yet that \ as namespace separator
is already controversial because of how commonly it is used as an escape
prefix, leading to a lot of situ
Hey Ilija,
On 14.3.2025 17:09:40, Ilija Tovilo wrote:
Hi Bob
On Thu, Mar 13, 2025 at 11:36 PM Bob Weinand wrote:
On 6.3.2025 23:20:37, Ilija Tovilo wrote:
I would also like to echo what has been said about the :: operator,
which feels out of place. I understand that \ comes with additional
a
On Thu, Mar 6, 2025, at 09:04, Tim Düsterhus wrote:
> Hi
>
> Am 2025-03-06 07:23, schrieb Rob Landers:
> > So, technically, they aren’t required to be in the same RFC; but also,
> > they complement each other very well.
>
> They really should be separate RFCs then. Your RFC text acknowledges
>
On Thu, Mar 6, 2025, at 02:08, Juris Evertovskis wrote:
> Hi,
>
> Maybe I didn’t read the RFC carefully enough, but… Do any of these features
> require the other one?
>
> I’m asking because I wouldn’t want to see them both denied just because the
> voters disagree with one of them.
>
> Go
On 2025-03-07 01:48, Rob Landers wrote:
They're not 100% arbitrary, but mostly due to technical limitations.
- One level deep: Nesting multiple levels results in ambiguous grammar.
- As a parent class: This also results in ambiguity.
- Abstract: If it cannot be a parent class, it doesn't make s
Hi Rob
On Thu, Mar 6, 2025 at 12:14 AM Rob Landers wrote:
>
> I'd like to introduce my RFC for discussion:
> https://wiki.php.net/rfc/short-and-inner-classes
Thank you for your proposal.
I'm very much against the idea of introducing yet another slightly
shorter form to declare a class. In your
On Thu, Mar 6, 2025, at 23:20, Ilija Tovilo wrote:
> Hi Rob
>
> On Thu, Mar 6, 2025 at 12:14 AM Rob Landers wrote:
> >
> > I'd like to introduce my RFC for discussion:
> > https://wiki.php.net/rfc/short-and-inner-classes
>
> Thank you for your proposal.
>
> I'm very much against the idea of
On Thu, Mar 6, 2025, at 23:31, Tim Düsterhus wrote:
> Hi
>
> On 3/6/25 23:05, Rob Landers wrote:
> >>
> >> Closure::fromCallable('Outer::Inner::method');
> >
> > You end up with:
> >
> > object(Closure)#1 (1) {
> >["function"]=>
> >string(20) "Outer::Inner::method"
> > }
>
> Oka
Hi
On 3/6/25 23:05, Rob Landers wrote:
Closure::fromCallable('Outer::Inner::method');
You end up with:
object(Closure)#1 (1) {
["function"]=>
string(20) "Outer::Inner::method"
}
Okay, does calling the closure work and correctly call the `method` on
the inner class? The questio
Hi
On 3/6/25 22:38, Rob Landers wrote:
I put a lot of thought into this issue off and on, all day. I've decided to
remove short syntax from the RFC and focus on inner classes.
Good choice.
Don't forget to update the title of the RFC in the Overview page:
https://wiki.php.net/rfc
Best rega
On Thu, Mar 6, 2025, at 22:00, Tim Düsterhus wrote:
> Hi
>
> On 3/6/25 20:08, Niels Dossche wrote:
> > What I'm less in favor of is the implementation choice to expose the inner
> > class as a property/const and using a fetch mode to grab it.
> > That feels quite weird to me honestly. How did you
Hi
On 3/6/25 20:08, Niels Dossche wrote:
What I'm less in favor of is the implementation choice to expose the inner
class as a property/const and using a fetch mode to grab it.
That feels quite weird to me honestly. How did you arrive at this choice?
Somewhat relatedly, the RFC does not menti
On Wed, Mar 5, 2025, at 5:11 PM, Rob Landers wrote:
> Hello PHP Internals,
>
> I'd like to introduce my RFC for discussion:
> https://wiki.php.net/rfc/short-and-inner-classes
I agree with others who have said this should be two RFCs. They stand alone,
but can complement each other well. That's
On 2025-03-06 10:04, Tim Düsterhus wrote:
- I don't understand the use of `private` properties. Given that the
classes cannot have methods, they would be inaccessible, no?
I think the RFC was a bit unclear on this. Short classes can have
methods. The short syntax just doesn't provide the abil
Hi Rob,
czw., 6 mar 2025 o 00:16 Rob Landers napisał(a):
> Hello PHP Internals,
>
> I'd like to introduce my RFC for discussion:
> https://wiki.php.net/rfc/short-and-inner-classes
>
> This RFC defines a short class syntax as well as the ability to nest
> classes inside another class. This introd
Hi,
Maybe I didn’t read the RFC carefully enough, but… Do any of these features
require the other one?
I’m asking because I wouldn’t want to see them both denied just because the
voters disagree with one of them.
Good luck with this proposal!
Juris
64 matches
Mail list logo
