2023年5月29日(月) 15:05 Máté Kocsis :
> Hi Everyone,
>
> Together with multiple authors, we'd like to start the discussion of the
> usual
> deprecation RFC for the subsequent PHP version. You can find the link
> below:
> https://wiki.php.net/rfc/deprecations_php_8_3
>
> Regards:
> Máté Kocsis
>
Hi.
Hi Everyone,
Together with multiple authors, we'd like to start the discussion of the
usual
deprecation RFC for the subsequent PHP version. You can find the link below:
https://wiki.php.net/rfc/deprecations_php_8_3
Regards:
Máté Kocsis
As others have said: the interface/contract makes available public stuff
that is what the implementers will make available. So it should not matter
if those are methods or properties.
In the case of a public property, the difference from the method-only
approach is that it's already implicit that t
On Sun, May 28, 2023 at 5:03 PM Larry Garfield
wrote:
> On another level, I'd redefine properties and methods slightly. (Public)
> Properties are not "raw data" but "aspects of the object I can manipulate"
> and methods are "behaviors I can ask the object to perform."
>
I just wanted to pull ou
On Sun, May 28, 2023, at 6:52 AM, David Gebler wrote:
> On Sun, May 28, 2023 at 10:33 AM Rowan Tommins
> wrote:
>
>> I don't follow. If a property is public, then code outside the class can
>> rely on being able to access it. That seems to me to be a contract between
>> the class and its users, no
Hey all
On 28.05.23 13:52, David Gebler wrote:
On Sun, May 28, 2023 at 10:33 AM Rowan Tommins
wrote:
I don't follow. If a property is public, then code outside the class can
rely on being able to access it. That seems to me to be a contract between
the class and its users, not an implementati
On Sun, May 28, 2023 at 8:21 AM Jorg Sowa wrote:
> Hello,
>
> I agree with David's statement:
> > So yes anyay, my view is that between interfaces as we have them today,
> > traits and abstract classes, there isn't a problem which needs to be
> solved
> > by now allowing properties on interfaces,
On Sun, May 28, 2023 at 10:33 AM Rowan Tommins
wrote:
> I don't follow. If a property is public, then code outside the class can
> rely on being able to access it. That seems to me to be a contract between
> the class and its users, not an implementation detail - e.g. removing the
> property, or
Hello,
I agree with David's statement:
> So yes anyay, my view is that between interfaces as we have them today,
> traits and abstract classes, there isn't a problem which needs to be
solved
> by now allowing properties on interfaces, but it would open up a
likelihood
> of encouraging things which
On 28 May 2023 01:09:39 BST, David Gebler wrote:
>
>I would say getters and setters don't [as a rule-of-thumb] really belong on
>interfaces, since they by definition relate to properties of an object and
>properties are by definition an implementation detail.
I don't follow. If a property is publ
I think it would be useful.
For some reason, lots of people on stackoverflow has a hard time
implementing this function in userland:
on
https://stackoverflow.com/questions/2517947/ucfirst-function-for-multibyte-character-encodings
there are 10 broken implementations of mb_ucfirst, and 1 correct on
On Sun, May 28, 2023 at 9:18 AM Nick Humphries wrote:
> > I don't want to get into a debate about principles of OOP and design
> > practices, this list isn't the place for it. I don't want to sidetrack
> the
> > discussion. I suppose what an interface should conceptually be in PHP is
> > necessar
> Interface properties are already included in the Property Hooks RFC,
> which should be going to a vote soon-ish. We hope it passes, of
> course. :-)
>From what I could see, simple interface properties are not going to be
implemented by this RFC (awesome work on the RFC too, it has my full
s
13 matches
Mail list logo
