> On Mon, Oct 15, 2012 at 6:02 PM, Clint Priest <cpri...@zerocue.com> wrote:
> > Because fundamentally interfaces are designed to explain a way of
> > communicating and properties are symmetrical and non-
> observable.
> >
> > The implementing class cannot "know" when a property has changed.
>
> Do you agree that there is nothing that distinguishes
>
> class A {
> public $v;
> }
>
> from
>
> class B {
> private $_v;
> public $v { get { return $this->v; }; set($n) { $this->v = $n; }} }
>
> when it comes to a client of B reading and writing to $b->v ? That's the
> entire point of accessors: being able to seamlessly intercept
> usages of properties with custom code.
>
> If you define an interface saying interface A { public $v { get;set;} } you
> are only saying to the user: objects of type A will have a
> property $v that you can read and write to.
> Whether it is a set of accessors or a property belongs to the implementation
> detail of the class implementing A, the user should not
> be able to see a difference when interacting with the class, as he will do it
> through $obj->v and $obj->v = ...;
>
> I can understand why we might not want that in PHP in order to simplify the
> implementation, but it we follow logical reasoning I
> can't see why we shouldn't implement that.
>
I'm not sure I understand what you're getting at here Etienne, this thread was
about interfaces but now you're talking about two classes...
>
> This discussion makes we wonder about another aspect of the patch that is
> unclear:
>
> class A {
> public $v = 2;
> }
>
> class B extends A {
> public $v { get { .. }; set { .. } }; }
>
> Will $b->v trigger the accessors, will it ignore them and access "v"
> in the properties table, or is overriding existing properties using accessors
> rejected during compilation?
>
This topic was brought up by Nikita and is now in the "backing property"
thread. Originally I had properties shadowing accessors, which would be the
opposite of your desired functionality here.
Nikita suggested that accessors should shadow properties which would let your
above design do just as you want it to. I think you and she are right,
Accessors should shadow real properties (hide them if defined) such that an
accessor will take over for a defined property. Originally I wrote it the
other way because that's the way __get() works, it only gets called if there is
not a real property already. I kept it the same for the sake of being the same
but I think accessors shadowing properties is the way to go.
> Best,
>
> >
> > -Clint
> >
> > On Oct 15, 2012, at 9:37 AM, "Levi Morrison" <morrison.l...@gmail.com>
> > wrote:
> >
> >>> I *think* we are on the same page here, though I'm not sure what 'user'
> >>> is referring to (user of interface "implementer") or (user
> of class B). In any case, I don't believe that your class B would be allowed
> at present, but if it is, then it should not be allowed
> because defining a property to satisfy the requirements of an accessor is not
> right.
> >>
> >> According to whom? In my opinion, not allowing a property to satisfy
> >> the requirement of an accessor is wrong.
>
>
>
> --
> Etienne Kneuss
> http://www.colder.ch
