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.
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., I have
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, since it works
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
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
classes. Whilst
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 ...
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 bug,
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
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)
$o-Foo-bar = null;
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,
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 think
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:
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 simply
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
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
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 less
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.
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
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-bar = null;
is not?
I Do not
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 *explicitely*
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 changed I
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:
public $property {
__get
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 at this
point
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
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() to modify an
instance in
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() {
return
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 = setProperty;
}
string public
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
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
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 {
string public
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 setProperty(string $value) {}
]
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) [EMAIL PROTECTED] wrote
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
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) [EMAIL PROTECTED] wrote:
I
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;
}
I
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 not
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 handle this
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;
}
string
(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 inheritance (diamond
style
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 __get() { return
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 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 defined.
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 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
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 using
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
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
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
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 with
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
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
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
: [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 you would
, 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 Developers Mailing List
Subject: Re: [PHP-DEV] Class Properties in Interfaces?
Hello
]
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
--
/James
On Tue
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
: [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
http://sebastian-bergmann.de/
GnuPG Key
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
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
Certainly most
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
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) [EMAIL PROTECTED
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
(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 interfaces in a few
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
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
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
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,
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
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
properties. I would
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:
1. We can't
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 Cisco) wrote:
I
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]:
On Tue, 2008-04-29 at
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
in the air and
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 say
but
when,
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 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 to
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 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
fundamentally
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
Hey list,
I was curious what everyone thought of implementing the ability to
specify class members in interfaces. I've run into a couple of
circumstances where I would like to specify public member names inside
of an interface to ensure that these members are accessed in a standard
way and
80 matches
Mail list logo
