Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66671
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALtuQzA0M80O3P3yrOqn-hWFk5+uCYoM+8rAqNK-f5e8CUwXyg@mail.gmail.com>
References: <CALtuQzA0M80O3P3yrOqn-hWFk5+uCYoM+8rAqNK-f5e8CUwXyg@mail.gmail.com>
Date: Sun, 17 Mar 2013 10:03:42 +0100
Message-ID: <CAH-PCH45bd0+7bbQXGUqYC0v6ng01e3MJKO+0jrdwfx5Mf5Cfg@mail.gmail.com>
To: Sebastian Krebs <krebs.seb@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae93409f72ddb0a04d81b2629
Subject: Re: [PHP-DEV] Abstract properties
From: tyra3l@gmail.com (Ferenc Kovacs)

--14dae93409f72ddb0a04d81b2629
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2012.12.01. 13:35, "Sebastian Krebs" <krebs.seb@gmail.com> ezt =C3=ADrta:
>
> Hi,
>
> Don't want to start a big discussion, but is there a concrete reason, why
> abstract properties (or "a kind of abstract") are not supported? I've
> learned, that "an interface [the concept, not the implementations within =
a
> language] is the sum of all accessible (--> public) methods and
> properties", what as far as I understand means, that properties could (an=
d
> should) be defineable in concrete interfaces too
>
> interface Queue {
>   public function enqueue($value);
>   public function dequeue();
>   public $top;
> }
> // or
> abstract class Queue {
>   abstract public function enqueue($value);
>   abstract public function dequeue();
>   abstract public $top;
> }
>
> Of course in the second example the "abstract" is kind of useless, but
it's
> for illustration. I've seen some cases (for example the example above),
> where it would be useful to define properties in interfaces, but instead =
I
> was forced to (in my eyes) misuse [1] methods. Right now I cannot safely
> write somethig like
>
> /**
>  * Must have a $top property
>  */
> interface Queue {
>   public function enqueue($value);
>   public function dequeue();
> }
>
> function foo(Queue $q) {
>   doSomethingWithTop($q->top);
> }
>
> Because I can never ensure, that $top exists. I always have to work with
> isset() here (or of course I use a getter, as mentioned earlier), what
> takes a little bit from the "usefulness" of interfaces ^^ The interface
> feels incomplete.
>
> Would like to hear some opinions, or maybe a summary of earlier
discussions
> about this topic :)
>
> Regards,
> Sebastian
>
>
>
>
> [1] I've also learned, that methods define behaviour and properties defin=
e
> the state. "$top" in the example is part of the state, thus calling a
> method to fetch the state feels wrong/like a hack (thats btw my opinion
> about getters/setters too; just to create a bridge to other concepts ;)).
>
> --
> github.com/KingCrunch

I'm also interested about the rationale behind this design decision.

--14dae93409f72ddb0a04d81b2629--