# [PHP-DEV [RFC] Property Accessors v1.2

- Thread: https://externals.io/message/63358
- Original archive: https://news-web.php.net/php.internals/63358
- Started by Clint Priest on 2012-10-12T05:23:30+00:00
- Messages: 66
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/63358.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #63358 — Clint Priest — 2012-10-12T05:23:30+00:00

URL: https://externals.io/message/63358#63358

Alright, here is the updated RFC as per discussions for the last few days:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week waiting period while I make the final code changes.

-Clint

---

## #63359 — Jazzer Dane — 2012-10-12T05:32:22+00:00

URL: https://externals.io/message/63358#63359 · In reply to: #63358

I like it.
I assume that, in regards to static properties, the static keyword works
just as well as self and parent, correct?



> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> If you could read it over, make sure I have all of your concerns correctly
> addressed and we can leave this open for the two week waiting period while
> I make the final code changes.
>
> -Clint

---

## #63361 — Bernhard Schussek — 2012-10-12T08:06:35+00:00

URL: https://externals.io/message/63358#63361 · In reply to: #63358

Hi Clint,

I would like to urge you again to consider implementing the array
access methods. Without that, this very neat feature becomes
essentially unusable for modelling one-to-many, many-to-one and
many-to-many object relations, as I tried to explain in the previous
topic.

Objects and relations between them are the most primitive building
block of OO design, so I regard this as highly important.

Thanks,
Bernhard

---

## #63362 — Lester Caine — 2012-10-12T08:22:24+00:00

URL: https://externals.io/message/63358#63362 · In reply to: #63358

Clint Priest wrote:
> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week waiting period while I make the final code changes.

Now I remember why I did not like this wholesale ...

There is no easy way to identify that
$time->Hours = 12; is doing something other than a bog standard 'store 12 in 
$Hours' while a simple $time->Hours(12); immediately makes it obvious that there 
IS some processing involved. And period = $time->Hours(); flags that the result 
is calculated from some other value in the class.

So IS this new layer of magic mirrors really necessary at all? Is it adding to 
the complexity at the expense of the inherent readability of the code later on?

I suppose the argument is that 'people expect it' but that is only because they 
are not yet used to the better way of working that IS PHP ... just because some 
people expect cryptic code should that be any reason to weigh PHP down further 
with it?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #63364 — Pierre Joye — 2012-10-12T08:37:15+00:00

URL: https://externals.io/message/63358#63364 · In reply to: #63362

hi Lester,


> Clint Priest wrote:
> > […]
>
>
> Now I remember why I did not like this wholesale ...
>
> There is no easy way to identify that
> $time->Hours = 12; is doing something other than a bog standard 'store 12 in
> $Hours' while a simple $time->Hours(12); immediately makes it obvious that
> there IS some processing involved. And period = $time->Hours(); flags that
> the result is calculated from some other value in the class.
>
> So IS this new layer of magic mirrors really necessary at all? Is it adding
> to the complexity at the expense of the inherent readability of the code
> later on?
>
> I suppose the argument is that 'people expect it' but that is only because
> they are not yet used to the better way of working that IS PHP ... just
> because some people expect cryptic code should that be any reason to weigh
> PHP down further with it?
>

Please keep the discussion sane without repeating the same arguments
over and over again. This RFC is about adding a new cleaner
getter/setter than the __get/__set we have now, which forces us to do
some more useless work for basic needs. The complexity you are talking
about already exist and you already mentioned this argument already,
we got it.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #63366 — Lester Caine — 2012-10-12T08:49:14+00:00

URL: https://externals.io/message/63358#63366 · In reply to: #63364

Pierre Joye wrote:
> hi Lester,
>
> 
> > […]
>
> Please keep the discussion sane without repeating the same arguments
> over and over again. This RFC is about adding a new cleaner
> getter/setter than the __get/__set we have now, which forces us to do
> some more useless work for basic needs. The complexity you are talking
> about already exist and you already mentioned this argument already,
> we got it.

