Hi!
Maybe the solution is simply to throw an E_STRICT when unset()-ting an
interface property? My understanding is E_STRICT is to push the
I'd have no problem with that provided it doesn't cost performance (i.e.
no additional hash lookups, etc.) and doesn't break any of __unset, etc.
semanti
2008/5/19 Stanislav Malyshev <[EMAIL PROTECTED]>:
> Hi!
>
>> Would the following be acceptable?
>>
>> (Not E_STRICT) If error_reporting does not include E_STRICT, then
>
> I think making the language internals depend on error_reporting setting is
> not a very good idea, especially on E_STRICT. I.e.
Hi!
Would the following be acceptable?
(Not E_STRICT) If error_reporting does not include E_STRICT, then
I think making the language internals depend on error_reporting setting
is not a very good idea, especially on E_STRICT. I.e., I have nothing
against making unset() trigger E_STRICT if i
Hello Stanislav,
Monday, May 19, 2008, 2:13:14 AM, you wrote:
> Hi!
>> As much as I agree on the interface part, changing my sentence from
>> containing 'interface' to 'protocol' makes it even a bug today. And that
>> by the way was the purpose of my mail.
> I think it is not right to call it a
Richard Quadling wrote:
> In trying to understand the proposal of allowing properties via
> interfaces from your (Chris') point of view, what benefit do we get?
I don't use interfaces at all so I don't have a strong opinion about the
benefits or drawbacks of adding properties really but ...
> All
2008/5/19 Christian Schneider <[EMAIL PROTECTED]>:
> Richard Quadling wrote:
>> (Not E_STRICT) If error_reporting does not include E_STRICT, then
>> unset()'ting properties defined in interfaces is allowed and operates
>> exactly as it does on normal variables and for properties defined in
>> class
Richard Quadling wrote:
> (Not E_STRICT) If error_reporting does not include E_STRICT, then
> unset()'ting properties defined in interfaces is allowed and operates
> exactly as it does on normal variables and for properties defined in
> classes. Whilst this may break the contract, this is what curr
2008/5/19 Stanislav Malyshev <[EMAIL PROTECTED]>:
> Hi!
>
>> As much as I agree on the interface part, changing my sentence from
>> containing 'interface' to 'protocol' makes it even a bug today. And that
>> by the way was the purpose of my mail.
>
> I think it is not right to call it a "bug", sinc
Hi!
As much as I agree on the interface part, changing my sentence from
containing 'interface' to 'protocol' makes it even a bug today. And that
by the way was the purpose of my mail.
I think it is not right to call it a "bug", since it works exactly as it
was intended and designed to work. I
Hello Stanislav,
Sunday, May 18, 2008, 9:01:36 PM, you wrote:
> Hi!
>> declared and part of an interface. Removing it means changing the
>> interface means breaking inheritance. So making this possible is a bug in
>> the engine. End of the story.
> Or that makes interface variables make much le
Hi!
declared and part of an interface. Removing it means changing the
interface means breaking inheritance. So making this possible is a bug in
the engine. End of the story.
Or that makes interface variables make much less sense than initially
thought :)
--
Stanislav Malyshev, Zend Software
Hi!
Just to make this clear once and for ever. If unset() deletes the property then:
But that's what unset does right now in any context. It deletes the
variable given as its argument. Changing this may have a lot of
unexpected effects.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL
Hello Christian,
Sunday, May 18, 2008, 7:16:55 PM, you wrote:
> Hi Marcus,
> Am 18.05.2008 um 18:41 schrieb Marcus Boerger:
>> Just to make this clear once and for ever. If unset() deletes the
>> property then:
>> a) it would break inheritance
>> b) accomplish nothing, as the next access would
Hi Marcus,
Am 18.05.2008 um 18:41 schrieb Marcus Boerger:
Just to make this clear once and for ever. If unset() deletes the
property then:
a) it would break inheritance
b) accomplish nothing, as the next access would simply recreate it
Ok, you don't want this thread to die, so here we go: Yo
Hello Christian,
Sunday, May 18, 2008, 1:30:08 PM, you wrote:
> Hi Marcus,
> Am 18.05.2008 um 13:20 schrieb Marcus Boerger:
>> Not allowing unset() is the bug. Having unset delete the property
>> would be
>> the error. As long as the property still exists with value NULL all is
>> fine.
> I t
Hi Marcus,
Am 18.05.2008 um 13:20 schrieb Marcus Boerger:
Not allowing unset() is the bug. Having unset delete the property
would be
the error. As long as the property still exists with value NULL all is
fine.
I think unset($foo->bar) should unset while $foo->bar = null should
set to null
Hello Christian,
Wednesday, May 14, 2008, 10:57:24 AM, you wrote:
> Am 14.05.2008 um 02:06 schrieb Marcus Boerger:
>>> So you are saying that
>>>$o_Foo->bar = array(42);
>>> is ok when the class "expects" a string but
>>>unset($o_Foo->bar);
>>> or (as as slight variation)
>>>
On Wed, 2008-05-14 at 14:37 +0200, Christian Schneider wrote:
> Richard Quadling wrote:
> > _IF_ the property was defined in an interface, should "unset" be
> > "allowed" to remove the property?
>
> a) Interfaces do not define attributes, they define a set of methods.
> b) If the above would be c
Richard Quadling wrote:
> _IF_ the property was defined in an interface, should "unset" be
> "allowed" to remove the property?
a) Interfaces do not define attributes, they define a set of methods.
b) If the above would be changed I still want to be able to shoot myself
in the foot if I *explicitel
2008/5/14 Christian Schneider <[EMAIL PROTECTED]>:
>
> Am 14.05.2008 um 02:06 schrieb Marcus Boerger:
>>>
>>> So you are saying that
>>> $o_Foo->bar = array(42);
>>> is ok when the class "expects" a string but
>>> unset($o_Foo->bar);
>>> or (as as slight variation)
>>> $o->Foo->ba
Am 14.05.2008 um 02:06 schrieb Marcus Boerger:
So you are saying that
$o_Foo->bar = array(42);
is ok when the class "expects" a string but
unset($o_Foo->bar);
or (as as slight variation)
$o->Foo->bar = null;
is not?
I Do not get the connection here? And since when can we '
Hello Christian, Stas,
Tuesday, May 13, 2008, 4:08:09 PM, you wrote:
> Marcus Boerger wrote:
>>> unset($o_Foo->bar);
>>> echo $o_Foo->bar;
>> ?>>
>>
>>> outputs ...
>>> Notice: Undefined property: foo::$bar in C:\- on line 13
>>
>> At this point you found an error. Because this allows unset() t
Hi!
point the following is nolonger valid: $o_Foo is-a foo. And that is the
basic design rule we chose for PHP. Please file as a bug!
I don't think it's a bug. PHP as a dynamic language allows to do a lot
of think that Java or C++ do not. This is one of them.
--
Stanislav Malyshev, Zend Soft
Marcus Boerger wrote:
>> unset($o_Foo->bar);
>> echo $o_Foo->bar;
> ?>>
>
>> outputs ...
>> Notice: Undefined property: foo::$bar in C:\- on line 13
>
> At this point you found an error. Because this allows unset() to modify an
> instance in a way that it nolonger adheres to its class that means
Hello Richard,
Monday, May 12, 2008, 5:03:39 PM, you wrote:
> 2008/5/12 Marcus Boerger <[EMAIL PROTECTED]>:
>> Hello Richard,
>>
>> Wednesday, May 7, 2008, 3:33:24 PM, you wrote:
>>
>>> 2008/5/7 Jeff Moore <[EMAIL PROTECTED]>:
On May 6, 2008, at 12:45 PM, Marcus Boerger wrote:
>>>
2008/5/12 Marcus Boerger <[EMAIL PROTECTED]>:
> Hello Richard,
>
> Wednesday, May 7, 2008, 3:33:24 PM, you wrote:
>
>> 2008/5/7 Jeff Moore <[EMAIL PROTECTED]>:
>>>
>>> On May 6, 2008, at 12:45 PM, Marcus Boerger wrote:
>>>
>>>
>>> > public $property {
>>> > __get = getProperty;
>>> > __set = set
Hello Richard,
Wednesday, May 7, 2008, 3:33:24 PM, you wrote:
> 2008/5/7 Jeff Moore <[EMAIL PROTECTED]>:
>>
>> On May 6, 2008, at 12:45 PM, Marcus Boerger wrote:
>>
>>
>> > public $property {
>> > __get = getProperty;
>> > __set = setProperty;
>> > }
>> > string public function getProperty() {
2008/5/7 Jeff Moore <[EMAIL PROTECTED]>:
>
> On May 6, 2008, at 12:45 PM, Marcus Boerger wrote:
>
>
> > public $property {
> > __get = getProperty;
> > __set = setProperty;
> > }
> > string public function getProperty() {
> > return $this->_property;
> > }
> > string protected function setPrope
2008/5/6 Lars Strojny <[EMAIL PROTECTED]>:
> Hi Marcus!
>
> Am Dienstag, den 06.05.2008, 21:45 +0200 schrieb Marcus Boerger:
> [...]
>
> > All fine with me. However we *would* need to specify which function is
> > getter, setter, isset or unset.
>
> [...]
>
> >
> > public $property {
> > st
On May 6, 2008, at 12:45 PM, Marcus Boerger wrote:
public $property {
__get = getProperty;
__set = setProperty;
}
string public function getProperty() {
return $this->_property;
}
string protected function setProperty(string $value) {}
Hi Marcus,
I prefer this approach.
One advantage is
On May 6, 2008, at 12:21 PM, Lars Strojny wrote:
I think this is too unspecific. At least the visibility, setter and/or
getter and type-hint (assuming we will have type hints) should be
defined. Otherwise defining properties in interfaces become useless as
it does not tell somebody more except
Hi All,
Lars Strojny schrieb:
>> Hi Marcus!
>>
>> Am Dienstag, den 06.05.2008, 21:45 +0200 schrieb Marcus Boerger:
>> [...]
All fine with me. However we *would* need to specify which
function is getter, setter, isset or unset.
>>
>> [...]
public $property { string public function
15:22
To: John Carter -X (johncart - PolicyApp Ltd at Cisco); Derick Rethans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Class Properties in Interfaces?
Hello John,
the main reason really is storage. If you allow storage in interfaces
then you get multiple inheritance with its virtual i
Hi Marcus!
Am Dienstag, den 06.05.2008, 21:45 +0200 schrieb Marcus Boerger:
[...]
> All fine with me. However we *would* need to specify which function is
> getter, setter, isset or unset.
[...]
>
> public $property {
> string public function __get() {
> return $this->_property;
> }
>
Hello Lars,
Tuesday, May 6, 2008, 9:21:12 PM, you wrote:
> Hi Marcus, et al.,
> Am Dienstag, den 06.05.2008, 09:09 -0700 schrieb Jeff Moore:
> [...]
>> I think this is really specifying implementation details in an
>> interface:
> I agree.
> [...]
>> This looks to me like the best way to han
On Tue, May 6, 2008 at 1:21 PM, Lars Strojny <[EMAIL PROTECTED]> wrote:
> I think this is too unspecific. At least the visibility, setter and/or
> getter and type-hint (assuming we will have type hints) should be
> defined. Otherwise defining properties in interfaces become useless as
> it does no
Hi Marcus, et al.,
Am Dienstag, den 06.05.2008, 09:09 -0700 schrieb Jeff Moore:
[...]
> I think this is really specifying implementation details in an
> interface:
I agree.
[...]
> This looks to me like the best way to handle this in interfaces:
>
> > interface Coord {
> > abstract $coord;
>
My question was simply: why can't interfaces have properties?
John.
From: Nathan Nobbe [mailto:[EMAIL PROTECTED]
Sent: 29 April 2008 16:17
To: John Carter -X (johncart - PolicyApp Ltd at Cisco)
Cc: internals@lists.php.net
Subject: Re: Re: [PHP-DEV] Cl
Marcus Boerger wrote:
A much shorter thing to do might be:
interface Coord {
abstract $coord;
}
Something like that is exactly what I was looking for in my original
question. I don't want to specify implementation details, I just want to
ensure the property exists on the classes that im
>
> John.
>
> From: Nathan Nobbe [mailto:[EMAIL PROTECTED]
> Sent: 29 April 2008 16:17
> To: John Carter -X (johncart - PolicyApp Ltd at Cisco)
> Cc: internals@lists.php.net
> Subject: Re: Re: [PHP-DEV] Class Properties in Interfac
Hi!
In Child $foo is redefined without a getter-method. This breaks the
How it's not "in Child the get method is inherited from Mother"? But
suppose it is as you say. Yes, in this particular case it would be
detected - however, it is not the code you brought in the last example,
where the a
Am Mittwoch, den 30.04.2008, 12:25 -0700 schrieb Stanislav Malyshev:
[...]
> How? For that you'd need the interpreter to actually understand what the
> code does. While I'd like to have such thing one day (provided it does
> not rebel and decide to kill all humans, of course ;) PHP interpreter is
Hi!
With the substantial difference, that __get()/__set() does not work
properly with inheritance, as the language can't verify the LSP.
Language never could verify the LSP. The developer should do it - the
language has no idea of what pre/postconditions in your code are.
Language can provid
Good evening Stas,
Am Mittwoch, den 30.04.2008, 10:02 -0700 schrieb Stanislav Malyshev:
[...]
> You can easily do this by having __get call getProperty. That's like 1
> line of code to do. No language change needed.
With the substantial difference, that __get()/__set() does not work
properly wit
Stanislav Malyshev wrote:
Hi!
have plain properties that may contain everything. If we would have
something like this:
You can easily do this by having __get call getProperty. That's like 1
line of code to do. No language change needed.
I don't know about you, but I'm not interested in tha
Hi!
have plain properties that may contain everything. If we would have
something like this:
You can easily do this by having __get call getProperty. That's like 1
line of code to do. No language change needed.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zen
Hi Stas, hi everbody,
Am Dienstag, den 29.04.2008, 10:22 -0700 schrieb Stanislav Malyshev:
[...]
> In any case, whenever you want to write $foo->bar, just write
> $foo->getBar() and $foo->setBar(), and it'd work :)
I think the issue is, that PHP does not have defined properties with
attached val
On Wed, 2008-04-30 at 09:22 -0700, Chris Stockton wrote:
> If you guys don't like the way interfaces work then do not use them.
> If your going to talk about cycles, just lose the abstraction all
> together.
>
> Important for some. You once again, with all your hand
> flapping, as
If you guys don't like the way interfaces work then do not use them. If your
going to talk about cycles, just lose the abstraction all together.
Important for some. You once again, with all your hand flapping, assume
> we want some kind of operation on the data. If we do not, and this
> happens a
On Wed, Apr 30, 2008 at 9:55 AM, Robert Cummings <[EMAIL PROTECTED]>
wrote:
>
> On Wed, 2008-04-30 at 09:39 -0600, Nathan Nobbe wrote:
> >
> > so really, all we would get is a group of member variables we know
> > would be there...
>
> No, you know nothing about the existence of properties when us
On Wed, 2008-04-30 at 09:39 -0600, Nathan Nobbe wrote:
>
> so really, all we would get is a group of member variables we know
> would be there...
No, you know nothing about the existence of properties when using
getters and setters. Just because you have getColour() and setColour()
in no way imp
On Wed, Apr 30, 2008 at 12:01 AM, Robert Cummings <[EMAIL PROTECTED]>
wrote:
>
> On Wed, 2008-04-30 at 01:22 -0400, Nathan Nobbe wrote:
> > On Wed, Apr 30, 2008 at 1:07 AM, Robert Cummings <[EMAIL PROTECTED]>
> wrote:
>
>
> > We are not talking about data here. We are talking about
> >
On Tue, 2008-04-29 at 23:37 -0700, Stanislav Malyshev wrote:
> > $hair = new Hair();
> > $hair->colour = 'brown';
>
> You can do this without pre-defining any properties.
yes but the following (as I'm you certainly know):
echo $hair->colour
generates an E_NOTICE if the property isn't defin
$hair = new Hair();
$hair->colour = 'brown';
You can do this without pre-defining any properties.
The above is a much less wordy way of doing the following:
No, it is not the same. You can override what happens when you do
setColor - like send notification to some other object or set also
On Wed, 2008-04-30 at 01:22 -0400, Nathan Nobbe wrote:
> On Wed, Apr 30, 2008 at 1:07 AM, Robert Cummings <[EMAIL PROTECTED]> wrote:
> We are not talking about data here. We are talking about
> properties.
> Data is assigned to a property which is akin to functionality
>
On Tue, 2008-04-29 at 22:21 -0700, Stanislav Malyshev wrote:
> > But then you need to check if it exists lest you raise an E_NOTICE
> > because it doesn't exist. Additionally, E_NOTICE is run-time, interface
> > checking is compile-time.
>
> I don't understand what you mean here. PHP can't check
On Wed, Apr 30, 2008 at 1:07 AM, Robert Cummings <[EMAIL PROTECTED]>
wrote:
>
> On Wed, 2008-04-30 at 00:27 -0400, Nathan Nobbe wrote:
> > On Wed, Apr 30, 2008 at 12:05 AM, Robert Cummings
> >
> > Abstract classes and interfaces are not the same. They are
> > used for
> > f
But then you need to check if it exists lest you raise an E_NOTICE
because it doesn't exist. Additionally, E_NOTICE is run-time, interface
checking is compile-time.
I don't understand what you mean here. PHP can't check variable accesses
compile-time. In fact, in PHP "compile-time" doesn't mean
On Tue, 2008-04-29 at 22:12 -0700, Stanislav Malyshev wrote:
> > an interface with an interface property of x, then all implementations
> > using that interface would know that property x exists and could use it
>
> You can use property in PHP without declaring it previously.
But then you need t
an interface with an interface property of x, then all implementations
using that interface would know that property x exists and could use it
You can use property in PHP without declaring it previously.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408
On Wed, 2008-04-30 at 00:27 -0400, Nathan Nobbe wrote:
> On Wed, Apr 30, 2008 at 12:05 AM, Robert Cummings
>
> Abstract classes and interfaces are not the same. They are
> used for
> fundamentally different reasons. An interface is to enforce a
> contract
On Wed, Apr 30, 2008 at 12:05 AM, Robert Cummings <[EMAIL PROTECTED]>
wrote:
> On Tue, 2008-04-29 at 23:51 -0400, Nathan Nobbe wrote:
> > On Tue, Apr 29, 2008 at 9:22 PM, Robert Cummings <[EMAIL PROTECTED]>
> > wrote:
> >
> > >
> > > That should be a matter of choice for the developer. When you sa
On Tue, 2008-04-29 at 23:51 -0400, Nathan Nobbe wrote:
> On Tue, Apr 29, 2008 at 9:22 PM, Robert Cummings <[EMAIL PROTECTED]>
> wrote:
>
> >
> > That should be a matter of choice for the developer. When you say
> "but
> > when, down the road, some logic...", all I see is you waving your
> hands
>
On Tue, Apr 29, 2008 at 9:22 PM, Robert Cummings <[EMAIL PROTECTED]>
wrote:
>
> On Tue, 2008-04-29 at 19:01 -0600, Nathan Nobbe wrote:
> > On Tue, Apr 29, 2008 at 6:14 PM, Richard Quadling <
> [EMAIL PROTECTED]>
> > wrote:
> >
> > > 2008/4/30 Robert Cummings <[EMAIL PROTECTED]>:
> > > >
> > > > O
On Tue, 2008-04-29 at 19:01 -0600, Nathan Nobbe wrote:
> On Tue, Apr 29, 2008 at 6:14 PM, Richard Quadling <[EMAIL PROTECTED]>
> wrote:
>
> > 2008/4/30 Robert Cummings <[EMAIL PROTECTED]>:
> > >
> > > On Tue, 2008-04-29 at 20:04 +0200, John Carter -X (johncart - PolicyApp
> > >
> > > Ltd at Cisc
On Tue, Apr 29, 2008 at 6:14 PM, Richard Quadling <[EMAIL PROTECTED]>
wrote:
> 2008/4/30 Robert Cummings <[EMAIL PROTECTED]>:
> >
> > On Tue, 2008-04-29 at 20:04 +0200, John Carter -X (johncart - PolicyApp
> >
> > Ltd at Cisco) wrote:
> > > I think there's been two responses to this query:
> >
2008/4/30 Robert Cummings <[EMAIL PROTECTED]>:
>
> On Tue, 2008-04-29 at 20:04 +0200, John Carter -X (johncart - PolicyApp
>
> Ltd at Cisco) wrote:
> > I think there's been two responses to this query:
> >
> > 1. We can't have properties in interfaces because interfaces don't have
> > properti
Robert Cummings wrote:
On Tue, 2008-04-29 at 20:04 +0200, John Carter -X (johncart - PolicyApp
Ltd at Cisco) wrote:
I think there's been two responses to this query:
1. We can't have properties in interfaces because interfaces don't have
properties. I would say this is tautological and doesn
On Tue, 2008-04-29 at 20:04 +0200, John Carter -X (johncart - PolicyApp
Ltd at Cisco) wrote:
> I think there's been two responses to this query:
>
> 1. We can't have properties in interfaces because interfaces don't have
> properties. I would say this is tautological and doesn't add anything.
>
I think there's been two responses to this query:
1. We can't have properties in interfaces because interfaces don't have
properties. I would say this is tautological and doesn't add anything.
2. Why would you need to? Getters and setters work.
So I suppose to answer my question for myself, ther
On Tue, Apr 29, 2008 at 10:28 AM, John Carter -X (johncart - PolicyApp Ltd
at Cisco) <[EMAIL PROTECTED]> wrote:
> Nathan,
>
> By example:
>
> interface EggLayer
>
> {
>public $eggsLaid;
> }
>
> class Chicken implements EggLayer;
>
> Some would say (and maybe I would too) that you should have a
Hi!
But, when you add the possibility of getters and setters, a property
becomes an abstraction. It would make sense that an interface declares
Nothing prevents you from having getters and setters as part of the
interface :)
Properties in interfaces make no sense now, but if we ever get a
Hi!
I understand why Interfaces can't have bodies, but could you explain why
Interfaces can't have properties?
Interfaces are API descriptions. API is usually seen as composed of
functions. Some go even as far as recommending even classes don't have
public properties at all :)
In any case
Carter -X (johncart - PolicyApp Ltd at Cisco)
Cc: internals@lists.php.net
Subject: Re: Re: [PHP-DEV] Class Properties in Interfaces?
On Tue, Apr 29, 2008 at 9:51 AM, John Carter -X (johncart - PolicyApp
Ltd at Cisco) <[EMAIL PROTECTED]> wrote:
The article explicitly mentions OOP int
On Tue, Apr 29, 2008 at 9:51 AM, John Carter -X (johncart - PolicyApp Ltd at
Cisco) <[EMAIL PROTECTED]> wrote:
> The article explicitly mentions OOP interfaces in a few languages.
my bad.
> But
> the article, or for that matter any formal definition of an interface
> isn't really what I asked
om: Nathan Nobbe [mailto:[EMAIL PROTECTED]
Sent: 29 April 2008 16:17
To: John Carter -X (johncart - PolicyApp Ltd at Cisco)
Cc: internals@lists.php.net
Subject: Re: Re: [PHP-DEV] Class Properties in Interfaces?
On Tue, Apr 29, 2008 at 6:28 AM, John Carter -X (johncart - PolicyApp
Ltd at Cisco) <[EM
On Apr 29, 2008, at 3:15 AM, Sebastian Bergmann wrote:
John Carter -X (johncart - PolicyApp Ltd at Cisco) schrieb:
could you explain why Interfaces can't have properties
Because interfaces are implemented which makes no sense for
attributes.
Sebastian,
This is true for the data storage
On Tue, Apr 29, 2008 at 6:28 AM, John Carter -X (johncart - PolicyApp Ltd at
Cisco) <[EMAIL PROTECTED]> wrote:
>
> I think I must be missing something here, but this sounds a little
> tautological - "we can't do it because it doesn't make sense. This is
> because it doesn't make sense"
>
> Certain
nals@lists.php.net
Subject: Re: [PHP-DEV] Class Properties in Interfaces?
John Carter -X (johncart - PolicyApp Ltd at Cisco) schrieb:
> could you explain why Interfaces can't have properties
Because interfaces are implemented which makes no sense for
attributes.
--
Sebastian Bergmann
h
James Dempster schrieb:
you should use getters and setters which you can define in interface
BTW: An attribute with getter and setter is what I would call a
property.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277
PROTECTED]
Sent: 29 April 2008 11:17
To: John Carter -X (johncart - PolicyApp Ltd at Cisco)
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Class Properties in Interfaces?
I would start by saying it's bad design. you should use getters and
setters which you can define in you interface
--
es can't have bodies, but could you explain why
> Interfaces can't have properties?
>
> Thanks,
>
> John.
>
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: 29 April 2008 10:46
> To: Jeremy Privett
> Cc: PHP Devel
John Carter -X (johncart - PolicyApp Ltd at Cisco) schrieb:
could you explain why Interfaces can't have properties
Because interfaces are implemented which makes no sense for attributes.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7
ubject: Re: [PHP-DEV] Class Properties in Interfaces?
Hello Jeremy,
interfaces cannot have properties, nor can they have method bodies -
that is the whole purpose of interfafces. We are thinking of adding
traits which would allow for both but would treat inheritance
differently. Until we get that
Hello Jeremy,
interfaces cannot have properties, nor can they have method bodies - that
is the whole purpose of interfafces. We are thinking of adding traits which
would allow for both but would treat inheritance differently. Until we get
that you would need to provide an abstract interface to a
85 matches
Mail list logo
