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
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
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,
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
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
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
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
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 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
> >
> 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
11 matches
Mail list logo