Sorry , but if the complexity was any good, why does it need to be changed?
Simply scrap the whole lot and get back to a more sane solution. I'm sorry but 
this is just the whole problem with PHP 'development' ... people push half 
developed ideas in, and then it's used as the basis for moving things further 
forward, when a step back MAY be the best way forward! Has ANY of the new stuff 
that has been added to PHP recently ACTUALLY been fully finished? In many cases 
you are now discussion how to make them work better because what exists has 
problems that will be fixed later :( And we have to live with the consequences 
in the real world.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #63367 — Pierre Joye — 2012-10-12T08:54:17+00:00

URL: https://externals.io/message/63358#63367 · In reply to: #63366

> Sorry , but if the complexity was any good, why does it need to be changed?
> Simply scrap the whole lot and get back to a more sane solution. I'm sorry
> but this is just the whole problem with PHP 'development' ...

We know that you don't like modern solutions, we really know it by
now. Please move on.

-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #63370 — Lester Caine — 2012-10-12T10:44:08+00:00

URL: https://externals.io/message/63358#63370 · In reply to: #63367

Pierre Joye wrote:
> > […]
> We know that you don't like modern solutions, we really know it by
> now. Please move on.

getters and setters modern? I was using them in C++ in the 90's and it was NICE 
to be able to avoid them in PHP when I started moving code over in the early 
2000's. But I've just looked back at that code to remind me how it was done 
there and one forgets how tidy C++ is! The getters and setters were simply 
implemented in a library function that one of my other core libraries used. They 
were never actually defined in C++ at all? One never had direct access to the 
class variables so never missed it. It comes back to what is needed in the core 
code, and what can simply be selected by those who thing they need it ... I just 
hope we do not end up on the Python bandwagon of dropping core functions simply 
because they do not fit with the 'modern way' Python2 is going to exist for a 
long time simply because people don't have time to rewrite code for P3 ... PHP 
seems to be going after the same 'modern approach' :(

Anyway back to TRYING to get a new server up and running WITH Apache2.4 and 
PHP5.4 when the distro is still on 2.2 and 5.3 ... It will be some years before 
any of this can be used generally in ISP hosting ...

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #63371 — Nikita Popov — 2012-10-12T10:48:28+00:00

URL: https://externals.io/message/63358#63371 · In reply to: #63358

> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week waiting period while I make the final code changes.
>
> -Clint

I've been thinking a bit about the automatic properties again, and
noticed that I forgot to name one use case: Asymmetric accessor
visibility. Automatic properties may be useful in that context, so
that you can write "public $foo { get; protected set; }" (though they
don't necessarily need to be implemented as properties with auto
generated code, rather just properties with more detailed visibility
handling [a bit related to the stuff Amaury has been saying]).

Nikita

---

## #63373 — Kingsquare.nl - Robin Speekenbrink — 2012-10-12T12:19:31+00:00

URL: https://externals.io/message/63358#63373

paf!



>
> Le 12/10/2012 11:48, Nikita Popov a écrit :
> > […]
>
> I agree.

---

## #63374 — Christian Stoller — 2012-10-12T12:23:02+00:00

URL: https://externals.io/message/63358#63374 · In reply to: #63371

Good hint, Nikita.
I like the feature of automatic properies. For the problems with unauthorized access: What about signing automated generated "variables", so that they are only accessable through the property?

@Lester Caine: This properties do not break backward compatibility. If you do not want to use it, you do not need.
I like them because they offer an easy, short and well readable way to protected object or class variables.

Best regards
Christian Stoller


-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com] 
Sent: Friday, October 12, 2012 12:48 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2


> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week waiting period while I make the final code changes.
>
> -Clint

I've been thinking a bit about the automatic properties again, and
noticed that I forgot to name one use case: Asymmetric accessor
visibility. Automatic properties may be useful in that context, so
that you can write "public $foo { get; protected set; }" (though they
don't necessarily need to be implemented as properties with auto
generated code, rather just properties with more detailed visibility
handling [a bit related to the stuff Amaury has been saying]).

Nikita

---

## #63375 — Kingsquare.nl - Robin Speekenbrink — 2012-10-12T12:32:10+00:00

URL: https://externals.io/message/63358#63375

Please ignore me... i'm a n00b and my mail programme F*cked me...

my bad

Regards,

Robin Speekenbrink
Kingsquare BV


>
> Le 12/10/2012 11:48, Nikita Popov a écrit :
> > […]
>
> I agree.

---

## #63376 — Lester Caine — 2012-10-12T13:02:04+00:00

URL: https://externals.io/message/63358#63376 · In reply to: #63374

Christian Stoller wrote:
> @Lester Caine: This properties do not break backward compatibility. If you do not want to use it, you do not need.
> I like them because they offer an easy, short and well readable way to protected object or class variables.

The problem is not my own use Christian ... like many of the facilities that 
have been added in PHP4.3 and 5.4, they get taken up by frameworks and third 
party libraries, so either one has to stay with libraries that you can 
understand and are compatible or learn all the foibles of these new features 
simply to track NEW bugs created in perfectly good code that was working until 
someone upgraded a library.

My comment about 'finding a good distro' is very pertinent here, since the one I 
am currently playing with Fedora 17 provides many of the pear and other 
libraries in the distro, but the pear ones have to be avoided since they are not 
strict complaint, and the other graphics libraries need to be reworked for 
PHP5.4. While 'it does not break backward compatibility', getting legacy 
websites to run on a more modern setup is not a quick job, and simply ignoring 
or switching off all the warnings does not help when there IS something which 
needs fixing! I would bet that 80% of code in use today needs reworking for 
PHP5.3 even let alone 5.4.

I wish now I had simply forked PHP5.2 and was maintaining security fixes on 
that, rather than NOW having to patch customers legacy sites because the version 
of PHP5.2 their ISP is running has newly identified holes! We simply don't have 
a LTS nail to work from and for which we can maintain security, and none of 
these developments are helping to solve the problem. ANOTHER ISP has just rolled 
back to 5.2 because of the problems with legacy sites on 5.3 and this is a 
bigger problem for PHP than fixing something that was broken when it was first 
implemented at all ...

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #63378 — Levi Morrison — 2012-10-12T14:44:41+00:00

URL: https://externals.io/message/63358#63378 · In reply to: #63358

> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week waiting period while I make the final code changes.
>
> -Clint
>

I'm not sure if that RFC is up to date; are `ZEND_ACC_READONLY` and
`ZEND_ACC_WRITEONLY` still there? Are there still 79 test cases? I'd
like to see wider coverage if you can think of more things to tests.
Ideally every conditional statement has a test.

I used to be very against this RFC but I admit the details have
improved a lot with the ability to type hint and the removal of read
and write only keywords.

Levi Morrison

---

## #63382 — Clint Priest — 2012-10-13T04:43:34+00:00

URL: https://externals.io/message/63358#63382 · In reply to: #63378

I must have missed taking that part out of the RFC, they would not be needed any more with those keywords being removed.

> -----Original Message-----
> From: Levi Morrison [mailto:morrison.levi@gmail.com]
> Sent: Friday, October 12, 2012 9:45 AM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
> 
> 
> > […]
> waiting period while I make the final code changes.
> > […]
> 
> I'm not sure if that RFC is up to date; are `ZEND_ACC_READONLY` and `ZEND_ACC_WRITEONLY` still there? Are there still 79 test cases?
> I'd like to see wider coverage if you can think of more things to tests.
> Ideally every conditional statement has a test.
> 
> I used to be very against this RFC but I admit the details have improved a lot with the ability to type hint and the removal of read and
> write only keywords.
> 
> Levi Morrison

---

## #63383 — Clint Priest — 2012-10-13T04:47:55+00:00

URL: https://externals.io/message/63358#63383 · In reply to: #63371

The problem with that Nikita is that it would need a variable storage location, which would mean a hidden, auto-implemented property.  You were dead-set against that from the get go.  Keep in mind that property accessors are not properties, real properties will take over the accessor, this could only be done from within the setter of an accessor, but there isn't any way to create an accessor named $Hours which accesses a variable named $Hours.

In any case, your example below could be implemented without automatic creation simply by doing the backing yourself, such as:

private $myFoo;

public $foo {
	get() { return $this->myFoo; }
	protected set($x) { $this->myFoo = $x; }
}

Again, without another "variable store" automatic properties goes out the door, can't really have one without the other.

Shall I hold off on this discussion point before proceeding?

> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Friday, October 12, 2012 5:48 AM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
> 
> 
> > […]
> waiting period while I make the final code changes.
> > […]
> 
> I've been thinking a bit about the automatic properties again, and noticed that I forgot to name one use case: Asymmetric accessor
> visibility. Automatic properties may be useful in that context, so that you can write "public $foo { get; protected set; }" (though they
> don't necessarily need to be implemented as properties with auto generated code, rather just properties with more detailed visibility
> handling [a bit related to the stuff Amaury has been saying]).
> 
> Nikita

---

## #63384 — Clint Priest — 2012-10-13T04:55:11+00:00

URL: https://externals.io/message/63358#63384 · In reply to: #63359

Yeah, if you check out the section in the RFC on static properties I give examples of both of these cases, I have not tested the use of static::$zz though come to think of it, I will put it on my todo list.

From: Jazzer Dane [mailto:tbprogrammer@gmail.com]
Sent: Friday, October 12, 2012 12:32 AM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

I like it.
I assume that, in regards to static properties, the static keyword works just as well as self and parent, correct?

Alright, here is the updated RFC as per discussions for the last few days:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week waiting period while I make the final code changes.

-Clint

---

## #63385 — Clint Priest — 2012-10-13T04:58:16+00:00

URL: https://externals.io/message/63358#63385 · In reply to: #63361

Hey Bernhard,

I see a few problems with the proposal:

1) If you're adding all of the ArrayAccess functions, what about all of the Iterator functions?  How about other SPL aspects, like Countable, etc.

