With "Interface Default Methods" potentially becoming a thing, it begs the
question for the need to have Interface Properties, at least `private` ones and
`private static` ones.
How can we have default getters and default setters in an interface if there
are no private interface properties to
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
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
On Sat, May 27, 2023 at 9:44 PM Zoltán Fekete
wrote:
> Abstract class could help this but it’s like using a
> tube wrench for a nut. Also one class can extend only one abstract class.
> By
> simply defining interfaces with properties would save a lot of boilerplate
> code
> and there would be no
> I wouldn't support this, personally. The reason interfaces in most
> languages which have this concept don't support defining properties is
> first because they are generally seen as an implementation detail rather
> than a promise about supported behaviour and second because interfaces are
> es
On Sat, May 27, 2023 at 6:24 PM Larry Garfield
wrote:
> On Sat, May 27, 2023, at 1:39 AM, Nick Humphries wrote:
> > Hello internals,
> >
> > Based on a few discussions I've had recently, my team and I couldn't
> > think of any reason why we shouldn't have properties on interfaces as
>
>
I wouldn'
On Sat, May 27, 2023, at 1:39 AM, Nick Humphries wrote:
> Hello internals,
>
> Based on a few discussions I've had recently, my team and I couldn't
> think of any reason why we shouldn't have properties on interfaces as
> it is common for these to be specified in doc blocks currently.
> Timing-w
Hello internals,
Based on a few discussions I've had recently, my team and I couldn't think of
any reason why we shouldn't have properties on interfaces as it is common for
these to be specified in doc blocks currently. Timing-wise, this lines up well
with dynamic properties being depreciated.
16 matches
Mail list logo