Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
2012/10/15 Clint Priest cpri...@zerocue.com
Also, your should be valid statement implies that you feel properties
and accessors are the same and they are not, internally. When a class
attempts to implement an interface a function check is done and since
there is no __getXX() function defined it would fail to implementation
check against an interface.
I cannot stress enough that properties != accessors in any way except the
syntax in which they are used ($o-xyz) or ($o-xyz = 1), that is their
*only* similarity.
I disagree. That's why I said this is a matter of choice. A philosophical
choice.
I don't see properties and accessors like different things which are
accidentally written the same. Accessors are a layer upon properties. It's
a magical layer, trying to mimic accessors.
It's a bit like aspect-oriented programming: you can add layer but the core
is still the same (from a developper point of view, not from the PHP
interpreter point of view).
See another argument: My proposal for read/write accessibility definition.
When I suggested to allow this syntax: public:private $abc;
some people objected that it's the same than public $abc { get; private
set; }
So, if I understand what you said, for you it's deeply different and
comparing them is like comparing apples and oranges. I disagree. I still
think my syntax is better (and could be implemented with better
performance), but it's normal to compare them, because they (can) offer
pretty much the same functionnalities.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
I prefer the current syntax to your proposal because:
1) It is not at all obvious which side is which. Example:
*protected:private
*Is protected* *for get? Or set? The average PHP developer will have no
idea. In fact, they likely won't know that they even correlate to get and
set.
2) There is no such syntax already in PHP. (And on a more personal note, I
don't think I've ever seen that syntax in any other language that I've
worked in before. Which means it's even *more-so* out of people's comfort
zones.)
The current read/write syntax works, and none of the discussion I've read
thus far would sway me towards any other option.
That being said, I wouldn't contest to hearing - in more detail - your
reasoning behind why we should use it instead of the current syntax.
On Tue, Oct 16, 2012 at 12:39 AM, Amaury Bouchard ama...@amaury.net wrote:
2012/10/15 Clint Priest cpri...@zerocue.com
Also, your should be valid statement implies that you feel properties
and accessors are the same and they are not, internally. When a class
attempts to implement an interface a function check is done and since
there is no __getXX() function defined it would fail to implementation
check against an interface.
I cannot stress enough that properties != accessors in any way except the
syntax in which they are used ($o-xyz) or ($o-xyz = 1), that is their
*only* similarity.
I disagree. That's why I said this is a matter of choice. A philosophical
choice.
I don't see properties and accessors like different things which are
accidentally written the same. Accessors are a layer upon properties. It's
a magical layer, trying to mimic accessors.
It's a bit like aspect-oriented programming: you can add layer but the core
is still the same (from a developper point of view, not from the PHP
interpreter point of view).
See another argument: My proposal for read/write accessibility definition.
When I suggested to allow this syntax: public:private $abc;
some people objected that it's the same than public $abc { get; private
set; }
So, if I understand what you said, for you it's deeply different and
comparing them is like comparing apples and oranges. I disagree. I still
think my syntax is better (and could be implemented with better
performance), but it's normal to compare them, because they (can) offer
pretty much the same functionnalities.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
Hi! public DateTime $date; This is *real* progress, even if under the hood all it does is wrap I think it's a movement in wrong direction. Again, it is an attempt to make PHP a strongly typed language, which would not work well in a dynamic language like PHP, for reasons that were amply explained in 9000 discussions we had on this topic before. functions and use function type-hints. This piece of code is SO much shorter and cleaner. Will it be a bit confusing to new developers? Maybe, but I don't care. It is not aimed at making the lives of new I think you should care. PHP is a beginner's language, it always was its core market. Adding more and more complicated features that benefit 0.1% of developers in PHP is a new direction, and I'm not sure at all it is a good direction for PHP to take. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Hi! The RFC states ReflectionClass::getMethods() will not return accessor functions (hides implementation detail). Up until now reflection is leaky and is telling the truth. We should either keep that or completely clean up reflection. (mind also get_class_methods() and such) I think the reflection should return all methods that exist. If the accessors are implemented as PHP methods/functions (and I see no reason why not) then reflection should return it. Reflection, as you pointed out, should tell the truth. There's nothing leaky about it, IMO - yes, it's an implementation detail, so what? If you don't want to use implementation details, don't - just ignore all __ functions and don't call them. Python, for example, has tons of __ functions, and people live just fine with it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Hi!
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
My feedback on the RFC:
1. Accessors IMO should be regular PHP methods that PHP generates with
two additional things:
a. Their name is generated by PHP
b. Their argument set is defined by the accessor pattern (i.e. same
thing as __get/__set).
We should keep the amount of magic and special cases to the minimum, the
engine is complex enough as it is.
This of course includes the full range of options available for the
methods - final, reflection, call scenarios, etc.
2. isset is defined as:
isset() { return $this-Hours != NULL; }
This does not seem to be correct - != NULL does not work like isset now.
Try this:
class A { public $x = 0; }
$a = new A;
var_dump(isset($a-x));
var_dump($a-x != NULL);
This needs to be fixed - generated isset() should be defined to work
exactly like regular isset and actually use the same code path. Argument
to isset() call can be retrieved using accessor but it should not differ
from isset() result in any possible way or situation (including error
situations - e.g. notices, etc.)
3. How references and complex cases are handled? Didn't find anything
about it, e.g. how it handles $foo-bar++, $foo-bar[] = 1,
$foo-bar[123] = 4, etc. ($foo-bar being property with get/set defined
of course)? How $foobar = $foo-bar is handled? The sort() case
mentions by-ref return but does not explicitly mention all other cases.
These need to be covered explicitly in the RFC.
4. We have some LSP controls now in place to ensure non-LSP overrides
generate E_STRICT. Will this be the case for properties too? Meaning,
what happens if you add overriding protected getter to a property that
was previously fully public - thus violating the LSP?
5. What happens if you override accessor property with plain old
variable property? I.e.:
class A {
protected $secret {
get() { return secret; }
}
}
class B extends A {
public $secret = not a secret anymore;
}
Also, what happens here if A extends B in the same scenario (this refers
to the #4 too).
6. Thinking more about isset/unset - why not make isset/unset always be
the default unless overridden? I can't really see the case where you
want echo $foo-bar to work but if(isset($foo-bar)) echo $foo-bar to
not work. I think isset() and unset() should always use automatic
implementations by default (fixed in accord with #2 of course).
7. Error messaging section is not clear. Some examples would help -
what is being translated to what?
8. Static accessors section is not clear, namely this one:
This yielded the possibility that a getter call was being made while it
should not be allowed (if there was no getter defined) and so pass_two()
was changed to look for these non-backpatched illegal static getter
calls and a compile time error is produced.
When the code is compiled, the class definition (and, in fact, the name
of the class we're talking about) may not be available, so how can you
known if certain property of this class has getters defined?
Also, I'm not sure what is the thing about backpatching and converting
to function calls - I think it should work via engine handlers just as
the rest of the things work in the engine, is it not the case? If not,
it should be made the case.
9. This:
Eliminate the ability for an accessor to be called via $o→__getHours(),
the accessor functions will be completely unavailable for use except as
property references ($o→Hours)
I think it a mistake. More magic and complication in the engine is not a
good thing and would require tons of special case checks in all places
where we deal with functions. I think it is wrong - if we create a
callable entity, it should be callable. __ in the name is the indication
enough that you're dealing with special method and you should tread
carefully, we should not go out of our way to mess up the engine to
prevent it.
10. I'm not sure what the point about debug_backtrace() is but again, we
should not create more complicated magic there, it just should show what
really is happening.
11. About read-only/write-only thing - I like not having the keywords,
but it is still not clear how final produces read-only property - do I
say something like final set(); or how can I say there's no set and
never will be?
I'm sorry if some points were already discussed - I scanned through the
multiple threads but may very well missed something in 100+ messages
that there are, in any case I feel most of the questions above must be
reflected in RFC explicitly.
Thanks,
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Hi! Does the PHP programmer need the truth of underlying language implementation details or do they need the truth of what they've defined? If the method exists, he needs to know it exists. For the rest, see below. I would argue that if the PHP programmer has defined a property accessor then the truth to him/her is that it's a property accessor and should be reflected as such. The fact that the underlying php One does not contradict the other. Reflection can have specific calls to see properties and accessors, but if accessors are PHP methods - which they should be, since producing more unneeded separate entities that look like methods but aren't quite is wrong - they also should be seen as methods. See for example in Python - special methods have __ to specify they aren't something you should mess with, but they also do not go out of the way to make it a separate concept. We should do the same. We could have option for Reflection to skip __ methods in list calls, maybe - if there's a use case for it - but I currently do not see any use case for it at all. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Hi! What remains on your TODO list for this functionality? When are you planning to run an RFC vote on this? I think this would be a valuable addition to PHP 5.5. I think we shouldn't rush with votes on this until all fine details aren't hashed out. This is a *huge* feature - one of the biggest ones recently, and has a lot of implications for various scenarios. Property access is what virtually every script in existence does, and doing changes there have implications that touch every corner of the engine. I think Clint is doing a great job with this RFC, but we need to carefully work through all the corners and side cases and relationships with all other features before we can declare it's ready for the prime time. Exactly because it is such a big deal it needs to be refined and polished. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
This discussion is opened in the dedicated thread. I used my proposal as an
example to illustrate my point of view, not to pollute this thread.
2012/10/16 Jazzer Dane tbprogram...@gmail.com
I prefer the current syntax to your proposal because:
1) It is not at all obvious which side is which. Example:
*protected:private
*Is protected* *for get? Or set? The average PHP developer will have
no idea. In fact, they likely won't know that they even correlate to get
and set.
2) There is no such syntax already in PHP. (And on a more personal note,
I don't think I've ever seen that syntax in any other language that I've
worked in before. Which means it's even *more-so* out of people's comfort
zones.)
The current read/write syntax works, and none of the discussion I've read
thus far would sway me towards any other option.
That being said, I wouldn't contest to hearing - in more detail - your
reasoning behind why we should use it instead of the current syntax.
On Tue, Oct 16, 2012 at 12:39 AM, Amaury Bouchard ama...@amaury.netwrote:
2012/10/15 Clint Priest cpri...@zerocue.com
Also, your should be valid statement implies that you feel properties
and accessors are the same and they are not, internally. When a class
attempts to implement an interface a function check is done and since
there is no __getXX() function defined it would fail to implementation
check against an interface.
I cannot stress enough that properties != accessors in any way except
the
syntax in which they are used ($o-xyz) or ($o-xyz = 1), that is their
*only* similarity.
I disagree. That's why I said this is a matter of choice. A philosophical
choice.
I don't see properties and accessors like different things which are
accidentally written the same. Accessors are a layer upon properties. It's
a magical layer, trying to mimic accessors.
It's a bit like aspect-oriented programming: you can add layer but the
core
is still the same (from a developper point of view, not from the PHP
interpreter point of view).
See another argument: My proposal for read/write accessibility definition.
When I suggested to allow this syntax: public:private $abc;
some people objected that it's the same than public $abc { get; private
set; }
So, if I understand what you said, for you it's deeply different and
comparing them is like comparing apples and oranges. I disagree. I still
think my syntax is better (and could be implemented with better
performance), but it's normal to compare them, because they (can) offer
pretty much the same functionnalities.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
Hi! I think that accessors should be allowed with interfaces because an interface really is a specification on how to communicate and while accessors do pass messages, properties do not. Communicate is a loaded term. Property access is communication too, but properties aren't defined in the interfaces. In any case, if you're allowing accessors in interface, you should bring back automatic implementation of accessors, since if you're saying you must provide property $a I should be able to say OK, here's property $a, working exactly as plain old PHP property. Either that or I'd have to write a boilerplate code (and make a couple of errors on the way such as breaking references and isset, which 99% of less-experienced PHP programmers would do). I think accessors in interfaces are a huge can of worms because of their potential of mixing function calls and property access, while the latter is traditionally not the domain of the interface. We should carefully consider if we really have use case for it. Especially given that PHP always has underlying default property access functionality that is always available - unlike methods which if not defined lead to fatal error. So while if you do $foo-bar() on wrong $foo it will break, if you do $foo-bar on wrong $foo yu just get default behavior. Given that, do we really need an interface there? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
#2: I agree with you here - this is problematic. isset/unset accessors that
invoke the isset/unset function should actually invoke the function rather
than being compared to null, as that isn't the same as isset.
#5: From what I understand, an extending class can not override an accessor
with a non-accessor.
#11: If you set an accessor's get or set to *final private*, you are not
able to extend and it are only able to invoke it from the current class. If
you don't invoke it, then it is virtually read or write only.
On Tue, Oct 16, 2012 at 2:12 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
My feedback on the RFC:
1. Accessors IMO should be regular PHP methods that PHP generates with
two additional things:
a. Their name is generated by PHP
b. Their argument set is defined by the accessor pattern (i.e. same
thing as __get/__set).
We should keep the amount of magic and special cases to the minimum, the
engine is complex enough as it is.
This of course includes the full range of options available for the
methods - final, reflection, call scenarios, etc.
2. isset is defined as:
isset() { return $this-Hours != NULL; }
This does not seem to be correct - != NULL does not work like isset now.
Try this:
class A { public $x = 0; }
$a = new A;
var_dump(isset($a-x));
var_dump($a-x != NULL);
This needs to be fixed - generated isset() should be defined to work
exactly like regular isset and actually use the same code path. Argument
to isset() call can be retrieved using accessor but it should not differ
from isset() result in any possible way or situation (including error
situations - e.g. notices, etc.)
3. How references and complex cases are handled? Didn't find anything
about it, e.g. how it handles $foo-bar++, $foo-bar[] = 1,
$foo-bar[123] = 4, etc. ($foo-bar being property with get/set defined
of course)? How $foobar = $foo-bar is handled? The sort() case
mentions by-ref return but does not explicitly mention all other cases.
These need to be covered explicitly in the RFC.
4. We have some LSP controls now in place to ensure non-LSP overrides
generate E_STRICT. Will this be the case for properties too? Meaning,
what happens if you add overriding protected getter to a property that
was previously fully public - thus violating the LSP?
5. What happens if you override accessor property with plain old
variable property? I.e.:
class A {
protected $secret {
get() { return secret; }
}
}
class B extends A {
public $secret = not a secret anymore;
}
Also, what happens here if A extends B in the same scenario (this refers
to the #4 too).
6. Thinking more about isset/unset - why not make isset/unset always be
the default unless overridden? I can't really see the case where you
want echo $foo-bar to work but if(isset($foo-bar)) echo $foo-bar to
not work. I think isset() and unset() should always use automatic
implementations by default (fixed in accord with #2 of course).
7. Error messaging section is not clear. Some examples would help -
what is being translated to what?
8. Static accessors section is not clear, namely this one:
This yielded the possibility that a getter call was being made while it
should not be allowed (if there was no getter defined) and so pass_two()
was changed to look for these non-backpatched illegal static getter
calls and a compile time error is produced.
When the code is compiled, the class definition (and, in fact, the name
of the class we're talking about) may not be available, so how can you
known if certain property of this class has getters defined?
Also, I'm not sure what is the thing about backpatching and converting
to function calls - I think it should work via engine handlers just as
the rest of the things work in the engine, is it not the case? If not,
it should be made the case.
9. This:
Eliminate the ability for an accessor to be called via $o→__getHours(),
the accessor functions will be completely unavailable for use except as
property references ($o→Hours)
I think it a mistake. More magic and complication in the engine is not a
good thing and would require tons of special case checks in all places
where we deal with functions. I think it is wrong - if we create a
callable entity, it should be callable. __ in the name is the indication
enough that you're dealing with special method and you should tread
carefully, we should not go out of our way to mess up the engine to
prevent it.
10. I'm not sure what the point about debug_backtrace() is but again, we
should not create more complicated magic there, it just should show what
really is happening.
11. About read-only/write-only thing - I like not having the keywords,
but it is still not clear how final produces read-only property - do I
say something like final set(); or how can I say there's no set and
never will be?
I'm sorry if some points
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Hi!
#5: From what I understand, an extending class can not override an
accessor with a non-accessor.
This should be in the RFC then - along with what exactly happens. Note
that this will represent a sort of BC break in terms that you could have
two properties $a before, but if you change implementation of $a in base
class from plain old property to accessor property, the child class
would break. Which is not good, since compatible changes in parent class
should not break child classes - and which will also impede adoption of
this feature, since you can not guarantee no child class does it.
#11: If you set an accessor's get or set to /final private/, you are not
able to extend and it are only able to invoke it from the current class.
If you don't invoke it, then it is virtually read or write only.
I get this, but what do you write as a method body if you want to just
disallow it? Do you write just {}? Then it's not good for get() since
get() is supposed to return a value, and also not good for set() since
base class still can call private methods, and we want set() to be not
available for everybody.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
2012/10/16 Stas Malyshev smalys...@sugarcrm.com public DateTime $date; This is *real* progress, even if under the hood all it does is wrap I think it's a movement in wrong direction. Again, it is an attempt to make PHP a strongly typed language, which would not work well in a dynamic language like PHP, for reasons that were amply explained in 9000 discussions we had on this topic before. Not necessarily strongly typed. (sorry to land on this topic afterwards) As I see PHP, it's a language that can be used as an informal scripting language, but also as a rock-solid modern tool. Type hinting in parameters is a really good thing, and it doesn't transformed PHP in a strongly typed language. Doing the same for object properties (always optional) could be very useful.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
Hi! Not necessarily strongly typed. (sorry to land on this topic afterwards) As I see PHP, it's a language that can be used as an informal scripting language, but also as a rock-solid modern tool. I have no idea what rock-solid modern tool means, though PHP is trivially a modern tool by being a tool and existing right now ;) Type hinting in parameters is a really good thing, and it doesn't transformed PHP in a strongly typed language. It however gave a permission to people to try sneak in strong-typedness through various backdoors arguing exactly that: but we have strong typing for parameters, why not for other things? I think it is not the right approach. Also, the fact is that other dynamic languages do not have strong typing. It may be they just aren't smart enough to recognize everybody needs it - or there may be a reason why it doesn't happen. I think there is a reason, which again was outlined some 9000 times here on the list. Doing the same for object properties (always optional) could be very useful. Not really, since PHP is not a compiled language and as such does not have static type controls. Now not only every foo($bar) can blow up but also every $foo-bar = $baz. Not very useful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
Hi! Not necessarily strongly typed. (sorry to land on this topic afterwards) As I see PHP, it's a language that can be used as an informal scripting language, but also as a rock-solid modern tool. I have no idea what rock-solid modern tool means, though PHP is trivially a modern tool by being a tool and existing right now ;) Type hinting in parameters is a really good thing, and it doesn't transformed PHP in a strongly typed language. It however gave a permission to people to try sneak in strong-typedness through various backdoors arguing exactly that: but we have strong typing for parameters, why not for other things? I think it is not the right approach. Also, the fact is that other dynamic languages do not have strong typing. It may be they just aren't smart enough to recognize everybody needs it - or there may be a reason why it doesn't happen. I think there is a reason, which again was outlined some 9000 times here on the list. Doing the same for object properties (always optional) could be very useful. Not really, since PHP is not a compiled language and as such does not have static type controls. Now not only every foo($bar) can blow up but also every $foo-bar = $baz. Not very useful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Hi!
In regards to #11, yes, you'd just write {}. I imagine you could also
This doesn't work for the same class (and for traits which put things in
the context of the same class) - it would not behave as no setter, it
would behave as there's a setter doing nothing. Is this the proposed
solution?
Exception is a possibility but then everybody would do it differently
which reduces the value of standardizing it (the whole point of having
accessors since otherwise we could just do __get and throw exceptions).
We went through multiple alternative options to read/write-only, and the
implementation you see in the 1.2 RFC is the most widely agreed upon
proposal. I don't doubt that there is room for improvement in this area,
but we haven't had any further proposals as of yet.
Actually, I do not see anything explicitly said in the proposal that
works for the cases outlined above. I wanted to just make sure if that
means no solution currently (then should be on TODO list) or we have
a solution but it's not outlined in the RFC (should be added then).
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Stas, the proposed solution thus far is to make the getter or setter
final and private and not have a body. This would naturally throw an
exception if it was accessed from anywhere but the class it was defined.
The class it was defined in has to remember that it is virtually a
read/write only accessor.
Although it has not been proposed yet, perhaps the above can be further
enforced by automatically throwing an exception whenever a getter/setter
exists but does not have a body.
Nevertheless, the solution is, as you can see, pretty loose right now,
and I definitely wouldn't object to hearing and discussing alternative
proposals.
On Tue, Oct 16, 2012 at 3:18 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
In regards to #11, yes, you'd just write {}. I imagine you could also
This doesn't work for the same class (and for traits which put things in
the context of the same class) - it would not behave as no setter, it
would behave as there's a setter doing nothing. Is this the proposed
solution?
Exception is a possibility but then everybody would do it differently
which reduces the value of standardizing it (the whole point of having
accessors since otherwise we could just do __get and throw exceptions).
We went through multiple alternative options to read/write-only, and the
implementation you see in the 1.2 RFC is the most widely agreed upon
proposal. I don't doubt that there is room for improvement in this area,
but we haven't had any further proposals as of yet.
Actually, I do not see anything explicitly said in the proposal that
works for the cases outlined above. I wanted to just make sure if that
means no solution currently (then should be on TODO list) or we have
a solution but it's not outlined in the RFC (should be added then).
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
I haven't done an exhaustive analysis of every language out there that supports
interfaces but to my knowledge there isn't a single one that supports
properties in interfaces. Again, not exhaustive either but there is one
language that does support accessors in interfaces and that's C#.
When I refer to communicate for an interface I am referring to the fact that
if a property were allowed and a consumer of an object which implements that
property changes that property, the object will not know about it until it has
its own code run through some other method, whereas with an accessor the object
will hear about it right away.
Think about it, if you allowed an outside caller of your class to modify your
internal state, any time you needed to use that internal state you would have
to validate it before you could rely upon its value to be set correctly. No
such issue exists with accessors in an interface as the communication about its
change attempt is resolved immediately (and can be rejected or accepted).
Just to be a bit more concrete here, as the code is presently written and
because I have strongly separated the concept of a property vs an accessor,
this code:
interface a {
public $xyz { get; }
}
class b implements a {
public $xyz;
}
Produces the following error:
Fatal error: Class b contains 3 abstract accessors and must be declared
abstract or implement the remaining accessors (get a::$xyz, isset a::$xyz, ...)
in %s on line %d
This fatal error actually occurs during the *function check* phase of interface
checking, because public $xyz {get;} represents a set of functions that must be
defined (accessors).
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, October 16, 2012 4:37 AM
To: Clint Priest
Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
Hi!
I think that accessors should be allowed with interfaces because an
interface really is a specification on how to communicate and while
accessors do pass messages, properties do not.
Communicate is a loaded term. Property access is communication too, but
properties aren't defined in the interfaces. In any case,
if you're allowing accessors in interface, you should bring back automatic
implementation of accessors, since if you're saying you
must provide property $a I should be able to say OK, here's property $a,
working exactly as plain old PHP property. Either that or
I'd have to write a boilerplate code (and make a couple of errors on the way
such as breaking references and isset, which 99% of
less-experienced PHP programmers would do).
I think accessors in interfaces are a huge can of worms because of their
potential of mixing function calls and property access, while
the latter is traditionally not the domain of the interface. We should
carefully consider if we really have use case for it. Especially
given that PHP always has underlying default property access functionality
that is always available - unlike methods which if not
defined lead to fatal error. So while if you do $foo-bar() on wrong $foo it
will break, if you do $foo-bar on wrong $foo yu just get
default behavior. Given that, do we really need an interface there?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
I would have to agree with Stas, the type hints that are presently implemented are failed code waiting to be found. Good luck if you're not monitoring your error logs. I can agree with the concept of wanting to avoid having to do all kinds of simple verification of input parameters but thankfully type hinting is optional. I think if it had been done differently, at least when possible, such that errors occurring during compile time and thus could be -linted it would have been much more useful, re: the concept of fail early. -Clint -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Tuesday, October 16, 2012 4:58 AM To: Amaury Bouchard Cc: Levi Morrison; Clint Priest; internals@lists.php.net; Nikita Popov (nikita@gmail.com) Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax Hi! Not necessarily strongly typed. (sorry to land on this topic afterwards) As I see PHP, it's a language that can be used as an informal scripting language, but also as a rock-solid modern tool. I have no idea what rock-solid modern tool means, though PHP is trivially a modern tool by being a tool and existing right now ;) Type hinting in parameters is a really good thing, and it doesn't transformed PHP in a strongly typed language. It however gave a permission to people to try sneak in strong-typedness through various backdoors arguing exactly that: but we have strong typing for parameters, why not for other things? I think it is not the right approach. Also, the fact is that other dynamic languages do not have strong typing. It may be they just aren't smart enough to recognize everybody needs it - or there may be a reason why it doesn't happen. I think there is a reason, which again was outlined some 9000 times here on the list. Doing the same for object properties (always optional) could be very useful. Not really, since PHP is not a compiled language and as such does not have static type controls. Now not only every foo($bar) can blow up but also every $foo-bar = $baz. Not very useful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
At this point, the last two weeks of deliberations on this RFC have pushed its release back quite a long ways. I don't know when 5.5 is due out but if it's within the next 6 months (and I'm the only one working on the code) then it will probably not be happening. Due to the dramatic changes that have been talked about, I may just scrap the fork and start over, since I've learned a lot about php-core since starting this a year ago. -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Tuesday, October 16, 2012 4:27 AM To: Paul Dragoonis Cc: Clint Priest; internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 Hi! What remains on your TODO list for this functionality? When are you planning to run an RFC vote on this? I think this would be a valuable addition to PHP 5.5. I think we shouldn't rush with votes on this until all fine details aren't hashed out. This is a *huge* feature - one of the biggest ones recently, and has a lot of implications for various scenarios. Property access is what virtually every script in existence does, and doing changes there have implications that touch every corner of the engine. I think Clint is doing a great job with this RFC, but we need to carefully work through all the corners and side cases and relationships with all other features before we can declare it's ready for the prime time. Exactly because it is such a big deal it needs to be refined and polished. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
2012/10/16 Stas Malyshev smalys...@sugarcrm.com Also, the fact is that other dynamic languages do not have strong typing. It may be they just aren't smart enough to recognize everybody needs it - or there may be a reason why it doesn't happen. I think there is a reason Doing the same for object properties (always optional) could be very useful. Not really, since PHP is not a compiled language and as such does not have static type controls. Now not only every foo($bar) can blow up but also every $foo-bar = $baz. Not very useful. If the first could be useful, the second could be useful too. Or you are saying that parameters type hinting was a bad idea? You can argue using other languages' design choices, but it shouldn't drive our own choices. Every methods and properties are public in Python; it doesn't mean PHP is doing wrong (nor Python is doing wrong). Last thing: I agree with Clint and you. If it was early checked, it would be better. But the current type hinting is far better than nothing at all. Yes, we can't lint it, but it was pretty useful a big number of times in my company. was outlined some 9000 times here on the list. OK, sorry for the trouble.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Hi! Stas, the proposed solution thus far is to make the getter or setter final and private and not have a body. This would naturally throw an exception if it was accessed from anywhere but the class it was defined. The class it was defined in has to remember that it is virtually a read/write only accessor. What you mean by not have a body - is there special syntax for body-less methods introduced? Then it should be in the RFC. How it is implemented - what exactly is stored in the function table then? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
I apologize for my confusing terminology - let me elaborate. There are no
special syntaxes. The below code should help clear things up a bit:
class MyClass {
private $otherProperty;
public $property {
get() {}; // Does not have a body, as there is no code between the
curly braces.
set($value) { $this-otherProperty = $value; } // Does have a body,
as there IS code between the curly braces.
}
}
On Tue, Oct 16, 2012 at 3:48 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Stas, the proposed solution thus far is to make the getter or setter
final and private and not have a body. This would naturally throw an
exception if it was accessed from anywhere but the class it was defined.
The class it was defined in has to remember that it is virtually a
read/write only accessor.
What you mean by not have a body - is there special syntax for
body-less methods introduced? Then it should be in the RFC. How it is
implemented - what exactly is stored in the function table then?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
Hi! If the first could be useful, the second could be useful too. Or you are saying that parameters type hinting was a bad idea? Given how it is understood now - as a first step to make PHP a strongly typed language - yes, I'm starting to think it was. If it was understood as it was intended - as a small hack to catch obvious code failures - then it'd be OK (not that great, but fine) idea, but given that more and more people misunderstand it as declaration of intent for PHP to be strongly typed language - I think maybe we would be better off not doing that after all. Last thing: I agree with Clint and you. If it was early checked, it would be better. But the current type hinting is far better than nothing at all. Yes, we can't lint it, but it was pretty useful a big number No, it's not better. Having code that can randomly fail with one error message is not better than having code that can randomly fail with another error message. It is more or less the same. It can actually be worse since it'd introduce more boliterplate checks in wrong places (i.e., you'd have to check every variable for correct type before assigning it to typed property) and does not provide any control over how the situation when something is wrong is going to be handled. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Hi!
I apologize for my confusing terminology - let me elaborate. There are
no special syntaxes. The below code should help clear things up a bit:
class MyClass {
private $otherProperty;
public $property {
get() {}; // Does not have a body, as there is no code between
the curly braces.
It does have a body. This body is just default empty method body
returning null - which does not throw any exceptions and is completely
indistinguishable from the outside from property being equal to null.
I'm not sure it's what the intent of *-only variable is, though I guess
it is a way to hack around it. I wonder however if it can be done better.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
Hi!
that supports properties in interfaces. Again, not exhaustive either
but there is one language that does support accessors in interfaces
and that's C#.
So what C# does when mixing regular properties and accessorized properties?
Think about it, if you allowed an outside caller of your class to
modify your internal state, any time you needed to use that internal
state you would have to validate it before you could rely upon its
value to be set correctly. No such issue exists with accessors in an
I do not see why this assumption is made that I need to do some special
validation each time state is changed. In fact, in 99% of existing code
it is not happening, and I assume this ratio will be kept even when
accessors are available. Most code will be very straightforward, not
doing anything complex with the state.
Now, I think the bigger question is: what exactly you want to
say/require when you write:
interface a { public $xyz { get; } }
and what is the use case for this requirement?
Just to be a bit more concrete here, as the code is presently written
and because I have strongly separated the concept of a property vs an
accessor, this code:
interface a { public $xyz { get; } }
class b implements a { public $xyz; }
Produces the following error: Fatal error: Class b contains 3
abstract accessors and must be declared abstract or implement the
remaining accessors (get a::$xyz, isset a::$xyz, ...) in %s on line
%d
I think this is wrong. 3 abstract accessors is especially wrong since it
doesn't match the direct interface definition and is very confusing (see
my earlier point about isset/unset always having fallback defaults) but
even with get as abstract I do not see a valid use case that would
require such behavior. What you want is for any $foo that is instanceof
a to be able to respond to read request to $foo-xyz, right? Class b
satisfies this requirement, why you reject it then?
Also, if you reject it - how I should fix it to make it work? Would I
have to implement a bolierplate getter/setter just to make interface
work? Doesn't look like a good proposition to me.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Excuse my late-night-influenced terminology, the word empty is much more
suitable than does not have.
And this solution really is more of a hack or work-around than a solution.
I do think that there is a better way to go about implementing
read/write-only, but nothing has come to mind as of yet - at least nothing
that doesn't completely change major aspects of this RFC.
On Tue, Oct 16, 2012 at 3:59 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
I apologize for my confusing terminology - let me elaborate. There are
no special syntaxes. The below code should help clear things up a bit:
class MyClass {
private $otherProperty;
public $property {
get() {}; // Does not have a body, as there is no code between
the curly braces.
It does have a body. This body is just default empty method body
returning null - which does not throw any exceptions and is completely
indistinguishable from the outside from property being equal to null.
I'm not sure it's what the intent of *-only variable is, though I guess
it is a way to hack around it. I wonder however if it can be done better.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Hey Stas, a bunch of this has already been covered but I will attempt to answer
each of these as is my current understanding of the hives decision... :P
1. Accessors IMO should be regular PHP methods that PHP generates with two
additional things:
a. Their name is generated by PHP
b. Their argument set is defined by the accessor pattern (i.e. same thing as
__get/__set).
We should keep the amount of magic and special cases to the minimum, the
engine is complex enough as it is.
This of course includes the full range of options available for the methods -
final, reflection, call scenarios, etc.
This is the way it is, though Nikita strongly disagrees that they should be
callable, visible methods on the object and I agree with Nikita on this
issue, I never did like the idea that __getHours() and __setHours() were
methods of a class just because of an accessor definition, which is why I
worked to have Reflection hide that fact. If I were to go about this again,
they probably will not be methods of the class. Internally there is little
requiring an op_array to be attached to a class in order to be executed.
2. isset is defined as:
isset() { return $this-Hours != NULL; } This does not seem to be
correct - != NULL does not work like isset now.
Try this:
class A { public $x = 0; }
$a = new A;
var_dump(isset($a-x));
var_dump($a-x != NULL);
This needs to be fixed - generated isset() should be defined to work exactly
like regular isset and actually use the same code path.
Argument to isset() call can be retrieved using accessor but it should not
differ from isset() result in any possible way or situation
(including error situations - e.g. notices, etc.)
The reason that = NULL and != NULL was chosen is because isset() and unset()
are special states that are available only to a variable or property, since a
get/set do not return a real property they cannot be used with isset/unset.
Now that there has been discussion of an accessor being a real property
shadowed by get/set, standard isset/unset could potentially be used against the
underlying property.
3. How references and complex cases are handled? Didn't find anything about
it, e.g. how it handles $foo-bar++, $foo-bar[] = 1,
$foo-bar[123] = 4, etc. ($foo-bar being property with get/set defined of
course)? How $foobar = $foo-bar is handled? The sort()
case mentions by-ref return but does not explicitly mention all other cases.
These need to be covered explicitly in the RFC.
This is covered in the RFC, perhaps not clearly enough (let me know how I could
expand on it further for clarity). To answer each of your questions, you can
think of what would happen as if it were a function call. For example, if you
did $foo-bar()[123] = 4 you would be modifying a return-by-val. If bar were
instead defined as returning a reference, then it would indeed work as you
expect above. $foobar = $foo-bar would work as expected as long as the
getter is returning a reference as well.
I, perhaps mistakenly, assumed that if return-by-ref and sort() worked
properly, then all other usages of references should equally work the same,
is that not right? If it's not right, why not?
4. We have some LSP controls now in place to ensure non-LSP overrides
generate E_STRICT. Will this be the case for properties too?
Meaning, what happens if you add overriding protected getter to a property
that was previously fully public - thus violating the LSP?
Certainly, this basic object oriented functionality, of course it is upheld.
This is one of the reasons I leveraged standard functions in the first place,
because these issues were automatically handled by the existing core.
5. What happens if you override accessor property with plain old variable
property? I.e.:
class A {
protected $secret {
get() { return secret; }
}
}
class B extends A {
public $secret = not a secret anymore; }
Also, what happens here if A extends B in the same scenario (this refers to
the #4 too).
This is currently up in the air on the RFC side and is being referred to as
which shadows which. The code currently has it that properties shadow
accessors, Nikita suggested that should be inverted and I agree, so unless
someone else thinks otherwise, accessors will probably shadow properties.
6. Thinking more about isset/unset - why not make isset/unset always be the
default unless overridden? I can't really see the case
where you want echo $foo-bar to work but if(isset($foo-bar)) echo $foo-bar
to not work. I think isset() and unset() should always
use automatic implementations by default (fixed in accord with #2 of course).
See response to #2 above, without a getter/setter returning a real property,
isset/unset accessors were necessary because isset()/unset() cannot perform on
a dynamic value. Consider this: unset($foo-bar()) or isset($foo-bar()).
Since we are moving in the direction of accessors
RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, October 16, 2012 6:06 AM
To: Clint Priest
Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
Hi!
that supports properties in interfaces. Again, not exhaustive either
but there is one language that does support accessors in interfaces
and that's C#.
So what C# does when mixing regular properties and accessorized properties?
I'd have to do some research to know for sure, but it's highly likely that they
cannot be mixed.
Think about it, if you allowed an outside caller of your class to
modify your internal state, any time you needed to use that internal
state you would have to validate it before you could rely upon its
value to be set correctly. No such issue exists with accessors in an
I do not see why this assumption is made that I need to do some special
validation each time state is changed. In fact, in 99% of
existing code it is not happening, and I assume this ratio will be kept even
when accessors are available. Most code will be very
straightforward, not doing anything complex with the state.
If you have a public property $a which internally can only deal with it being
set to 2 or 3 and someone external to the class sets it to 4, your class either
has to check that it's 2 or 3 and deal with the fact that it is now 4 or have
indeterminate results when it is set to 4.
Now, I think the bigger question is: what exactly you want to say/require
when you write:
interface a { public $xyz { get; } }
and what is the use case for this requirement?
The use case is that you are declaring that interface a must allow a property
$xyz to be readable and *not* writable.
Just to be a bit more concrete here, as the code is presently written
and because I have strongly separated the concept of a property vs an
accessor, this code:
interface a { public $xyz { get; } }
class b implements a { public $xyz; }
Produces the following error: Fatal error: Class b contains 3 abstract
accessors and must be declared abstract or implement the remaining
accessors (get a::$xyz, isset a::$xyz, ...) in %s on line %d
I think this is wrong. 3 abstract accessors is especially wrong since it
doesn't match the direct interface definition and is very
confusing (see my earlier point about isset/unset always having fallback
defaults) but even with get as abstract I do not see a valid
use case that would require such behavior. What you want is for any $foo that
is instanceof a to be able to respond to read request
to $foo-xyz, right? Class b satisfies this requirement, why you reject it
then?
Also, if you reject it - how I should fix it to make it work? Would I have to
implement a bolierplate getter/setter just to make
interface work? Doesn't look like a good proposition to me.
Class b does not satisfy the requirement because you are missing the fact that
public $xyz { get; } forbids setting of $xyz, only reading it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
private final get/set() {} is indeed not a read/write only functionality. I
really would like to keep new keywords out of whatever syntax is
implemented, but I think the latest proposal can and should be improved
upon.
I've been thinking about this quite a bit.
To reiterate the initial problem, although we can disable get/set by not
including it in the accessor, the reason we need read/write only is,
without it, there is no way to not allow subclasses to add set/get to their
parent's accessor.
Going with the idea that not including get/set disables them, what about
this syntax:
class MyObject
{
public $property {
get() { ... }
final set; // Defining an accessor function without body is virtually
the same as not defining the accessor function at all, i.e. this property
accessor can not be set.
}
}
$object = new MyObject();
$propertyValue = $object-property; // Works
$object-property = 10; // Does not work, set not allowed
By disabling accessor functions that don't provide a body, we can easily
imitate read/write arguably better than what the current RFC is capable of,
and use exceptions that already exist (same as the exception thrown if the
accessor function is never defined in the property accessor).
On Tue, Oct 16, 2012 at 4:19 AM, Clint Priest cpri...@zerocue.com wrote:
Hey Stas, a bunch of this has already been covered but I will attempt to
answer each of these as is my current understanding of the hives
decision... :P
1. Accessors IMO should be regular PHP methods that PHP generates with
two additional things:
a. Their name is generated by PHP
b. Their argument set is defined by the accessor pattern (i.e. same
thing as __get/__set).
We should keep the amount of magic and special cases to the minimum, the
engine is complex enough as it is.
This of course includes the full range of options available for the
methods - final, reflection, call scenarios, etc.
This is the way it is, though Nikita strongly disagrees that they should
be callable, visible methods on the object and I agree with Nikita on
this issue, I never did like the idea that __getHours() and __setHours()
were methods of a class just because of an accessor definition, which is
why I worked to have Reflection hide that fact. If I were to go about this
again, they probably will not be methods of the class. Internally there is
little requiring an op_array to be attached to a class in order to be
executed.
2. isset is defined as:
isset() { return $this-Hours != NULL; } This does not seem to
be correct - != NULL does not work like isset now.
Try this:
class A { public $x = 0; }
$a = new A;
var_dump(isset($a-x));
var_dump($a-x != NULL);
This needs to be fixed - generated isset() should be defined to work
exactly like regular isset and actually use the same code path.
Argument to isset() call can be retrieved using accessor but it should
not differ from isset() result in any possible way or situation
(including error situations - e.g. notices, etc.)
The reason that = NULL and != NULL was chosen is because isset() and
unset() are special states that are available only to a variable or
property, since a get/set do not return a real property they cannot be used
with isset/unset. Now that there has been discussion of an accessor being
a real property shadowed by get/set, standard isset/unset could potentially
be used against the underlying property.
3. How references and complex cases are handled? Didn't find anything
about it, e.g. how it handles $foo-bar++, $foo-bar[] = 1,
$foo-bar[123] = 4, etc. ($foo-bar being property with get/set defined
of course)? How $foobar = $foo-bar is handled? The sort()
case mentions by-ref return but does not explicitly mention all other
cases.
These need to be covered explicitly in the RFC.
This is covered in the RFC, perhaps not clearly enough (let me know how I
could expand on it further for clarity). To answer each of your questions,
you can think of what would happen as if it were a function call. For
example, if you did $foo-bar()[123] = 4 you would be modifying a
return-by-val. If bar were instead defined as returning a reference, then
it would indeed work as you expect above. $foobar = $foo-bar would work
as expected as long as the getter is returning a reference as well.
I, perhaps mistakenly, assumed that if return-by-ref and sort() worked
properly, then all other usages of references should equally work the
same, is that not right? If it's not right, why not?
4. We have some LSP controls now in place to ensure non-LSP overrides
generate E_STRICT. Will this be the case for properties too?
Meaning, what happens if you add overriding protected getter to a
property that was previously fully public - thus violating the LSP?
Certainly, this basic object oriented functionality, of course it is
upheld. This is one of the reasons I leveraged standard functions in the
first
RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
This would conflict with the concept of auto-implementation, which if we went
with Nikita’s suggestion, would make an undefined body setter actually set the
property it shadows.
For example
class a {
public $prop {
get() { … }
final set($x);
}
}
Would have final set() translate to final set($x) { $this-prop = $x; }
We *could* have it be that final set; or final set(); -- Without the () or
without the ($x) specifically mean that it is read-only but the clarity goes
WAY down. It is not at all intuitive that any of those things means ‘read-only’
Why is everyone so against the two new keywords? I’m told there has been talk
long ago about having them as keywords anyway. Is it the dash?
Is this more palatable?
public readonly $prop {
get() { }
}
Or
public read_only $prop { … }
Specifically, read-only actually has the advantage that one of the few ways
that it would break BC is if someone had defined a variable named $read and
attempted to subtract a constant or string of ‘only’ from it.
$read = 5;
echo $read-only; // Yields 5
with define(‘only’, 2);
echo $read-only; // Becomes 3
I find it highly unlikely that someone would have been using $read-only or
$write-only since variables cannot have dashes in them, he interpreter sees
that as a subtraction and as shown above it would be nonsensical to have
written PHP like that.
From: Jazzer Dane [mailto:tbprogram...@gmail.com]
Sent: Tuesday, October 16, 2012 6:45 AM
To: Clint Priest
Cc: Stas Malyshev; internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
private final get/set() {} is indeed not a read/write only functionality. I
really would like to keep new keywords out of whatever syntax is implemented,
but I think the latest proposal can and should be improved upon.
I've been thinking about this quite a bit.
To reiterate the initial problem, although we can disable get/set by not
including it in the accessor, the reason we need read/write only is, without
it, there is no way to not allow subclasses to add set/get to their parent's
accessor.
Going with the idea that not including get/set disables them, what about this
syntax:
class MyObject
{
public $property {
get() { ... }
final set; // Defining an accessor function without body is virtually the
same as not defining the accessor function at all, i.e. this property accessor
can not be set.
}
}
$object = new MyObject();
$propertyValue = $object-property; // Works
$object-property = 10; // Does not work, set not allowed
By disabling accessor functions that don't provide a body, we can easily
imitate read/write arguably better than what the current RFC is capable of, and
use exceptions that already exist (same as the exception thrown if the accessor
function is never defined in the property accessor).
On Tue, Oct 16, 2012 at 4:19 AM, Clint Priest
cpri...@zerocue.commailto:cpri...@zerocue.com wrote:
Hey Stas, a bunch of this has already been covered but I will attempt to answer
each of these as is my current understanding of the hives decision... :P
1. Accessors IMO should be regular PHP methods that PHP generates with two
additional things:
a. Their name is generated by PHP
b. Their argument set is defined by the accessor pattern (i.e. same thing as
__get/__set).
We should keep the amount of magic and special cases to the minimum, the
engine is complex enough as it is.
This of course includes the full range of options available for the methods -
final, reflection, call scenarios, etc.
This is the way it is, though Nikita strongly disagrees that they should be
callable, visible methods on the object and I agree with Nikita on this
issue, I never did like the idea that __getHours() and __setHours() were
methods of a class just because of an accessor definition, which is why I
worked to have Reflection hide that fact. If I were to go about this again,
they probably will not be methods of the class. Internally there is little
requiring an op_array to be attached to a class in order to be executed.
2. isset is defined as:
isset() { return $this-Hours != NULL; } This does not seem to be
correct - != NULL does not work like isset now.
Try this:
class A { public $x = 0; }
$a = new A;
var_dump(isset($a-x));
var_dump($a-x != NULL);
This needs to be fixed - generated isset() should be defined to work exactly
like regular isset and actually use the same code path.
Argument to isset() call can be retrieved using accessor but it should not
differ from isset() result in any possible way or situation
(including error situations - e.g. notices, etc.)
The reason that = NULL and != NULL was chosen is because isset() and unset()
are special states that are available only to a variable or property, since a
get/set do not return a real property they cannot be used with
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Hi!
This is the way it is, though Nikita strongly disagrees that they
should be callable, visible methods on the object and I agree with
Nikita on this issue, I never did like the idea that __getHours() and
I think PHP engine has enough complexity and we do not need to add more
unwarranted one. These are methods, they exist - so they should exist
everywhere methods exist. Doing otherwise will result in a tons of
inconsistencies and weird occurrences. If you are in __getHours method
but the engine says __getHours does not exist and can not be called, it
is bad magic. There's no use case for this bad magic and I see no reason
for it except for us trying to restrict users for purist reasons. I do
not think the engine needs complex bad magic when simple solution of
making regular methods would work just as well in all cases where
methods work.
If I were to go about this again, they probably will not be methods
of the class. Internally there is little requiring an op_array to be
attached to a class in order to be executed.
So methods of what would they be? What would be their scope? What would
$this mean? What would method name and backtrace report? How
debugging/profiling tools would work with them? I see no need to
reinvent complex APIs that would require dozens of changes in all tools
dealing with PHP engine when simple methods approach would work as well.
If they won't be regular methods I think it would be too much trouble to
have yet another entity which is like method but not really a method
in the engine.
The reason that = NULL and != NULL was chosen is because isset() and
unset() are special states that are available only to a variable or
property, since a get/set do not return a real property they cannot
be used with isset/unset. Now that there has been discussion of an
I'm not sure I understand here. Property can be either set (exists and
not storing null) or not, there's nothing special about it - all
variables and properties work this way. Automatic isset should work
*exactly* like plain PHP's isset(), and unset should make variable into
the state where isset returns false (and resources are freed). The code
in the RFC for isset() is not working like PHP's isset. That should be
fixed.
This is covered in the RFC, perhaps not clearly enough (let me know
how I could expand on it further for clarity). To answer each of
Yes, it needs to be expanded, since no examples right now show how it is
supposed to be working.
I, perhaps mistakenly, assumed that if return-by-ref and sort()
worked properly, then all other usages of references should equally
work the same, is that not right? If it's not right, why not?
I'm not sure, I didn't check all of them yet. All these need to be tested.
Certainly, this basic object oriented functionality, of course it is
upheld. This is one of the reasons I leveraged standard functions in
the first place, because these issues were automatically handled by
the existing core.
I'm not sure overriding public $foo with public $foo { protected
get() {} } is covered by existing code. Existing code has no way to
cover such things.
This is currently up in the air on the RFC side and is being referred
to as which shadows which. The code currently has it that
properties shadow accessors, Nikita suggested that should be inverted
and I agree, so unless someone else thinks otherwise, accessors will
probably shadow properties.
Which raises the question above again - how LSP is preserved? What would
happen in such case?
See response to #2 above, without a getter/setter returning a real
property, isset/unset accessors were necessary because
isset()/unset() cannot perform on a dynamic value. Consider this:
You seem to misunderstand what I wrote there. I am proposing that
isset() would a) always have default implementation if get() is defined
and b) work exactly like PHP isset() in that the way that if get()
returns null (or does not exist if write-only properties are introduced)
then it returns false, otherwise it returns true.
The fact that current isset() operator does not work on T variables is
irrelevant, since I'm talking about level below that - how that operator
is implemented. The implementation should be augmented so that for
properties with accessors it would work exactly the same as for
properties without ones.
direction of accessors shadowing properties, I could see the default
implementation of isset/unset actually be more like unset() { return
unset($this-bar); } and isset() { return isset($this-bar); }
If this is pseudocode, meaning call get accessor if exists and return
true if return value is not null, otherwise return false then it's fine
for isset. For unset, you'd still want to use set accessor or fail if
set accessor is not defined.
Oh crap, you're referring to the idea that during compilation a class
definition may exist below the point of current compilation, right?
I had not considered this case and you're right,
[PHP-DEV] static analysis and early warning systems
Since there's a heavy debate on the list about strong typing right now, I just want to briefly share my point of view. PHP is not and won't be a strongly typed language. What it can be (and is on the way to be, with Clint's work) is a language that supports type-checking. Not the same as strongly typed. There's a time for unchecked properties and arguments, and there's a time for type-checking - you can argue against type hints and type-checks until you're blue in the face, but they exists for a reason: static analysis, which means better tooling and faster (and more well-documented) codebases in larger projects. And early warning systems - making sure that code fails at the point of failure, rather than bad arguments (or worse, property-values) slipping through the cracks, costing you many hours of painstaking debugging. Code that doesn't fail in the place where it's actually broken, is harder to debug than anything else. Type hints are optional, so PHP can still be a beginner-friendly language. To classify PHP as a beginner-language seems unfair to experienced professionals, who brought projects like Symfony and Zend Framework to life. The recent injection of new talent and renewed interest in the past 1-2 years has happened because those people stuck with PHP rather than moving on to other languages - let's face it, nobody wants to be stuck in beginner mode, and if PHP was really strictly a beginner language, it would be largely a waste of time. To me, it is much more than that - it is a language where you can dip your toes and test the water safely, but you can go really, really deep if you want to. The modern tools, libraries and frameworks available today are a testament to that fact - if the people behind these projects had simply moved on, where would PHP be today? Growing the language is key to maintaining the interest of smart people who are willing to invest their time in building great software with PHP and sharing it with the community. A language is only worth as much as the community is willing to invest! Don't be afraid of scaring off beginners with advanced features - because PHP is such a loose language, those people can still get on board and start learning, without having to go the whole way on day 1. Beginners are unlikely to start picking apart Symfony or Zend Framework anyhow - but they are likely to start trying them out eventually. Most people do not get into PHP development intending to learn only the basics - they usually have a more long-term plan. Those who get in, intending to learn only a little, are usually designers and front-end people, who will never touch more than a view/template script anyhow, and thus will never even encounter classes, closures, or any of the other advanced stuff. Just my two cents.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Yes, I'm aware - I thought of the clash with Nikita's proposal while
writing mine, but decided not to bring it up. If we were to go with my
proposed syntax, then one of two things would have to happen.
1) Don't auto implement get/set. *On a similar note, what's the difference
between using a property accessor that auto implements get/set* and a
normal property?
2) As you said, differentiate between get; and get();. The issue this
creates is obvious, and in my opinion this isn't a viable solution.
For the record, *read_only* and even moreso *readonly* are, in my opinion,
nicer than *read-only*.
On Tue, Oct 16, 2012 at 5:10 AM, Clint Priest cpri...@zerocue.com wrote:
This would conflict with the concept of auto-implementation, which if we
went with Nikita’s suggestion, would make an undefined body setter actually
set the property it shadows.
** **
For example
** **
class a {
public $prop {
get() { … }
final set($x);
}
}
** **
Would have final set() translate to final set($x) { $this-prop = $x; }***
*
** **
We **could** have it be that final set; or final set(); ß Without the ()
or without the ($x) specifically mean that it is read-only but the clarity
goes WAY down. It is not at all intuitive that any of those things means
‘read-only’
** **
Why is everyone so against the two new keywords? I’m told there has been
talk long ago about having them as keywords anyway. Is it the dash?
** **
Is this more palatable?
** **
public readonly $prop {
get() { }
}
** **
Or
** **
public read_only $prop { … }
** **
Specifically, read-only actually has the advantage that one of the few
ways that it would break BC is if someone had defined a variable named
$read and attempted to subtract a constant or string of ‘only’ from it.***
*
** **
$read = 5;
echo $read-only; // Yields 5
** **
with define(‘only’, 2);
** **
echo $read-only; // Becomes 3
** **
I find it highly unlikely that someone would have been using $read-only or
$write-only since variables cannot have dashes in them, he interpreter sees
that as a subtraction and as shown above it would be nonsensical to have
written PHP like that.
** **
** **
*From:* Jazzer Dane [mailto:tbprogram...@gmail.com]
*Sent:* Tuesday, October 16, 2012 6:45 AM
*To:* Clint Priest
*Cc:* Stas Malyshev; internals@lists.php.net
*Subject:* Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
** **
private final get/set() {} is indeed not a read/write only functionality.
I really would like to keep new keywords out of whatever syntax is
implemented, but I think the latest proposal can and should be improved
upon.
I've been thinking about this quite a bit.
To reiterate the initial problem, although we can disable get/set by not
including it in the accessor, the reason we need read/write only is,
without it, there is no way to not allow subclasses to add set/get to their
parent's accessor.
Going with the idea that not including get/set disables them, what about
this syntax:
class MyObject
{
public $property {
get() { ... }
final set; // Defining an accessor function without body is virtually
the same as not defining the accessor function at all, i.e. this property
accessor can not be set.
}
}
$object = new MyObject();
$propertyValue = $object-property; // Works
$object-property = 10; // Does not work, set not allowed
By disabling accessor functions that don't provide a body, we can easily
imitate read/write arguably better than what the current RFC is capable of,
and use exceptions that already exist (same as the exception thrown if the
accessor function is never defined in the property accessor).
On Tue, Oct 16, 2012 at 4:19 AM, Clint Priest cpri...@zerocue.com wrote:
Hey Stas, a bunch of this has already been covered but I will attempt to
answer each of these as is my current understanding of the hives
decision... :P
1. Accessors IMO should be regular PHP methods that PHP generates with
two additional things:
a. Their name is generated by PHP
b. Their argument set is defined by the accessor pattern (i.e. same
thing as __get/__set).
We should keep the amount of magic and special cases to the minimum, the
engine is complex enough as it is.
This of course includes the full range of options available for the
methods - final, reflection, call scenarios, etc.
This is the way it is, though Nikita strongly disagrees that they should
be callable, visible methods on the object and I agree with Nikita on
this issue, I never did like the idea that __getHours() and __setHours()
were methods of a class just because of an accessor definition, which is
why I worked to have Reflection hide
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
Hi!
If you have a public property $a which internally can only deal with
it being set to 2 or 3 and someone external to the class sets it to
4, your class either has to check that it's 2 or 3 and deal with the
fact that it is now 4 or have indeterminate results when it is set to
4.
Most of the properties, however, aren't of that nature.
The use case is that you are declaring that interface a must allow a
property $xyz to be readable and *not* writable.
Why would you require for the implementor to *not* be able to do
something? Interfaces were never used to make class *not* be able to do
something. Are you sure it's good thing to introduce this? I think it's
not. I think interfaces should only define X should work but not Y
should not work.
Class b does not satisfy the requirement because you are missing the
fact that public $xyz { get; } forbids setting of $xyz, only reading
it.
See above, I think it's not the right use of interfaces. Also, error
message produced has nothing in common with this logic.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Gabeezus, I have to get to work Stas! ;)
This is the way it is, though Nikita strongly disagrees that they
should be callable, visible methods on the object and I agree with
Nikita on this issue, I never did like the idea that __getHours() and
I think PHP engine has enough complexity and we do not need to add more
unwarranted one. These are methods, they exist - so
they should exist everywhere methods exist. Doing otherwise will result in a
tons of inconsistencies and weird occurrences. If you
are in __getHours method but the engine says __getHours does not exist and
can not be called, it is bad magic. There's no use case
for this bad magic and I see no reason for it except for us trying to
restrict users for purist reasons. I do not think the engine needs
complex bad magic when simple solution of making regular methods would work
just as well in all cases where methods work.
I very much disagree, engine details should not be visible to users. It is
irrelevant to them and only serves to confuse.
If I were to go about this again, they probably will not be methods of
the class. Internally there is little requiring an op_array to be
attached to a class in order to be executed.
So methods of what would they be? What would be their scope? What would $this
mean? What would method name and backtrace
report? How debugging/profiling tools would work with them? I see no need to
reinvent complex APIs that would require dozens of
changes in all tools dealing with PHP engine when simple methods approach
would work as well.
If they won't be regular methods I think it would be too much trouble to have
yet another entity which is like method but not really
a method
in the engine.
To be clear, they would be regular methods, they would just not exist in the
HashTable *functions of the class. In every other way they are methods of the
class.
The reason that = NULL and != NULL was chosen is because isset() and
unset() are special states that are available only to a variable or
property, since a get/set do not return a real property they cannot be
used with isset/unset. Now that there has been discussion of an
I'm not sure I understand here. Property can be either set (exists and not
storing null) or not, there's nothing special about it - all
variables and properties work this way. Automatic isset should work
*exactly* like plain PHP's isset(), and unset should make variable into the
state where isset returns false (and resources are freed).
The code in the RFC for isset() is not working like PHP's isset. That should
be fixed.
PHP 5.4.7 (cli) (built: Sep 13 2012 09:32:31)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with DBG v4.6.1, (C) 2000,2012, by Dmitri Dmitrienko
[root@deploy /opt/esp/release]# php -ddisplay_errors=1
-ddisplay_startup_errors=1 -a
Interactive shell
php function a() { return 1; }
php unset(a());
Fatal error: Can't use function return value in write context in php shell code
on line 1
php isset(a());
Fatal error: Can't use function return value in write context in php shell code
on line 1
See the problem?
This is covered in the RFC, perhaps not clearly enough (let me know
how I could expand on it further for clarity). To answer each of
Yes, it needs to be expanded, since no examples right now show how it is
supposed to be working.
How would you like me to expand on it?
I, perhaps mistakenly, assumed that if return-by-ref and sort() worked
properly, then all other usages of references should equally work
the same, is that not right? If it's not right, why not?
I'm not sure, I didn't check all of them yet. All these need to be tested.
I don't know the other contexts that need to be tested. There are already
over 80 tests written for this (.phpt) that all pass, please let me know what
other tests need to be written and I'd be happy to write them.
Certainly, this basic object oriented functionality, of course it is
upheld. This is one of the reasons I leveraged standard functions in
the first place, because these issues were automatically handled by
the existing core.
I'm not sure overriding public $foo with public $foo { protected
get() {} } is covered by existing code. Existing code has no way to cover
such things.
This isn't over-riding, this is simultaneous existence and at present,
properties shadow accessors, though Nikita wants to invert that.
This is currently up in the air on the RFC side and is being referred
to as which shadows which. The code currently has it that
properties shadow accessors, Nikita suggested that should be inverted
and I agree, so unless someone else thinks otherwise, accessors will
probably shadow properties.
Which raises the question above again - how LSP is preserved? What would
happen in such case?
It's preserved in the same exact way (and by the same exact code)
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
2012/10/16 Clint Priest cpri...@zerocue.com In this regard, I have yet to see any proposal that is as clear or concise as public read-only $abc. What is the big problem with adding read-only and write-only keywords? Once they are in the language they could be expanded to plain properties. public:const $abc; (in cyberspace, no one can hear me scream) No need for another keyword when there is one doing the job. IMHO, write-only doesn't make any sense. If you define something like an attribute to be only writeable, in fact you are defining a method. But you use it like that: $obj-attr = 3; instead of using it like that: $obj-meth(3); What's the point? More, read-only and write-only are very poor-meaning keywords. We need full PPP visibility (and yes, I know the RFC allows asymetric visibility, but it implies to create accessors and therefore some code).
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Hi!
I very much disagree, engine details should not be visible to users.
It is irrelevant to them and only serves to confuse.
It's not engine detail. We're not talking about exposing C pointers or
zend_op values. We're talking about implementing methods that have
special meaning. They are still methods and it only makes sense that
they behave like other methods do. Not doing that - as you are perfectly
aware - adds a lot of complications and makes the engine inconsistent -
now you have methods that engine treats one way and methods that the
engine teats in completely different way, and in every place you deal
with methods you need to have special cases.
To be clear, they would be regular methods, they would just not exist
in the HashTable *functions of the class. In every other way they
are methods of the class.
Don't sound like a good idea. Imagine a debugger/profiler that works
with PHP. Now instead of having one hashtable to deal with it has two
since current function may or may not be in different hashtable. Imagine
extension or other tool or just engine part that deals with functions -
now everywhere you have to make provisions for the fact that functions
now live in two places instead of one. I don't think design-wise it is a
good idea.
See the problem?
I am *NOT* saiyng you should apply isset operator as it to it. I am
saying that code that is implementing the default isset should work
*exactly* as the isset operator would work on regular property. Of
course it can not be the same operator - it should be changed/extended -
but it should keep working the same way. E.g. not return not set when
property is set to 0.
I don't know the other contexts that need to be tested. There are
already over 80 tests written for this (.phpt) that all pass, please
let me know what other tests need to be written and I'd be happy to
write them.
I think the following cases should be covered:
- $foo-bar++/-- (postfix and prefix) - with actual value being number,
string, empty, not existing.
- $foo-bar[$index] = $x (with value being array, object with
ArrayAccess, string, integer - the last should produce proper error and
no leaks)
- $foo-bar[] = $x with the same as above
- $foo-bar-baz = $x with $bar being object or empty or non-object
value (proper error and no leaks)
- $foo-bar{$x} = foo (string offsets), also checks that non-string
vars work fine
- $foo-bar = $bar-baz, etc. with modifying both sides and checking
everything works (including modifying via accessors)
- property loop detection needs to be tested (i.e. $this-foo in getter
for $foo or $this-bar in $foo and $this-foo in $bar).
Maybe more if I'd think of anything.
I realize some of these may feel obvious but we're modifying very core
part - it's better to be safe than sorry.
It's preserved in the same exact way (and by the same exact code)
that any other function over-rides are handled. The accessor syntax,
LITERALLY, translates into functions and thus go through the ordinary
LSP preservation lines of code. It's the reason I chose to go that
route in the first place (to leverage the existing LSP checks)
The accessor syntax translates to functions but public $foo does not.
That's the issue. There's no existing check for overriding public $foo
with private accessor. There are checks that would work between two
accessors - but not between accessor and plain property.
With isset/unset accessors, they *can be* implemented appropriately,
with automatic isset/unset implementations, they cannot, for reasons
stated above:
php isset(a());
Fatal error: Can't use function return value in write context in php
shell code on line 1
You do not need to apply isset() as is to function call. You can have
isset method that is smart enough to do the right thing. You're writing
the engine patch, not the PHP code transformation tool, so you can do
more things here. If you need specific, I can look into the code,
probably later as I'll have to move on pretty soon :)
You've got that right... isset() cannot exist (and is not allowed) if
isset() should always be allowed - it just should return false if
something goes wrong. This is how it is used now - as safe operator
which will always work and return false if something is wrong. Making
isset() not allowed means that you need another operator saying am I
allowed to call isset() here or will my code fail?. No need for that as
isset() is exactly such kind of operator for read access. No such thing
for write access btw which is quite bad since nothing now guarantees
simple $foo-bar = 1; wouldn't blow up and there's no way to check for
that. Which makes impossible to write robust code. This alone makes me
very uneasy about the whole read-only idea.
Yes, these cases were not considered. The static accessors portion
of this project took up an inordinate amount of time as compared to
the rest.
Maybe we should limit accessors to dynamic ones for now or split it out
to additional spec/1.1
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
On Oct 16, 2012 11:27 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! What remains on your TODO list for this functionality? When are you planning to run an RFC vote on this? I think this would be a valuable addition to PHP 5.5. I think we shouldn't rush with votes on this until all fine details aren't hashed out. This is a *huge* feature - one of the biggest ones recently, Exactly because it is such a big deal it needs to be refined and polished. Amen.
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Stas Malyshev wrote: What remains on your TODO list for this functionality? When are you planning to run an RFC vote on this? I think this would be a valuable addition to PHP 5.5. I think we shouldn't rush with votes on this until all fine details aren't hashed out. This is a*huge* feature - one of the biggest ones recently, and has a lot of implications for various scenarios. Property access is what virtually every script in existence does, and doing changes there have implications that touch every corner of the engine. I think Clint is doing a great job with this RFC, but we need to carefully work through all the corners and side cases and relationships with all other features before we can declare it's ready for the prime time. Exactly because it is such a big deal it needs to be refined and polished. But a vote NOT to include it should still be one of the options! The more edge cases I see on this discussion, the more I am convinced that this is simply not right for PHP ... it's not needed and only adds unnecessary bloat. The more the functionality of PHP gets buried in 'magic code' that can't even be debugged properly or viewed the less useful PHP becomes. I'm sorry if people are spending a lot of time trying to make something work, but that is their choice, and should not be a reason to include something. I still don't see how this improves anything when all we need to be doing is managing the existing variables, arrays and objects stored in the object. __get and __set aren't needed either but that is another matter. Does anybody actually use them, or are they waiting for the 'better alternative'? Is there any real reason not simply to be using $obj-var ? It is the fastest way of doing it anyway ... -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
On 10/16/2012 02:51 AM, Amaury Bouchard wrote: 2012/10/16 Stas Malyshev smalys...@sugarcrm.com public DateTime $date; This is *real* progress, even if under the hood all it does is wrap I think it's a movement in wrong direction. Again, it is an attempt to make PHP a strongly typed language, which would not work well in a dynamic language like PHP, for reasons that were amply explained in 9000 discussions we had on this topic before. Not necessarily strongly typed. (sorry to land on this topic afterwards) As I see PHP, it's a language that can be used as an informal scripting language, but also as a rock-solid modern tool. Type hinting in parameters is a really good thing, and it doesn't transformed PHP in a strongly typed language. Doing the same for object properties (always optional) could be very useful. The rule in PHP for any sort of type hinting is that it is only done for non-coercable types. In cases where there is simply no way to recover from passing the wrong type, it is good to catch it as early as possible. Extending this to also cover scalar coercable types would be disastrous for the entire ecosystem and would completely change PHP. And the fact that it is optional means absolutely nothing because once some piece of your system has optionally decided to use it you don't have the option not to abide by it, and it certainly isn't a hint, it is a strong type. You will end up casting every call to everything all the time just to be safe. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Lester's Comment (was Property Accessors v1.1)
Lester, But a vote NOT to include it should still be one of the options! No it should not. Comments like this are not helpful, and are quite destructive. Please stop running that circle. As far as the particular implementation goes, I'd vote against it right now. Not because it's bad, but because it's immature. The best way to get the idea mature is constructive conversation and implementations. That's what's going on here. And that's what should be happening. Your comment does nobody any good. To be honest, neither do the rest of your comments. Please realize that we should be constructively encouraging conversation. Let the conversation generate a concrete proposal, then discuss that for inclusion. But your post and position is not constructive. Please stop. I'm sorry if people are spending a lot of time trying to make something work, but that is their choice, and should not be a reason to include something. I still don't see how this improves anything when all we need to be doing is managing the existing variables, arrays and objects stored in the object. __get and __set aren't needed either but that is another matter. Does anybody actually use them, or are they waiting for the 'better alternative'? Is there any real reason not simply to be using $obj-var ? It is the fastest way of doing it anyway ... If you don't understand the problems with $obj-var, then perhaps you shouldn't contribute to a conversation that's this early. The RFC hasn't been proposed. It's still evolving. Save those questions until the proposers feel it's ready. And to be fair, if you don't understand the problems with public variables, then you really don't have much room to be commenting (or voting) on OOP design decisions. I'm sorry if this seems to be attacking you, but it really is. Your presence lately has been very damaging and demoralizing. Not once have you proposed or commented in a constructive way. Everything with you is a problem. So please, either be constructive, or simply don't post. This list has a bad enough history of destructive criticism... Anthony
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
2012/10/16 Rasmus Lerdorf ras...@lerdorf.com The rule in PHP for any sort of type hinting is that it is only done for non-coercable types. In cases where there is simply no way to recover from passing the wrong type, it is good to catch it as early as possible. Extending this to also cover scalar coercable types would be disastrous for the entire ecosystem and would completely change PHP. My point was not about scalar types. It was about porting the logic of parameters type hinting to object properties. Nothing more, nothing less. And the fact that it is optional means absolutely nothing because once some piece of your system has optionally decided to use it you don't have the option not to abide by it, and it certainly isn't a hint, it is a strong type. You will end up casting every call to everything all the time just to be safe. I use parameters type hinting everyday. I can say it's very useful. And I never needed to cast anything. If the object model is used wisely, and if type hinting is used as an option (i.e. don't use it when you know you'll need mixed data), it's a very good thing. I don't see why it couldn't be as good for properties as it is for parameters. But Stas said it was already discussed a lot here, so I give up. :-)
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
On Tue, Oct 16, 2012 at 10:31 AM, Amaury Bouchard ama...@amaury.net wrote:
2012/10/16 Rasmus Lerdorf ras...@lerdorf.com
The rule in PHP for any sort of type hinting is that it is only done for
non-coercable types. In cases where there is simply no way to recover
from passing the wrong type, it is good to catch it as early as
possible. Extending this to also cover scalar coercable types would be
disastrous for the entire ecosystem and would completely change PHP.
My point was not about scalar types. It was about porting the logic of
parameters type hinting to object properties. Nothing more, nothing less.
And the fact that it is optional means absolutely nothing because once
some piece of your system has optionally decided to use it you don't
have the option not to abide by it, and it certainly isn't a hint, it is
a strong type. You will end up casting every call to everything all the
time just to be safe.
I use parameters type hinting everyday. I can say it's very useful. And I
never needed to cast anything.
If the object model is used wisely, and if type hinting is used as an option
(i.e. don't use it when you know you'll need mixed data), it's a very good
thing.
I don't see why it couldn't be as good for properties as it is for
parameters. But Stas said it was already discussed a lot here, so I give up.
:-)
It is foolish to think that these two bits of code are behaviorally different:
class Entity {
DateTime $last_modified;
}
//vs
class Entity {
public $last_modified {
get();
set(DateTime $last_modified);
}
}
The latter is a more verbose way of saying the former (assuming the
get returns the same type as the set accepts). The latter is
definitely capable of doing more than the former, such as private set
and public get. The former piece of code is simply a public get and
public set such that the type is always DateTime. It would be nice to
have the former syntax because of how succinct it is, but I am not an
experienced core programmer. I am unsure how feasible it is to
implement.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
My choice of words were misleading/incorrect. If you are programming to an
interface then the interface dictates what *will* work, if you attempt to use
an interface to do something that the interface has not declared is supported
then it may work or it may fail.
On Oct 16, 2012, at 7:43 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
If you have a public property $a which internally can only deal with
it being set to 2 or 3 and someone external to the class sets it to
4, your class either has to check that it's 2 or 3 and deal with the
fact that it is now 4 or have indeterminate results when it is set to
4.
Most of the properties, however, aren't of that nature.
The use case is that you are declaring that interface a must allow a
property $xyz to be readable and *not* writable.
Why would you require for the implementor to *not* be able to do
something? Interfaces were never used to make class *not* be able to do
something. Are you sure it's good thing to introduce this? I think it's
not. I think interfaces should only define X should work but not Y
should not work.
Class b does not satisfy the requirement because you are missing the
fact that public $xyz { get; } forbids setting of $xyz, only reading
it.
See above, I think it's not the right use of interfaces. Also, error
message produced has nothing in common with this logic.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Stas, go back a few revisions of the RFC and you'll see there used to be automatically implemented accessors which were voted out. The current RFC does not reflect the current fork of the code, it did before I modified it with the consensus from around 10/12 before Nikita brought up some more thoughts on the subject. I believe the general idea of the changes is documented at the bottom of the document in the change list, but you're free to go back to previous versions of the RFC. -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Tuesday, October 16, 2012 5:48 AM To: Jazzer Dane Cc: Clint Priest; internals@lists.php.net Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 Hi! Stas, the proposed solution thus far is to make the getter or setter final and private and not have a body. This would naturally throw an exception if it was accessed from anywhere but the class it was defined. The class it was defined in has to remember that it is virtually a read/write only accessor. What you mean by not have a body - is there special syntax for body-less methods introduced? Then it should be in the RFC. How it is implemented - what exactly is stored in the function table then? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Jesus, this is such a CF. Can I not write understandable English?
read-only and write-only ENFORCE UPON SUBCLASSES that no setter or getter
(respectively) can be defined. That's all they do. There is no currently
proposed solution that meets this need.
This NEED was pulled from the original RFC that Dennis wrote some 4 years
ago. Perhaps we don't even NEED a solution to this problem.
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, October 16, 2012 5:59 AM
To: Jazzer Dane
Cc: Clint Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Hi!
I apologize for my confusing terminology - let me elaborate. There are
no special syntaxes. The below code should help clear things up a bit:
class MyClass {
private $otherProperty;
public $property {
get() {}; // Does not have a body, as there is no code between
the curly braces.
It does have a body. This body is just default empty method body returning
null - which does not throw any exceptions and is
completely indistinguishable from the outside from property being equal to
null.
I'm not sure it's what the intent of *-only variable is, though I guess it is
a way to hack around it. I wonder however if it can be done
better.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Alternatives to mailing list?
Is it just me or has this Property Accessors chain of emails been impossible to make heads or tails of? People replying within replies within replies, quoting partial emails, cross-posting and all sorts of chaos. Would anyone be willing to entertain an alternative communication method with specific respect to building/refining an RFC or fleshing out an idea? Heck, I think even live chat meeting over IRC would beat what's been going on... Not saying abandon the mailing list, it's crucial, but when there gets to be 150+ emails on one subject and numerous sub-subjects it just seems inefficient at best and chaos at its worst... I don't know of anything offhand that would work well but I'd be willing to try and find something we could try out. -Clint
Re: [PHP-DEV] Alternatives to mailing list?
I may sound old fashioned, but what about a forum? On Wed, Oct 17, 2012 at 3:05 AM, Clint Priest cpri...@zerocue.com wrote: Is it just me or has this Property Accessors chain of emails been impossible to make heads or tails of? People replying within replies within replies, quoting partial emails, cross-posting and all sorts of chaos. Would anyone be willing to entertain an alternative communication method with specific respect to building/refining an RFC or fleshing out an idea? Heck, I think even live chat meeting over IRC would beat what's been going on... Not saying abandon the mailing list, it's crucial, but when there gets to be 150+ emails on one subject and numerous sub-subjects it just seems inefficient at best and chaos at its worst... I don't know of anything offhand that would work well but I'd be willing to try and find something we could try out. -Clint
Re: [PHP-DEV] Alternatives to mailing list?
I agree. VBulletin rules. It also permits voluntary participation rather than getting every email for ever conversation. Should you prefer to get everything via email, I believe it is possible to sync VBulletin with a mailing list. On 10/16/2012 5:18 PM, Yahav Gindi Bar wrote: I may sound old fashioned, but what about a forum? On Wed, Oct 17, 2012 at 3:05 AM, Clint Priest cpri...@zerocue.com wrote: Is it just me or has this Property Accessors chain of emails been impossible to make heads or tails of? People replying within replies within replies, quoting partial emails, cross-posting and all sorts of chaos. Would anyone be willing to entertain an alternative communication method with specific respect to building/refining an RFC or fleshing out an idea? Heck, I think even live chat meeting over IRC would beat what's been going on... Not saying abandon the mailing list, it's crucial, but when there gets to be 150+ emails on one subject and numerous sub-subjects it just seems inefficient at best and chaos at its worst... I don't know of anything offhand that would work well but I'd be willing to try and find something we could try out. -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternatives to mailing list?
Personally, I like IP.Board. Put that aside, I thought about PHPBB or another open-source software :) On Wed, Oct 17, 2012 at 3:22 AM, J. Adams zardozro...@gmail.com wrote: I agree. VBulletin rules. It also permits voluntary participation rather than getting every email for ever conversation. Should you prefer to get everything via email, I believe it is possible to sync VBulletin with a mailing list. On 10/16/2012 5:18 PM, Yahav Gindi Bar wrote: I may sound old fashioned, but what about a forum? On Wed, Oct 17, 2012 at 3:05 AM, Clint Priest cpri...@zerocue.com wrote: Is it just me or has this Property Accessors chain of emails been impossible to make heads or tails of? People replying within replies within replies, quoting partial emails, cross-posting and all sorts of chaos. Would anyone be willing to entertain an alternative communication method with specific respect to building/refining an RFC or fleshing out an idea? Heck, I think even live chat meeting over IRC would beat what's been going on... Not saying abandon the mailing list, it's crucial, but when there gets to be 150+ emails on one subject and numerous sub-subjects it just seems inefficient at best and chaos at its worst... I don't know of anything offhand that would work well but I'd be willing to try and find something we could try out. -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternatives to mailing list?
Yahav Gindi Bar in php.internals (Wed, 17 Oct 2012 03:18:12 +0300): I may sound old fashioned, but what about a forum? A forum is new fashioned. I am reading and writing this on news.php.net. Webinterface: http://news.php.net/php.internals But you'd better use a proper newsreader. Some browsers have one built-in: nntp://news.php.net/php.internals Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Alternatives to mailing list?
I was thinking more along the lines of a collaborative wiki with inline-threaded comments... -Original Message- From: Jan Ehrhardt [mailto:php...@ehrhardt.nl] Sent: Tuesday, October 16, 2012 8:00 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Alternatives to mailing list? Yahav Gindi Bar in php.internals (Wed, 17 Oct 2012 03:18:12 +0300): I may sound old fashioned, but what about a forum? A forum is new fashioned. I am reading and writing this on news.php.net. Webinterface: http://news.php.net/php.internals But you'd better use a proper newsreader. Some browsers have one built-in: nntp://news.php.net/php.internals Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
On 16/10/12 22:34, Clint Priest wrote:
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, October 16, 2012 6:06 AM
To: Clint Priest
Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
Hi!
that supports properties in interfaces. Again, not exhaustive either
but there is one language that does support accessors in interfaces
and that's C#.
So what C# does when mixing regular properties and accessorized properties?
I'd have to do some research to know for sure, but it's highly likely that they
cannot be mixed.
Think about it, if you allowed an outside caller of your class to
modify your internal state, any time you needed to use that internal
state you would have to validate it before you could rely upon its
value to be set correctly. No such issue exists with accessors in an
I do not see why this assumption is made that I need to do some special
validation each time state is changed. In fact, in 99% of
existing code it is not happening, and I assume this ratio will be kept even
when accessors are available. Most code will be very
straightforward, not doing anything complex with the state.
If you have a public property $a which internally can only deal with it being
set to 2 or 3 and someone external to the class sets it to 4, your class either
has to check that it's 2 or 3 and deal with the fact that it is now 4 or have
indeterminate results when it is set to 4.
Now, I think the bigger question is: what exactly you want to say/require when
you write:
interface a { public $xyz { get; } }
and what is the use case for this requirement?
The use case is that you are declaring that interface a must allow a property
$xyz to be readable and *not* writable.
Just to be a bit more concrete here, as the code is presently written
and because I have strongly separated the concept of a property vs an
accessor, this code:
interface a { public $xyz { get; } }
class b implements a { public $xyz; }
Produces the following error: Fatal error: Class b contains 3 abstract
accessors and must be declared abstract or implement the remaining
accessors (get a::$xyz, isset a::$xyz, ...) in %s on line %d
I think this is wrong. 3 abstract accessors is especially wrong since it
doesn't match the direct interface definition and is very
confusing (see my earlier point about isset/unset always having fallback
defaults) but even with get as abstract I do not see a valid
use case that would require such behavior. What you want is for any $foo that
is instanceof a to be able to respond to read request
to $foo-xyz, right? Class b satisfies this requirement, why you reject it then?
Also, if you reject it - how I should fix it to make it work? Would I have to
implement a bolierplate getter/setter just to make
interface work? Doesn't look like a good proposition to me.
Class b does not satisfy the requirement because you are missing the fact that
public $xyz { get; } forbids setting of $xyz, only reading it.
That doesn't make sense. An implementation has to have the same or less
restricted visibility, so the above should work. The inverse however
should not:
interface a { public $xyz; }
class b implements a { public $xyz { get; }}
Daivd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