2) The use case can still be handled with an actual object which implements ArrayAccess and in a better practice scenario, unless I misunderstood what your code sample was implying.  (if so, could you provide a complete, concrete example where it would be more advantageous to have these four additional accessor functions?)

3) Zero other languages that I am aware of implement anything more than get/set for accessors, the need for isset/unset is obvious for php because they are so heavily used.  In fact, this document referenced in Dennis's original RFC shows 11 other languages with accessors, none of which have more than get/set.  
http://en.wikipedia.org/wiki/Property_%28programming%29

Lastly, it would probably delay this project another 6 months, perhaps it could be shelved for a version 2 of the accessors aspect?

-Clint

> -----Original Message-----
> From: Bernhard Schussek [mailto:bschussek@gmail.com]
> Sent: Friday, October 12, 2012 3:07 AM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
> 
> Hi Clint,
> 
> I would like to urge you again to consider implementing the array access methods. Without that, this very neat feature becomes
> essentially unusable for modelling one-to-many, many-to-one and many-to-many object relations, as I tried to explain in the previous
> topic.
> 
> Objects and relations between them are the most primitive building block of OO design, so I regard this as highly important.
> 
> Thanks,
> Bernhard

---

## #63386 — Benjamin Eberlei — 2012-10-13T08:06:29+00:00

