> On Jun 17, 2024, at 8:54 AM, Bilge wrote:
> Furthermore, for absolute clarity and the avoidance of doubt, I believe this
> guiding principle can be enshrined on the following single sentence:
>
> "We cannot remove features from a static class that would otherwise be
> present in a standar
On 17/06/2024 13:49, Bilge wrote:
On 16/06/2024 14:32, Mike Schinkel wrote:
Not supporting all features used in the wild would result in
developers not being able to use static classes for new and/or
refactored code if they believe they need those excluded
features. This would s
On 16/06/2024 14:32, Mike Schinkel wrote:
Not supporting all features used in the wild would result in
developers not being able to use static classes for new and/or
refactored code if they believe they need those excluded features.
This would stop developers from signaling their
On Sun, 16 Jun 2024 at 20:08, Rowan Tommins [IMSoP]
wrote:
>
> On 16/06/2024 18:54, Andreas Hennings wrote:
>
> Yes, the possibility for namespace part imports exists.
> Unfortunately these namespace imports usually need to be set up
> manually, whereas the regular class or function import has bet
On 16/06/2024 18:54, Andreas Hennings wrote:
Yes, the possibility for namespace part imports exists.
Unfortunately these namespace imports usually need to be set up
manually, whereas the regular class or function import has better
automatic support from the IDE.
Also, namespace fragments are ofte
On Sun, 16 Jun 2024 at 19:09, Rowan Tommins [IMSoP]
wrote:
>
> On 16/06/2024 16:24, Andreas Hennings wrote:
>
> For a function call, the namespace is usually only visible in the
> imports list at the top of the file.
>
>
> This is one of those interesting cases where the language itself is flexibl
On Sun, 16 Jun 2024 at 17:44, Larry Garfield wrote:
>
> On Sun, Jun 16, 2024, at 10:24 AM, Andreas Hennings wrote:
> > Regarding function autoloading:
> >
> > A more interesting question to me is a convention where to put each
> > function.
> > With classes, PSR-4 tells us exactly what one can ex
Here is a relevant example usage of static classes/polymorphism on my
personal site/app:
https://gist.github.com/oplanre/6894f56fb61134ee5ea93cf262ba3662
On Sun, Jun 16, 2024 at 10:38 AM Andreas Hennings
wrote:
> Regarding function autoloading:
>
> A more interesting question to me is a conventi
On 16/06/2024 16:24, Andreas Hennings wrote:
For a function call, the namespace is usually only visible in the
imports list at the top of the file.
This is one of those interesting cases where the language itself is
flexible, but people are used to a specific style: a use statement can
import
On Sun, Jun 16, 2024, at 10:24 AM, Andreas Hennings wrote:
> Regarding function autoloading:
>
> A more interesting question to me is a convention where to put each function.
> With classes, PSR-4 tells us exactly what one can expect to find in a
> class file with a given name.
> Perhaps a separate
Regarding function autoloading:
A more interesting question to me is a convention where to put each function.
With classes, PSR-4 tells us exactly what one can expect to find in a
class file with a given name.
Perhaps a separate directory tree per package, with one file per sub-namespace?
Or just
> On Jun 16, 2024, at 5:17 AM, Bilge wrote:
>
> Let's start getting specific so we can make some progress.
>
> The goals of this RFC are fairly straightforward:
> Introduce the `static` keyword at the class level to preclude the need to
> create a private constructor. That is, `__construct` wo
On Sun, Jun 16, 2024, at 14:13, Rowan Tommins [IMSoP] wrote:
>
>
> On 15 June 2024 18:39:20 BST, Valentin Udaltsov
> wrote:
>
> >PHP does not have internal/private functions.
> >Very often I use functions for really simple things like `array_flatten`
> >(and register them via composer.json.a
On 15 June 2024 18:39:20 BST, Valentin Udaltsov
wrote:
>PHP does not have internal/private functions.
>Very often I use functions for really simple things like `array_flatten`
>(and register them via composer.json.autoload.files). But when the function
>requires decomposition to smaller ones,
Marco Deleu
>
>> You may have core developers that voted no due to maintenance burden, but if
>> said maintainer is no longer active and new maintainers don't mind it, it's
>> a moot argument because people changed.
>
> The maintenance burden argument is actually a good example of *not* bei
On 16 June 2024 10:27:27 BST, Rob Landers wrote:
>I don’t understand why we are comparing this to a jury and/or court case. In
>many countries, juries don’t even exist (such as the one I currently reside
>in) so the only context is US TV shows for what that even means.
Apologies, I'm from th
https://github.com/oplanre/php-src/tree/feature/static-class
On Sat, Jun 15, 2024 at 3:17 PM Lanre wrote:
> I proposed this previously and have a working implementation, though it
> may need some updates. However, I chose not to pursue it further because it
> was clear it wouldn't pass as many p
On Sun, Jun 16, 2024, at 11:17, Bilge wrote:
> Let's start getting specific so we can make some progress.
>
> The goals of this RFC are fairly straightforward:
> • Introduce the `static` keyword at the class level to preclude the need to
> create a private constructor. That is, `__construct` w
On Sun, Jun 16, 2024, at 10:33, Rowan Tommins [IMSoP] wrote:
>
>
> On 16 June 2024 03:00:39 BST, "Marco Aurélio Deleu"
> wrote:
> >If you appoint a different jury to try a 20 year old case, the decision of
> >the previous jury doesn't have any more weight than any other evidence on
> >its o
Let's start getting specific so we can make some progress.
The goals of this RFC are fairly straightforward:
* Introduce the `static` keyword at the class level to preclude the
need to create a private constructor. That is, `__construct` would
be invalid in a static class.
* Prohibit ins
On 16 June 2024 03:00:39 BST, "Marco Aurélio Deleu" wrote:
>If you appoint a different jury to try a 20 year old case, the decision of the
>previous jury doesn't have any more weight than any other evidence on its own.
You missed the point of the analogy. The point is that that would only ha
> On 15 Jun 2024, at 14:11, Rowan Tommins [IMSoP] wrote:
>
> I fundamentally disagree with this assertion.
>
> If somebody makes a valid point, it doesn't automatically become invalid
> because time has passed, or because nobody happens to repeat it in a later
> e-mail thread.
>
> If I cop
I proposed this previously and have a working implementation, though it may
need some updates. However, I chose not to pursue it further because it was
clear it wouldn't pass as many people here are unaware that PHP is a
multi-paradigm language.
I frequently use static classes because they allow m
On Sat, 15 June, 2024 at 19:21, Bilge wrote:
> On 15/06/2024 16:58, Rowan Tommins [IMSoP] wrote:
> > Common arguments against:
> >
> > - Static properties are a form of global state, and that's something
> > widely advised against
>
> Correct, but a static class does not need to have any state. I
On Sat, Jun 15, 2024, at 9:40 AM, Bilge wrote:
> On 15/06/2024 14:53, Rowan Tommins [IMSoP] wrote:
>> On 15/06/2024 12:16, Bilge wrote:
>>>
>>> I want to introduce the `static` keyword at the class declaration
>>> level. That is, the following would be valid: `static class Foo {}`.
>>
>>
>> This
On 15/06/2024 17:17, Bilge wrote:
You already provided a counter-point to this; we can't autoload functions.
Just to reiterate, please do not attribute any of the arguments or
counter-arguments to me. They were my attempt, from memory, to summarise
previous discussions.
Besides, there ma
On 15/06/2024 16:58, Rowan Tommins [IMSoP] wrote:
Common arguments against:
- Static properties are a form of global state, and that's something
widely advised against
Correct, but a static class does not need to have any state. Indeed, I
cannot think of an instance where I (personally) have
On 15/06/2024 15:40, Bilge wrote:
That's all quite interesting, but I didn't get a good sense of why the
idea was rejected
I haven't re-read the threads in full, so this is mostly from old
memories. And please note I am not saying which of these views I agree
with, just attempting to summari
On Sat, Jun 15, 2024, at 16:40, Bilge wrote:
> On 15/06/2024 14:53, Rowan Tommins [IMSoP] wrote:
> > On 15/06/2024 12:16, Bilge wrote:
> >>
> >> I want to introduce the `static` keyword at the class declaration
> >> level. That is, the following would be valid: `static class Foo {}`.
> >
> >
>
On 15/06/2024 14:53, Rowan Tommins [IMSoP] wrote:
On 15/06/2024 12:16, Bilge wrote:
I want to introduce the `static` keyword at the class declaration
level. That is, the following would be valid: `static class Foo {}`.
This has been proposed before, and was rejected at vote. It was nearly
On 15/06/2024 12:16, Bilge wrote:
I want to introduce the `static` keyword at the class declaration
level. That is, the following would be valid: `static class Foo {}`.
This has been proposed before, and was rejected at vote. It was nearly
10 years ago, so opinions may have changed, but it
On Fri, Feb 26, 2016 at 7:12 PM wrote:
> Hi,
>
>
> I'd be very thankful for a clear explanation on this:
> http://stackoverflow.com/questions/35656898
>
>
> May be it's just a word game and I don't understand it correctly, but
> documentation states one, though $object::$staticProperty works in a
Use self::$cnt but internals@ is not meant for PHP questions but for
discussing development of PHP.
Andi
At 07:48 PM 2/12/2004 +, [EMAIL PROTECTED] wrote:
Can someone point me to some more information on using PHP 5's static
class variables? All I have been able to find is the zend php5 ch
33 matches
Mail list logo