URL: https://externals.io/message/63358#63386 · In reply to: #63358

> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> If you could read it over, make sure I have all of your concerns correctly
> addressed and we can leave this open for the two week waiting period while
> I make the final code changes.
>
> -Clint
>
>
Can we discuss the removal of automatic get; set; again? For me that was
the best feature of the whole RFC, essentially allowing to define a
property with getter/setter in 1 LOC. Allowing future overriding of that
getter/Setter if the application required it.

This is absolutely essential for database backed recods which will have
tons of those property accessors. Now if i apply PSR coding styles to
accessors, then i end up with 11 LOC for accessors defining a property, a
property accessor and get/set functions, compared to 10 LOC with usual
getter/setters.

As i understand it was removed because of the unclear behavior when we have
the following code:

public $Foo { get(); set($value) { $this->??? = $value; }}

I propose to reintroduce this shortcut, if you define both getter/setter as
automatic:

public $Foo { get(); set(); }

The syntax is up for grabs, but it would be very sad if this be removed.

greetings,
Benjamin

---

## #63387 — Nikita Popov — 2012-10-13T09:29:50+00:00

URL: https://externals.io/message/63358#63387 · In reply to: #63386

> Can we discuss the removal of automatic get; set; again? For me that was
> the best feature of the whole RFC, essentially allowing to define a
> property with getter/setter in 1 LOC. Allowing future overriding of that
> getter/Setter if the application required it.
>
> This is absolutely essential for database backed recods which will have
> tons of those property accessors. Now if i apply PSR coding styles to
> accessors, then i end up with 11 LOC for accessors defining a property, a
> property accessor and get/set functions, compared to 10 LOC with usual
> getter/setters.

Not sure I quite understand you. What prevents you from just using a
normal public property?

    public $property;

Accessors give you the ability to add alternative behavior for the
property lateron (this is actually the main use I personally see in
this RFC: Not actually using it, but having the possibility of using
it).

The only place (which I see off the top of my head) where property /
automatic property makes a difference is interfaces. In the current
implementation interfaces can only define properties with accessors.
So:

    interface Foo {
        // this is okay
        public $abc { get; set; }

        // this is invalid
        public $abc;
    }

And similarly you can't implement the public $abc { get; set; }
definition from the interface using a plain property.

I think that properties should be definable in interfaces, or at a
normal property "public $abc;" should satisfy the interface "public
$abc { get; set; }" (I mean, it kinda does from a functional point of
view, right?)

Nikita

---

## #63388 — Nikita Popov — 2012-10-13T09:58:38+00:00

URL: https://externals.io/message/63358#63388 · In reply to: #63383

> The problem with that Nikita is that it would need a variable storage location, which would mean a hidden, auto-implemented property.  You were dead-set against that from the get go.
What I was mainly against was the particular way how automatic
properties were implemented (with a real __property as a protected
backing field, which was directly exposed to the user). But automatic
properties don't really need that, or at least I don't see why. Just
"public $foo { get; set; }" doesn't really need anything, it can be
equivalent to "public $foo" (not that it makes much sense having it in
that case ^^). "public $foo { get; protected set; }" can also be
implemented without automagically generated accessor methods. This is
what Amaury's patch does, just with a different syntax (it provides
more detailed visibility handling, but does not need accessors).
Another reason why it might be better to not use generated accessors
for this, but rather just more detailed visibility flags for
properties, is performance. Right now "public $foo" would be a "fast"
property, but "public $foo { get; protected set; }" would turn it into
a "slow" method based property. Not sure how important that is though
:)

> Keep in mind that property accessors are not properties, real properties will take over the accessor, this could only be done from within the setter of an accessor, but there isn't any way to create an accessor named $Hours which accesses a variable named $Hours.
"Isn't a way" as in "not possible in the current implementation" or as
in "not possible due to technical limitations in the engine"? I was
going to suggest to allow accessing the $foo property from within the
$foo accessor as to avoid having to create a separate protected
backing property. But if that's not possible for technical reasons
then that obviously won't work out :/

> In any case, your example below could be implemented without automatic creation simply by doing the backing yourself, such as:
>
> private $myFoo;
>
> public $foo {
>         get() { return $this->myFoo; }
>         protected set($x) { $this->myFoo = $x; }
> }
Yes, sure you can implement it manually. Automatic properties are only
there to make it simpler. I can't exactly judge just how important
asymmetric visibility will be, so I don't know just how important it
is to make it short and easy. I can tell that Symfony has 3x more
getters than setters and ZF has 1.6x more getters. But I'm not sure
whether this means "many properties with asymmetric visibility" or
"many properties with just a getter".

> Shall I hold off on this discussion point before proceeding?
Yes, please. As there isn't really a consensus on this it would be
better to wait a bit more.

Nikita

---

## #63389 — Benjamin Eberlei — 2012-10-13T10:00:11+00:00

URL: https://externals.io/message/63358#63389 · In reply to: #63387

> On Sat, Oct 13, 2012 at 10:06 AM, Benjamin Eberlei <kontakt@beberlei.de>
> wrote:
> > […]
>
> Not sure I quite understand you. What prevents you from just using a
> normal public property?
>
>     public $property;
>

Ah yes, of course. Sorry, stupid me :-)



>
> Accessors give you the ability to add alternative behavior for the
> property lateron (this is actually the main use I personally see in
> this RFC: Not actually using it, but having the possibility of using
> it).
>
> The only place (which I see off the top of my head) where property /
> automatic property makes a difference is interfaces. In the current
> implementation interfaces can only define properties with accessors.
> So:
>
>     interface Foo {
>         // this is okay
>         public $abc { get; set; }
>
>         // this is invalid
>         public $abc;
>     }
>
> And similarly you can't implement the public $abc { get; set; }
> definition from the interface using a plain property.
>
> I think that properties should be definable in interfaces, or at a
> normal property "public $abc;" should satisfy the interface "public
> $abc { get; set; }" (I mean, it kinda does from a functional point of
> view, right?)
>
> Nikita

---

## #63390 — Amaury Bouchard — 2012-10-13T10:06:02+00:00

URL: https://externals.io/message/63358#63390 · In reply to: #63387

2012/10/13 Nikita Popov <nikita.ppv@gmail.com>

>     interface Foo {
>         // this is okay
>         public $abc { get; set; }
>
>         // this is invalid
>         public $abc;
>     }
>

Sorry, I missed something. Why the first should be correct but not the
second one?
For me it's exactly the same thing.

---

## #63393 — Clint Priest — 2012-10-13T11:51:32+00:00

URL: https://externals.io/message/63358#63393 · In reply to: #63390

Interfaces are used to define what methods must be present, properties are not allowed.

From: amaury.bouchard@gmail.com [mailto:amaury.bouchard@gmail.com] On Behalf Of Amaury Bouchard
Sent: Saturday, October 13, 2012 5:06 AM
To: Nikita Popov
Cc: Benjamin Eberlei; Clint Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

2012/10/13 Nikita Popov <nikita.ppv@gmail.com<mailto:nikita.ppv@gmail.com>>
    interface Foo {
        // this is okay
        public $abc { get; set; }

        // this is invalid
        public $abc;
    }

Sorry, I missed something. Why the first should be correct but not the second one?
For me it's exactly the same thing.

---

## #63394 — Amaury Bouchard — 2012-10-13T12:35:17+00:00

URL: https://externals.io/message/63358#63394 · In reply to: #63393

2012/10/13 Clint Priest <cpriest@zerocue.com>

>  Interfaces are used to define what methods must be present, properties
> are not allowed.
>

Yes, so no one should be correct, right?
I mean, yes the first declaration implies some code; but for the interface,
it's still a property definition.



>   *From:* amaury.bouchard@gmail.com [mailto:amaury.bouchard@gmail.com] *On
> Behalf Of *Amaury Bouchard
> *Sent:* Saturday, October 13, 2012 5:06 AM
> *To:* Nikita Popov
> *Cc:* Benjamin Eberlei; Clint Priest; internals@lists.php.net
>
> *Subject:* Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2****
>
>  ** **
>
> 2012/10/13 Nikita Popov <nikita.ppv@gmail.com>****
>
>     interface Foo {****
>
>         // this is okay
>         public $abc { get; set; }
>
>         // this is invalid
>         public $abc;
>     }****
>
> ** **
>
> Sorry, I missed something. Why the first should be correct but not the
> second one?****
>
> For me it's exactly the same thing.****

---

Next page: https://externals.io/message/63358.md?page=2