RE: [PHP-DEV] [RFC] Propety Accessors v1.1

[Clint Priest]

Wow, I'm surprised by all the talk about this RFC this time around.  I posted 
this numerous times in the past trying to elicit feedback and got little to 
none, so I took the time to write it as I thought it should be written.  Some 
of these things will take considerable effort to fix/correct/change.



I'll try to address everyone's comments/questions in one post:





Nikita:

> What concerns me with the current implementation is that it leaks many 
> implementation details, in particular the fact that the accessors are 
> implemented as *real* __getXYZ methods and automatic implementations also use 
> *real* $__XYZ properties.

>

> A few examples:

>

> ## 1 - __getProperty() method directly callable

>

> class Test {

> public $property {

> get { return 123; }

> }

> }

>

> $test = new Test;

> var_dump($test->property); // int(123)

> var_dump($test->__getProperty()); // int(123)

>



I don't particularly see this as a problem (the ability to use it as a getter 
or call it as a function), but see my comments at the end.  I also don't 
particularly see the point of auto implemented getters/setters ( public $h { 
get; set; } )



> ## 2 - __getProperty() method exposed via exception

>

> class Test {

> public $throwingProperty {

> get { throw new Exception; }

> }

> }

>

> (new Test)->throwingProperty;

>

> exception 'Exception' in /home/nikic/dev/php-src/t29.php:9 Stack trace:

> #0 /home/nikic/dev/php-src/t29.php(31): Test->__getthrowingProperty()

> #1 {main}

>



I have gone to great lengths to shield the implementation details from users, 
this one slipped past me.  Nearly all errors that are shown reference a 
property rather than a function name and this could also be cleaned up.



> ## 3 - Can directly access $__automaticProperty and even unset it (causing 
> notices in the internal code)

>

> class Test {

> public $automaticProperty {

> get; set;

> }

>

> public function getAutomaticProperty() {

> return $this->__automaticProperty;

> }

>

> public function unsetAutomaticProperty() {

> unset($this->__automaticProperty);

> }

> }

>

> $test->automaticProperty = 'foo';

> var_dump($test->getAutomaticProperty());

> $test->unsetAutomaticProperty();

> var_dump($test->automaticProperty);

>

> string(3) "foo"

>

> Notice: Undefined property: Test::$__automaticProperty in 
> /home/nikic/dev/php-src/t29.php on line 13 NULL



I'm not even sure that automatic backing fields are even desired, I never felt 
the need to have them in C# and the only reason they were included is because 
they were a part of Dennis's original proposal.  Eliminating them would 
eliminate this as an issue.



>

> =

>

> I feel like this approach to the implementation will be a big can of worms. 
> Sure, it works, but it is rather fragile and the enduser ends up dealing with 
> internal stuff which he ought not care about. I think it would be better to 
> cleanly separate out the accessor implementation. It might require more code 
> now, but will be better in the long run.



All three of these issues, could be addressed I believe by not having the 
functions and/or properties a part of the ordinary HashTables, or to have flags 
set on them.  I believe there is already a SHADOW flag type defined which may 
be able to be used for this type of functionality.





Leigh:

> Further to this, take the following example.

>

> public $_state {

> set { ... }

> }

>

> This automatically generates a "hidden" function __set_state(), which is a 
> magic method already (and should be declared static, and take an array as 
> it's only parameter)

>

> Another fine example of how automatically generating *real* implementations 
> can potentially break things.



This would clearly cause problems, again this could possibly be addressed by 
not having the accessor functions be a part of the standard Functions 
HashTable, the functions would not even need to have names at that point if 
they are not intended to be accessible directly.



> public $property {

> set { $this->property = ($this->property*2)+$value } get; }

>

> How do I reference the property being set from within the function? The way I 
> have done it in the example will cause recursion? How can I assign to "self"?

>

> How do I set the default value of $property when the object is created?

> Surely I don't have to reverse the set accessors logic and set the inverse in 
> __construct?



Generally speaking, I don't know why you would use an automatic backing getter 
with a separate setter, but if you wanted to do that, at present you would 
access the automatic backing field by $this->__property.



The above will not cause recursion, it is protected from recursion by the same 
mechanism that __get() and __set() are protected.  In fact, the above code 
would set an actual property named $prope

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[David Muir]

On 09/10/12 19:20, Jazzer Dane wrote:

- "If we ever get return type hinting/checks then we needn't consider how
the syntax has to look" From what I know, this isn't planned for PHP 5.5
and any proposals for it have been largely ignored. Return type hinting
won't help when setting either, although it would help with getting. All
that being said, type hinting aside, the syntax I proposed is, in my
opinion, the most consistent out of any other proposal thus far (arguably
aside from yours, I'll go over that momentarily).


Excellent point. Return type-hints only affect the getter, and even then 
it could be a moot point if the property itself could be bound to a 
particular type. It would actually be a much cleaner solution, and 
wouldn't require any superfluous parens in the declaration:


class MyClass{

public SomeClass $property {
get {...}
set {...}
}
}

$foo = new MyClass;
$bar = new SomeClass;
$foo->property = $bar; //ok
$foo->property = new StdClass; //type mismatch

Heck, half the time setters and getters are implemented specifically for 
this purpose. If the property itself could be typed, then 90% of the 
time we wouldn't even need to specify get/set. Just give the property a 
type and be done with it.


That said, it wouldn't help for scalar values, and that leads to a 
problem with the current syntax (AFAICS). You can't specify the initial 
value for a property:


eg:
class MyClass{

public $property = 5//?can we do this?
{
set($value){
if(!is_int($value)){
throw new InvalidArgumentException('value of wrong type');
}
$this->__property = $value;
}
}
}

Or would that have to happen in the constructor?

class MyClass{

public $property
{
set($value){
if(!is_int($value)){
throw new InvalidArgumentException('value of wrong type');
}
$this->__property = $value;
}
}

public function __construct(){
$this->property = 5;
}
}


Cheers,
David

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Jazzer Dane]

I think Leigh brings up some important flaws to in the current RFC. What
Leigh is asking for does not appear to be possible, and in my opinion, it
should be.

I also agree with Rasmus, to a certain extent.
By putting only a getter/setter, the developer essentially sets the
property as read or write only. At first glance, there is no need for the
read-only or write-only keyword. Except... subclassing may or may not be an
issue.

By setting a property to read-only, it ensures that 'set' can never be set
by a subclass. Unless I redefine the entire property... or is that not even
possible? *The RFC isn't very clear but it appears that there is no way to
redefine the entire property, as if you define it in the subclass with only
get, then it will take set, isset, and unset from the parent class, correct?
* Though, that can be outright stopped by making the property final. But
then there is no point in having read/write-only.

>From what I can tell, read-only becomes useful if I extend the class and
want to partially modify the property.
Example:

> class A {
>   public $seconds = 3600;
>
>   public $hours {
> get() { return $this->seconds / 3600 };
>   }
> }
>
> class B extends A {
>   public $hours { // Maintains 'get' from class A
> set($value) { $this->seconds = $value; }
>   }
> }
>

^There's no way to stop the developer from doing that without read-only.

Also, if the property is public, what if an outside class tries to do this:

> class A {
>   public $seconds = 3600;
>
>   public $hours {
> get() { return $this->seconds / 3600 };
>   }
> }
>
> $object = new A();
> $object->hours = 100;
>
What happens then?

And similarly, how do we set a public property as a property accessor, hmm?

class A {
>   public $hours = 1;
> }
>
> $seconds = 20;
>
> $object = new A();
> $object->hours = { // Does this work?
>   get() { return $seconds; }
> };
>


There's definitely still some questions to answer before this RFC is ready.

On Tue, Oct 9, 2012 at 10:19 AM, Leigh  wrote:

> > RFC Document:
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> public $property {
> set { $this->property = ($this->property*2)+$value }
> get;
> }
>
> How do I reference the property being set from within the function? The way
> I have done it in the example will cause recursion? How can I assign to
> "self"?
>
> How do I set the default value of $property when the object is created?
> Surely I don't have to reverse the set accessors logic and set the inverse
> in __construct?
>

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Johannes Schlüter]

On Mon, 2012-10-08 at 11:52 +, Clint Priest wrote:
> It's been a while since I posted any updates about this, a few individuals 
> have been asking about it privately and wanting me to get it out the door for 
> PHP 5.5 release.  It's come a long way since the last time I posted about it.
> 
> RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

About the items in regards to reflection in there:

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)

The RFC also introduces a new class ReflectionPropertyAccessor and has
methods returning ReflectionProperty and ReflectionPropertyAccessor.
there should either be a common base class or interface (see i.e.
ReflectionFunctionAbstract)

What will  ReflectionPropertyAccessor->getGetter()->getName() return? I
guess reflection will be leaky there? (see first item)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Rasmus Schultz]

This looks great, and essentially has everything I had hoped for!

My only remaining comment is on the read-only and write-only keywords...
this seems really superfluous and strange to me - the syntax (using a
hyphenated keyword) and the feature itself, is way off the grid as compared
to other languages.

In my opinion, this is a feature that is so exotic, it's likely to never
actually be used by anyone.

What I dislike the most about this feature, is that it's existence may
mandate a "best practice" of declaring read-only properties as read-only.
What I mean is, because this feature exists, anytime you're declaring
something that is read-only by nature (because a write-accessor makes no
logical sense), you would be expected to declare such a property as
read-only.

In other words, not using the read-only keyword for a property that only
has a read-accessor, can only be interpreted in two ways:

1. it's an oversight, or simply bad practice.

2. it's an implied invitation to implement the write-accessor in an
extension.

Case 1 of course shouldn't happen, while case 2 would be an extremely
exotic and far-fetched scenario.

I understand the justification for this keyword - but the use-cases are
just too rare, and they don't, in my opinion, outweigh the disadvantages.

This feature just feel clumsy and out of place to me. I will never use it,
and I would strongly prefer not to have to think about it, having to
declare read-only and write-only deliberately. For 95% of cases, it's going
to be perfectly obvious, both to me and other consumers of the code, why or
whether something is read-only or write-only, and the extra guarantee or
insulation against error in the marginal 5% of cases do not justify the
effort of having to declare it explicitly everywhere.

Just my two cents...




Subject: [PHP-DEV] [RFC] Propety Accessors v1.1

It's been a while since I posted any updates about this, a few individuals
have been asking about it privately and wanting me to get it out the door
for PHP 5.5 release.  It's come a long way since the last time I posted
about it.

RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Leigh]

> RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

public $property {
set { $this->property = ($this->property*2)+$value }
get;
}

How do I reference the property being set from within the function? The way
I have done it in the example will cause recursion? How can I assign to
"self"?

How do I set the default value of $property when the object is created?
Surely I don't have to reverse the set accessors logic and set the inverse
in __construct?

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

[Nathan Bruer]

Is there a reason why we cannot implement this using PHP's already widely used 
function syntax:

class TimePeriod {
private $Seconds = 3600;

public $Hours {
public function get() { return $this->Seconds / 3600; }
private function set($value) { $this->Seconds = $value; }
/*public implied */function isset(){ return isset ($this->Seconds); }
private function unset() { unset ($this->Seconds); }
}
}

This would be much less confusing as it follows other PHP standards for 
creating functions and such. I know C# has a similar syntax to what is 
proposed, but we are not developing for C# we are developing for PHP which has 
its own syntax rules that differ from C#'s and my vote is to follow PHP's 
already in existent syntax format.

---
-Nathan Bruer

-Original Message-
From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of Etienne Kneuss
Sent: Tuesday, October 09, 2012 8:15 AM
To: Nikita Popov
Cc: Clint Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Hi,


On Tue, Oct 9, 2012 at 3:01 PM, Nikita Popov  wrote:
> On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest  wrote:
>> It's been a while since I posted any updates about this, a few individuals 
>> have been asking about it privately and wanting me to get it out the door 
>> for PHP 5.5 release.  It's come a long way since the last time I posted 
>> about it.
>>
>> RFC Document: 
>> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>>
>> Example Usage:
>>
>> class TimePeriod {
>> private $Seconds = 3600;
>>
>> public $Hours {
>> get { return $this->Seconds / 3600; }
>> set { $this->Seconds = $value; }
>> isset { return 
>> isset($this->Seconds); }
>> unset { 
>> unset($this->Seconds); }
>> }
>> }
>>
>> Changes / Updates
>>
>> * isset/unset accessor functions now implemented (object & static 
>> context, auto implementations, etc)
>>
>> * static accessor now fully functional
>>
>> * Reference functionality validated, tests written
>>
>> * All operators have been tested, tests written
>>
>> * read-only and write-only keywords: Added explanation of reasons 
>> for inclusion at the top of the appropriate RFC section
>>
>> * Tested for speed, approaches or meets __get() speed.
>>
>> Internally things have changed quite a bit
>>
>> * cleaned up and simplified
>>
>> * had been using 4 to 5 additional fn_flag slots, now down to two 
>> (READ_ONLY and WRITE_ONLY)
>>
>> * the automatic implementations now compiled internal php code, this 
>> greatly simplified that part of the code and future proofed it.
>>
>> The code is available at the url below and is up to date with master, all 
>> tests pass.
>> https://github.com/cpriest/php-src
>>
>> I'd like to get this project wrapped up in time to make it to the 5.5 
>> release, only a few things remain to be completed/updated:
>>
>> * Check on reflection code written prior to major changes (tests 
>> still pass)
>>
>> * Add a few more reflection functions that were requested
>>
>> In total there are 79 tests for this new functionality, if there are any 
>> others that I have missed, please let me know.
>
> What concerns me with the current implementation is that it leaks many 
> implementation details, in particular the fact that the accessors are 
> implemented as *real* __getXYZ methods and automatic implementations 
> also use *real* $__XYZ properties.
>
> A few examples:
>
> ## 1 - __getProperty() method directly callable
>
> class Test {
> public $property {
> get { return 123; }
> }
> }
>
> $test = new Test;
> var_dump($test->property); // int(123) 
> var_dump($test->__getProperty()); // int(123)
>
> ## 2 - __getProperty() method exposed via exception
>
> class Test {
> public $throwingProperty {
> get { throw new Exception; }
> }
> }
>
> (new Test)->throwingProperty;
>
> exception 'Exception' in /home/nikic/dev/php-src/t29.php:9 Stack 
> trace:
> #0 /home/nikic/dev/php-src/t29.php(31): Test->__getthrowingProperty()
> #1 {main}
>
> ## 3 - Can directly access $__automaticProperty and even unset it 
> (causing notices in the internal code)
>
> class Test {
> public $automaticProperty {
> get; set;
> }
>
> public function getAutomaticProperty() {
> return $this->__automaticProperty;
> }
>
> public function unsetAutomaticProperty() {
> unset($this->__automaticProperty);
> }
> }
>
> $test->automaticProperty = 'foo';
> var_dump($test->getAutomaticProperty());
> $test->unsetAutomaticProperty();
> var_dump($test->automaticProperty);
>
> string(3) "foo"
>
> Notice: Undefined property: Test::$__automaticProperty in 
> /home/nikic/dev/php-src/t29.php on line 13 NULL
>
> =
>
> I feel like this approach to the impleme

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Leigh]

> What concerns me with the current implementation is that it leaks many
> implementation details, in particular the fact that the accessors are
> implemented as *real* __getXYZ methods and automatic implementations
> also use *real* $__XYZ properties.

Further to this, take the following example.

public $_state {
set { ... }
}

This automatically generates a "hidden" function __set_state(), which
is a magic method already (and should be declared static, and take an
array as it's only parameter)

Another fine example of how automatically generating *real*
implementations can potentially break things.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Etienne Kneuss]

Hi,


On Tue, Oct 9, 2012 at 3:01 PM, Nikita Popov  wrote:
> On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest  wrote:
>> It's been a while since I posted any updates about this, a few individuals 
>> have been asking about it privately and wanting me to get it out the door 
>> for PHP 5.5 release.  It's come a long way since the last time I posted 
>> about it.
>>
>> RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>>
>> Example Usage:
>>
>> class TimePeriod {
>> private $Seconds = 3600;
>>
>> public $Hours {
>> get { return $this->Seconds / 3600; }
>> set { $this->Seconds = $value; }
>> isset { return 
>> isset($this->Seconds); }
>> unset { 
>> unset($this->Seconds); }
>> }
>> }
>>
>> Changes / Updates
>>
>> * isset/unset accessor functions now implemented (object & static 
>> context, auto implementations, etc)
>>
>> * static accessor now fully functional
>>
>> * Reference functionality validated, tests written
>>
>> * All operators have been tested, tests written
>>
>> * read-only and write-only keywords: Added explanation of reasons 
>> for inclusion at the top of the appropriate RFC section
>>
>> * Tested for speed, approaches or meets __get() speed.
>>
>> Internally things have changed quite a bit
>>
>> * cleaned up and simplified
>>
>> * had been using 4 to 5 additional fn_flag slots, now down to two 
>> (READ_ONLY and WRITE_ONLY)
>>
>> * the automatic implementations now compiled internal php code, this 
>> greatly simplified that part of the code and future proofed it.
>>
>> The code is available at the url below and is up to date with master, all 
>> tests pass.
>> https://github.com/cpriest/php-src
>>
>> I'd like to get this project wrapped up in time to make it to the 5.5 
>> release, only a few things remain to be completed/updated:
>>
>> * Check on reflection code written prior to major changes (tests 
>> still pass)
>>
>> * Add a few more reflection functions that were requested
>>
>> In total there are 79 tests for this new functionality, if there are any 
>> others that I have missed, please let me know.
>
> What concerns me with the current implementation is that it leaks many
> implementation details, in particular the fact that the accessors are
> implemented as *real* __getXYZ methods and automatic implementations
> also use *real* $__XYZ properties.
>
> A few examples:
>
> ## 1 - __getProperty() method directly callable
>
> class Test {
> public $property {
> get { return 123; }
> }
> }
>
> $test = new Test;
> var_dump($test->property); // int(123)
> var_dump($test->__getProperty()); // int(123)
>
> ## 2 - __getProperty() method exposed via exception
>
> class Test {
> public $throwingProperty {
> get { throw new Exception; }
> }
> }
>
> (new Test)->throwingProperty;
>
> exception 'Exception' in /home/nikic/dev/php-src/t29.php:9
> Stack trace:
> #0 /home/nikic/dev/php-src/t29.php(31): Test->__getthrowingProperty()
> #1 {main}
>
> ## 3 - Can directly access $__automaticProperty and even unset it
> (causing notices in the internal code)
>
> class Test {
> public $automaticProperty {
> get; set;
> }
>
> public function getAutomaticProperty() {
> return $this->__automaticProperty;
> }
>
> public function unsetAutomaticProperty() {
> unset($this->__automaticProperty);
> }
> }
>
> $test->automaticProperty = 'foo';
> var_dump($test->getAutomaticProperty());
> $test->unsetAutomaticProperty();
> var_dump($test->automaticProperty);
>
> string(3) "foo"
>
> Notice: Undefined property: Test::$__automaticProperty in
> /home/nikic/dev/php-src/t29.php on line 13
> NULL
>
> =
>
> I feel like this approach to the implementation will be a big can of
> worms. Sure, it works, but it is rather fragile and the enduser ends
> up dealing with internal stuff which he ought not care about. I think
> it would be better to cleanly separate out the accessor
> implementation. It might require more code now, but will be better in
> the long run.
>

I disagree, to me that this feature is all about syntactic sugar, as
such it does what it expected: it generates concrete properties and
methods that are somewhat hidden to the end-user.

I feel that any implementation that do not rely on proper
properties/methods would be a big hack.

Best,

> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Etienne Kneuss
http://www.colder.ch

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Nikita Popov]

On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest  wrote:
> It's been a while since I posted any updates about this, a few individuals 
> have been asking about it privately and wanting me to get it out the door for 
> PHP 5.5 release.  It's come a long way since the last time I posted about it.
>
> RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> Example Usage:
>
> class TimePeriod {
> private $Seconds = 3600;
>
> public $Hours {
> get { return $this->Seconds / 3600; }
> set { $this->Seconds = $value; }
> isset { return 
> isset($this->Seconds); }
> unset { 
> unset($this->Seconds); }
> }
> }
>
> Changes / Updates
>
> * isset/unset accessor functions now implemented (object & static 
> context, auto implementations, etc)
>
> * static accessor now fully functional
>
> * Reference functionality validated, tests written
>
> * All operators have been tested, tests written
>
> * read-only and write-only keywords: Added explanation of reasons for 
> inclusion at the top of the appropriate RFC section
>
> * Tested for speed, approaches or meets __get() speed.
>
> Internally things have changed quite a bit
>
> * cleaned up and simplified
>
> * had been using 4 to 5 additional fn_flag slots, now down to two 
> (READ_ONLY and WRITE_ONLY)
>
> * the automatic implementations now compiled internal php code, this 
> greatly simplified that part of the code and future proofed it.
>
> The code is available at the url below and is up to date with master, all 
> tests pass.
> https://github.com/cpriest/php-src
>
> I'd like to get this project wrapped up in time to make it to the 5.5 
> release, only a few things remain to be completed/updated:
>
> * Check on reflection code written prior to major changes (tests 
> still pass)
>
> * Add a few more reflection functions that were requested
>
> In total there are 79 tests for this new functionality, if there are any 
> others that I have missed, please let me know.

What concerns me with the current implementation is that it leaks many
implementation details, in particular the fact that the accessors are
implemented as *real* __getXYZ methods and automatic implementations
also use *real* $__XYZ properties.

A few examples:

## 1 - __getProperty() method directly callable

class Test {
public $property {
get { return 123; }
}
}

$test = new Test;
var_dump($test->property); // int(123)
var_dump($test->__getProperty()); // int(123)

## 2 - __getProperty() method exposed via exception

class Test {
public $throwingProperty {
get { throw new Exception; }
}
}

(new Test)->throwingProperty;

exception 'Exception' in /home/nikic/dev/php-src/t29.php:9
Stack trace:
#0 /home/nikic/dev/php-src/t29.php(31): Test->__getthrowingProperty()
#1 {main}

## 3 - Can directly access $__automaticProperty and even unset it
(causing notices in the internal code)

class Test {
public $automaticProperty {
get; set;
}

public function getAutomaticProperty() {
return $this->__automaticProperty;
}

public function unsetAutomaticProperty() {
unset($this->__automaticProperty);
}
}

$test->automaticProperty = 'foo';
var_dump($test->getAutomaticProperty());
$test->unsetAutomaticProperty();
var_dump($test->automaticProperty);

string(3) "foo"

Notice: Undefined property: Test::$__automaticProperty in
/home/nikic/dev/php-src/t29.php on line 13
NULL

=

I feel like this approach to the implementation will be a big can of
worms. Sure, it works, but it is rather fragile and the enduser ends
up dealing with internal stuff which he ought not care about. I think
it would be better to cleanly separate out the accessor
implementation. It might require more code now, but will be better in
the long run.

Nikita

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] generators & php tools

[Derick Rethans]

On Tue, 9 Oct 2012, Nikita Popov wrote:

> On Thu, Oct 4, 2012 at 9:45 AM, Derick Rethans  wrote:
> > On Sun, 30 Sep 2012, Stas Malyshev wrote:
> >
> >> I was looking into generators topic and I couldn't find answer to 
> >> this question: how generators are supposed to interact with PHP 
> >> tools, such as debuggers, profilers, etc.? Specifically, how calls 
> >> to generator are handled? Usually, the tool overrides zend_execute 
> >> and zend_execute_internal and every function call goes through 
> >> there. But generator does not use these - it uses execute_ex 
> >> instead. So can generator be debugged/profiled? What happens if I 
> >> say "step out" inside generator - would that work?
> >
> > It won't work with Xdebug right now, as it indeed overrides just 
> > zend_execute and zend_execute_internal --- we should definitely look 
> > at fixing generators that they go through those as well. It's 
> > related to the zend_execute_internal hook missing from the other 
> > email that I just replied to (and your PR 178).
> 
> Generators won't be able to go through zend_execute, because they need 
> to work on an existing execution context and not create a new one on 
> every resume. So instead we will probably need an additional hook for 
> execute_ex (in which case the existing execute hook isn't really 
> necessary anymore).
> 
> Would that be okay?

Let's find out! I'd be happy to play around with this new hook and see 
whether it works.

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] generators & php tools

[Nikita Popov]

On Thu, Oct 4, 2012 at 9:45 AM, Derick Rethans  wrote:
> On Sun, 30 Sep 2012, Stas Malyshev wrote:
>
>> I was looking into generators topic and I couldn't find answer to this
>> question: how generators are supposed to interact with PHP tools, such
>> as debuggers, profilers, etc.? Specifically, how calls to generator
>> are handled? Usually, the tool overrides zend_execute and
>> zend_execute_internal and every function call goes through there. But
>> generator does not use these - it uses execute_ex instead. So can
>> generator be debugged/profiled? What happens if I say "step out"
>> inside generator - would that work?
>
> It won't work with Xdebug right now, as it indeed overrides just
> zend_execute and zend_execute_internal  --- we should definitely look at
> fixing generators that they go through those as well. It's related to
> the zend_execute_internal hook missing from the other email that I just
> replied to (and your PR 178).
>
> cheers,
> Derick

Generators won't be able to go through zend_execute, because they need
to work on an existing execution context and not create a new one on
every resume. So instead we will probably need an additional hook for
execute_ex (in which case the existing execute hook isn't really
necessary anymore).

Would that be okay?
Nikita

XDebug execute and execute_internal:
https://github.com/derickr/xdebug/blob/master/xdebug.c#L1215
https://github.com/derickr/xdebug/blob/master/xdebug.c#L1442

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] SoapClient: Catchable Fatal Error for invalid WSDL

[Nicolai Scheer]

Hi!

Just read the comments for Bug #47584: WSDL error in soapClient causes
Fatal Error.

If a SoapClient is created and the WSDL can not be found, an Exception
is thrown:

 1 ) );
}
catch ( Exception $e )
{
echo $e->faultstring;
}

echo "ok\n";

$error = error_get_last();
print_r( $error );
?>

Although I'm using exceptions here, an E_ERROR gets "registered", thus
the output is:

SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-existent.wsdl' :
failed to load external entity "non-existent.wsdl"
ok
Array
(
[type] => 1
[message] => SOAP-ERROR: Parsing WSDL: Couldn't load from
'non-existent.wsdl' : failed to load external entity
"non-existent.wsdl"

[file] => Y:\client2.phb
[line] => 5
)


Can anybody comment on this behaviour? Should an error be registered
when exceptions are used? Should this be an E_RECOVERABLE_ERROR
instead?
The specific problem is that we use a shutdown function that utilizes
error_get_last() to see if a fatal error orccured and then tries to
redirect to a specific error page.
Now we call a php script via ajax that tries to connect to a soap
service. If the service is unreachable we correctly catch the
exception, but the registered E_ERROR gets processed on shutdown, thus
redirecting...

Thanks and greetings

Nico

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] stream_get_line behaviour Bug #63240

[Sherif Ramadan]

On Tue, Oct 9, 2012 at 5:10 AM, Tjerk Anne Meesters  wrote:
> Hi,
>
> I've managed to pinpoint the issue inside the code itself and attached a
> patch for 5.4.4 (I can make one for trunk as well, but at the time of
> writing I worked with what I had).
>
> The bug manifests itself when delimiter size > 1 AND the file pointer falls
> in between a delimiter after filling the read buffer with
> php_stream_fill_read_buffer().
>
> When this happens, the part of the delimiter that falls on the left side of
> the file pointer is skipped at the next iteration because it was examined
> before; however, that only makes sense for single character delimiters.
>
> My patch will decrement the skip length (if non-zero) by at most  length - 1> bytes before performing the search. This will make sure any
> buffered characters are taken into consideration (again).
>
>


Yup, that makes perfect sense. I had narrowed it down to somewhere
within _php_stream_search_delim, but I couldn't actually think of a
reasonable fix without potentially breaking something else. This looks
quite reasonable and I think it should work fine.


> On Tue, Oct 9, 2012 at 4:33 PM, Sherif Ramadan 
> wrote:
>>
>> On Tue, Oct 9, 2012 at 12:59 AM, Tjerk Anne Meesters 
>> wrote:
>> > On Tue, Oct 9, 2012 at 12:14 AM, Nicolai Scheer
>> > wrote:
>> >
>> >> Hi!
>> >>
>> >> We switched from php 5.3.10 to 5.3.17 this weekend and stumbled upon a
>> >> behaviour of stream_get_line that is most likely a bug and breaks a
>> >> lot of our file processing code.
>> >>
>> >> The issue seems to have been introduced from 5.3.10 to 5.3.11.
>> >>
>> >> I opened a bug report: #63240.
>> >>
>> >
>> > I've managed to reduce the code to this; it's very specific:
>> >
>> > $file = __DIR__ . '/input_dummy.txt';
>> > $delimiter = 'MM';
>> > file_put_contents($file, str_repeat('.', 8189) . $delimiter .
>> > $delimiter);
>> >
>> > $fh = fopen($file, "rb");
>> >
>> > stream_get_line($fh, 8192, $delimiter);
>> > var_dump($delimiter === stream_get_line($fh, 8192, $delimter));
>> >
>> > fclose($fh);
>> > unlink($file);
>> >
>> > If the internal buffer length is 8192, after the first call to
>> > stream_get_line() the read position (x) and physical file pointer (y)
>> > should be positioned like so:
>> >
>> > ...MM(x)M(y)M
>> >
>> > The fact that (y) is in between the delimiter seems to cause an issue.
>> >
>> >
>>
>>
>> I'm not sure why this bug exists, and I haven't exactly been able to
>> pinpoint where the bug manifests itself, but something I find
>> incredibly unusual here is the fact that the size of the stream being
>> exactly 8193 bytes long is the reason the bug exists.
>>
>> It has nothing to do with the file pointers position since all we have
>> to do here is increase or decrease the size of the file by exactly 1
>> byte and the bug will never show its face.
>>
>> Test case 1: (we decrease the file size from 8193 bytes to 8192 bytes)
>>
>> $file = __DIR__ . '/input_dummy.txt';
>> $delimiter = 'MM';
>> file_put_contents($file, str_repeat('.', 8188) . $delimiter . $delimiter);
>>
>> $fh = fopen($file, "rb");
>>
>> stream_get_line($fh, 8192, $delimiter);
>> var_dump($delimiter === stream_get_line($fh, 8192, $delimiter));
>>
>> fclose($fh);
>> unlink($file);
>>
>> /* bool(false) */
>>
>> ---
>>
>> Test 2: (we increase the file size from 8193 bytes to 8194 bytes)
>>
>> $file = __DIR__ . '/input_dummy.txt';
>> $delimiter = 'MM';
>> file_put_contents($file, str_repeat('.', 8190) . $delimiter . $delimiter);
>>
>> $fh = fopen($file, "rb");
>>
>> stream_get_line($fh, 8192, $delimiter);
>> var_dump($delimiter === stream_get_line($fh, 8192, $delimiter));
>>
>> fclose($fh);
>> unlink($file);
>>
>> /* bool(false) */
>>
>>
>> --
>>
>>
>> As long as the file size is not exactly equal to 8193 bytes you don't
>> get this issue. In fact, you can test it with any multiple of 8192 + 1
>> and the same issue appears. However, the bigger anomaly is that it
>> also requires the length of the delimiter to be larger than 1 before
>> the bug manifests itself.
>>
>> I suspect this has something to do with the way PHP streams are
>> buffered internally. The internal stream is read up to a certain
>> length and buffered in memory using the internal API functions, while
>> your calls to PHP-facing functions like stream_get_line() read
>> directly from the buffer instead. So it's possible somewhere in this
>> function (line 1026 of main/streams/streams.c
>> http://lxr.php.net/xref/PHP_5_4/main/streams/streams.c#1026) lies the
>> bug.
>>
>>
>>
>> >> The issue seems to be related to #44607, but that one got fixed years
>> >> ago.
>> >>
>> >> Is anybody able to confirm this behaviour or has stumbled upon this?
>> >>
>> >> Furthermore the behaviour of stream_get_line on an empty file seems to
>> >> have changed between php 5.3.10 and php 5.3.11:
>> >>
>> >> > >>
>> >> $file = __DIR__ . 'empty.txt';
>> >> file_put_contents( $file, '' );
>> >> $fh = fop

Re: [PHP-DEV] stream_get_line behaviour Bug #63240

[Tjerk Anne Meesters]

Hi,

I've managed to pinpoint the issue inside the code itself and attached a
patch for 5.4.4 (I can make one for trunk as well, but at the time of
writing I worked with what I had).

The bug manifests itself when delimiter size > 1 AND the file pointer falls
in between a delimiter after filling the read buffer with
php_stream_fill_read_buffer().

When this happens, the part of the delimiter that falls on the left side of
the file pointer is skipped at the next iteration because it was examined
before; however, that only makes sense for single character delimiters.

My patch will decrement the skip length (if non-zero) by at most  bytes before performing the search. This will make sure any
buffered characters are taken into consideration (again).


On Tue, Oct 9, 2012 at 4:33 PM, Sherif Ramadan wrote:

> On Tue, Oct 9, 2012 at 12:59 AM, Tjerk Anne Meesters 
> wrote:
> > On Tue, Oct 9, 2012 at 12:14 AM, Nicolai Scheer  >wrote:
> >
> >> Hi!
> >>
> >> We switched from php 5.3.10 to 5.3.17 this weekend and stumbled upon a
> >> behaviour of stream_get_line that is most likely a bug and breaks a
> >> lot of our file processing code.
> >>
> >> The issue seems to have been introduced from 5.3.10 to 5.3.11.
> >>
> >> I opened a bug report: #63240.
> >>
> >
> > I've managed to reduce the code to this; it's very specific:
> >
> > $file = __DIR__ . '/input_dummy.txt';
> > $delimiter = 'MM';
> > file_put_contents($file, str_repeat('.', 8189) . $delimiter .
> $delimiter);
> >
> > $fh = fopen($file, "rb");
> >
> > stream_get_line($fh, 8192, $delimiter);
> > var_dump($delimiter === stream_get_line($fh, 8192, $delimter));
> >
> > fclose($fh);
> > unlink($file);
> >
> > If the internal buffer length is 8192, after the first call to
> > stream_get_line() the read position (x) and physical file pointer (y)
> > should be positioned like so:
> >
> > ...MM(x)M(y)M
> >
> > The fact that (y) is in between the delimiter seems to cause an issue.
> >
> >
>
>
> I'm not sure why this bug exists, and I haven't exactly been able to
> pinpoint where the bug manifests itself, but something I find
> incredibly unusual here is the fact that the size of the stream being
> exactly 8193 bytes long is the reason the bug exists.
>
> It has nothing to do with the file pointers position since all we have
> to do here is increase or decrease the size of the file by exactly 1
> byte and the bug will never show its face.
>
> Test case 1: (we decrease the file size from 8193 bytes to 8192 bytes)
>
> $file = __DIR__ . '/input_dummy.txt';
> $delimiter = 'MM';
> file_put_contents($file, str_repeat('.', 8188) . $delimiter . $delimiter);
>
> $fh = fopen($file, "rb");
>
> stream_get_line($fh, 8192, $delimiter);
> var_dump($delimiter === stream_get_line($fh, 8192, $delimiter));
>
> fclose($fh);
> unlink($file);
>
> /* bool(false) */
>
> ---
>
> Test 2: (we increase the file size from 8193 bytes to 8194 bytes)
>
> $file = __DIR__ . '/input_dummy.txt';
> $delimiter = 'MM';
> file_put_contents($file, str_repeat('.', 8190) . $delimiter . $delimiter);
>
> $fh = fopen($file, "rb");
>
> stream_get_line($fh, 8192, $delimiter);
> var_dump($delimiter === stream_get_line($fh, 8192, $delimiter));
>
> fclose($fh);
> unlink($file);
>
> /* bool(false) */
>
>
> --
>
>
> As long as the file size is not exactly equal to 8193 bytes you don't
> get this issue. In fact, you can test it with any multiple of 8192 + 1
> and the same issue appears. However, the bigger anomaly is that it
> also requires the length of the delimiter to be larger than 1 before
> the bug manifests itself.
>
> I suspect this has something to do with the way PHP streams are
> buffered internally. The internal stream is read up to a certain
> length and buffered in memory using the internal API functions, while
> your calls to PHP-facing functions like stream_get_line() read
> directly from the buffer instead. So it's possible somewhere in this
> function (line 1026 of main/streams/streams.c
> http://lxr.php.net/xref/PHP_5_4/main/streams/streams.c#1026) lies the
> bug.
>
>
>
> >> The issue seems to be related to #44607, but that one got fixed years
> ago.
> >>
> >> Is anybody able to confirm this behaviour or has stumbled upon this?
> >>
> >> Furthermore the behaviour of stream_get_line on an empty file seems to
> >> have changed between php 5.3.10 and php 5.3.11:
> >>
> >>  >>
> >> $file = __DIR__ . 'empty.txt';
> >> file_put_contents( $file, '' );
> >> $fh = fopen( $file, 'rb' );
> >> $data = stream_get_line( $fh, 4096 );
> >> var_dump( $data );
> >>
> >> result in
> >>
> >> string(0) ""
> >>
> >> for php 5.3.10
> >>
> >> and in
> >>
> >> bool(false)
> >>
> >> for php > 5.3.10.
> >
> > I don't know if this should be considered a bug, but as far as I know
> >> such a behaviour should not change during minor releases...
> >>
> >> Any insight is appreciated!
> >>
> >> Greetings
> >>
> >> Nico
> >>
> >> --
> >> PHP Internals - PHP Runtime Development 

Re: [PHP-DEV] stream_get_line behaviour Bug #63240

[Sherif Ramadan]

On Tue, Oct 9, 2012 at 12:59 AM, Tjerk Anne Meesters  wrote:
> On Tue, Oct 9, 2012 at 12:14 AM, Nicolai Scheer wrote:
>
>> Hi!
>>
>> We switched from php 5.3.10 to 5.3.17 this weekend and stumbled upon a
>> behaviour of stream_get_line that is most likely a bug and breaks a
>> lot of our file processing code.
>>
>> The issue seems to have been introduced from 5.3.10 to 5.3.11.
>>
>> I opened a bug report: #63240.
>>
>
> I've managed to reduce the code to this; it's very specific:
>
> $file = __DIR__ . '/input_dummy.txt';
> $delimiter = 'MM';
> file_put_contents($file, str_repeat('.', 8189) . $delimiter . $delimiter);
>
> $fh = fopen($file, "rb");
>
> stream_get_line($fh, 8192, $delimiter);
> var_dump($delimiter === stream_get_line($fh, 8192, $delimter));
>
> fclose($fh);
> unlink($file);
>
> If the internal buffer length is 8192, after the first call to
> stream_get_line() the read position (x) and physical file pointer (y)
> should be positioned like so:
>
> ...MM(x)M(y)M
>
> The fact that (y) is in between the delimiter seems to cause an issue.
>
>


I'm not sure why this bug exists, and I haven't exactly been able to
pinpoint where the bug manifests itself, but something I find
incredibly unusual here is the fact that the size of the stream being
exactly 8193 bytes long is the reason the bug exists.

It has nothing to do with the file pointers position since all we have
to do here is increase or decrease the size of the file by exactly 1
byte and the bug will never show its face.

Test case 1: (we decrease the file size from 8193 bytes to 8192 bytes)

$file = __DIR__ . '/input_dummy.txt';
$delimiter = 'MM';
file_put_contents($file, str_repeat('.', 8188) . $delimiter . $delimiter);

$fh = fopen($file, "rb");

stream_get_line($fh, 8192, $delimiter);
var_dump($delimiter === stream_get_line($fh, 8192, $delimiter));

fclose($fh);
unlink($file);

/* bool(false) */

---

Test 2: (we increase the file size from 8193 bytes to 8194 bytes)

$file = __DIR__ . '/input_dummy.txt';
$delimiter = 'MM';
file_put_contents($file, str_repeat('.', 8190) . $delimiter . $delimiter);

$fh = fopen($file, "rb");

stream_get_line($fh, 8192, $delimiter);
var_dump($delimiter === stream_get_line($fh, 8192, $delimiter));

fclose($fh);
unlink($file);

/* bool(false) */


--


As long as the file size is not exactly equal to 8193 bytes you don't
get this issue. In fact, you can test it with any multiple of 8192 + 1
and the same issue appears. However, the bigger anomaly is that it
also requires the length of the delimiter to be larger than 1 before
the bug manifests itself.

I suspect this has something to do with the way PHP streams are
buffered internally. The internal stream is read up to a certain
length and buffered in memory using the internal API functions, while
your calls to PHP-facing functions like stream_get_line() read
directly from the buffer instead. So it's possible somewhere in this
function (line 1026 of main/streams/streams.c
http://lxr.php.net/xref/PHP_5_4/main/streams/streams.c#1026) lies the
bug.



>> The issue seems to be related to #44607, but that one got fixed years ago.
>>
>> Is anybody able to confirm this behaviour or has stumbled upon this?
>>
>> Furthermore the behaviour of stream_get_line on an empty file seems to
>> have changed between php 5.3.10 and php 5.3.11:
>>
>> >
>> $file = __DIR__ . 'empty.txt';
>> file_put_contents( $file, '' );
>> $fh = fopen( $file, 'rb' );
>> $data = stream_get_line( $fh, 4096 );
>> var_dump( $data );
>>
>> result in
>>
>> string(0) ""
>>
>> for php 5.3.10
>>
>> and in
>>
>> bool(false)
>>
>> for php > 5.3.10.
>
> I don't know if this should be considered a bug, but as far as I know
>> such a behaviour should not change during minor releases...
>>
>> Any insight is appreciated!
>>
>> Greetings
>>
>> Nico
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> --
> Tjerk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Jazzer Dane]

Christian, I think a majority of your concerns are all for none.
>From top to bottom:

- Extra indention: This is definitely a bias and is only moderately
relevant while documenting this feature.

- You *can* declare a public getter and private setter, or vice versa, or
whatever you want. This is in the RFC. See "Asymmetric Accessor
Accessibility."

- "If we ever get return type hinting/checks then we needn't consider how
the syntax has to look" From what I know, this isn't planned for PHP 5.5
and any proposals for it have been largely ignored. Return type hinting
won't help when setting either, although it would help with getting. All
that being said, type hinting aside, the syntax I proposed is, in my
opinion, the most consistent out of any other proposal thus far (arguably
aside from yours, I'll go over that momentarily).

- "We must deal with two different syntaxes for the same thing" I don't
quite understand what you mean here, unless you're talking about braces
inside braces. It seems your code examples make your intended point here a
bit clearer, though.

- "IDE's, documentation tools, static analyses tools or similar tools have
a huge effort to implement this syntax. With the method syntax it's only a
small effort" While we want to strive to keep a clean and consistent
syntax, I don't think molding to whatever is easiest for IDE's is a good
idea.

- "We have to create new rules about how the documentation for this syntax
should look like" From my point of view, this isn't so much a concern as a
to-do item later on.


On to your proposal:

I'm not a fan of this:

> public function get hours() {}
>
This is adding another keyword after function, which is arguably more
inconsistent than some previous proposals.

I'm sort of okay with this:

> public get hours() {}
>
Replacing function with get/set/isset/unset... but it still seems a bit too
inconsistent and insensible. Replacing the function keyword with the name
of a preexisting function? I also do not like how the accessors are
separated from one another, which is not the case with the previous
proposals.

All in all, I still prefer my previous proposal to this.

On Tue, Oct 9, 2012 at 12:46 AM, Christian Kaps
wrote:

> Hi,
>
> typehinting should definitely be available for this feature. But I have
> another question. Why not go more consistent with the rest of the language?
> I have mentioned this previously as the first proposal comes up on the
> list. In my opinion the AS3 getter and setter syntax(
> http://help.adobe.com/**en_US/ActionScript/3.0_**ProgrammingAS3/**
> WS5b3ccc516d4fbf351e63e3d118a9**b90204-7f30.html#**
> WS5b3ccc516d4fbf351e63e3d118a9**b90204-7fcb)
> fits more into the language as the proposed one.
>
> Here are my concerns:
> - I do not like the extra indentation level and it's ugly to document (OK,
> this is a personal preference)
> - It isn't possible to declare a private setter and a public getter, as it
> is possible with methods
> - If we ever get return type hinting/checks then we needn't consider how
> the syntax has to look
> - We must deal with two different syntaxes for the same thing, because
> both are methods
> - IDE's, documentation tools, static analyses tools or similar tools have
> a huge effort to implement this syntax. With the method syntax it's only a
> small effort
> - We have to create new rules about how the documentation for this syntax
> should look like
>
> For me the following syntax seems more consistent with the rest of PHP:
>
> public get hours() {}
> public set hours(DateTime $dateTime) {}
> public isset hours() {}
> public unset hours() {}
>
> Or:
>
> public function get hours() {}
> public function set hours(DateTime $dateTime) {}
> public function isset hours() {}
> public function unset hours() {}
>
> Or:
>
> public function get $hours() {}
> public function set $hours(DateTime $dateTime) {}
> public function isset $hours() {}
> public function unset $hours() {}
>
> Cheers,
> Christian
>
> Am 09.10.2012 05:08, schrieb Jazzer Dane:
>
>> While I understand your concern with set being the only keyword using (),
>> and even agree it's a bit problematic, I see a big problem with using
>> $value.
>>
>> Even if $value internally makes sense due to something along the lines of
>> *
>> __setHours($value)* {} being equal to *set {}*, I think using $value
>>
>> without it ever being defined in the developer's code is not at all a good
>> idea.
>> If I see $value in the code, I'll logically look for where it was defined,
>> and when I don't see it anywhere else in the code, things are going to
>> very
>> quickly get confusing.
>> Our best option to combat this confusion is, in my eyes, putting a note in
>> the documentation. That's not enough.
>>
>> A similar alternative to using $value that I'd argue would be much more
>> sensible would be to, as Denis mentio

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Sebastian Krebs]

2012/10/9 Christian Kaps 

> Hi,
>
> typehinting should definitely be available for this feature. But I have
> another question. Why not go more consistent with the rest of the language?
> I have mentioned this previously as the first proposal comes up on the
> list. In my opinion the AS3 getter and setter syntax(
> http://help.adobe.com/**en_US/ActionScript/3.0_**ProgrammingAS3/**
> WS5b3ccc516d4fbf351e63e3d118a9**b90204-7f30.html#**
> WS5b3ccc516d4fbf351e63e3d118a9**b90204-7fcb)
> fits more into the language as the proposed one.
>
> Here are my concerns:
> - I do not like the extra indentation level and it's ugly to document (OK,
> this is a personal preference)
>

I guess it's more useful to document the property as a whole and not every
single accessor on it's own.


> - It isn't possible to declare a private setter and a public getter, as it
> is possible with methods
>

As far as I understand it it is possible.


> - If we ever get return type hinting/checks then we needn't consider how
> the syntax has to look
>
- We must deal with two different syntaxes for the same thing, because both
> are methods
>

For now it seems the only bigger difference is, that the keyword 'function'
is omitted. You can propose to add it :)


> - IDE's, documentation tools, static analyses tools or similar tools have
> a huge effort to implement this syntax. With the method syntax it's only a
> small effort
>

The tools should not decide how the language should look like, just because
it makes their life easier ;)


> - We have to create new rules about how the documentation for this syntax
> should look like
>

Why should the documentation differ from the documentation for regular
properties?


>
> For me the following syntax seems more consistent with the rest of PHP:
>
> public get hours() {}
> public set hours(DateTime $dateTime) {}
> public isset hours() {}
> public unset hours() {}
>
> Or:
>
> public function get hours() {}
> public function set hours(DateTime $dateTime) {}
> public function isset hours() {}
> public function unset hours() {}
>
> Or:
>
> public function get $hours() {}
> public function set $hours(DateTime $dateTime) {}
> public function isset $hours() {}
> public function unset $hours() {}
>

I don't like how it separate the single accessors from each other. The
benefit from this RFC (imo) -- especially compared to __get()/__set() --
is, that every accessors is directly and obviously bound to the (single)
property: You have a single block with all the corresponding accessors in
it and not several (on the first glance: different) methods, that could be
spread over the whole class.

Maybe it's just me, but I really would like to see this feature in 5.5. As
far as I remember it was first proposed for 5.3 and now (years after)
seeing it delayed, because the syntax "looks ugly (just my opinion)" makes
me feel a little bit ... ehm ... sad. I think the syntax is fine and it
seems it covers the most important points (even not all). There is a
property and "the value" of the property are the accessors. I bet we could
find an infinite number of different syntax, that provides exactly the same
functionality, but why?

Regards,
Sebastian


>
> Cheers,
> Christian
>
> Am 09.10.2012 05:08, schrieb Jazzer Dane:
>
>  While I understand your concern with set being the only keyword using (),
>> and even agree it's a bit problematic, I see a big problem with using
>> $value.
>>
>> Even if $value internally makes sense due to something along the lines of
>> *
>> __setHours($value)* {} being equal to *set {}*, I think using $value
>> without it ever being defined in the developer's code is not at all a good
>> idea.
>> If I see $value in the code, I'll logically look for where it was defined,
>> and when I don't see it anywhere else in the code, things are going to
>> very
>> quickly get confusing.
>> Our best option to combat this confusion is, in my eyes, putting a note in
>> the documentation. That's not enough.
>>
>> A similar alternative to using $value that I'd argue would be much more
>> sensible would be to, as Denis mentioned, use either a magic constant or a
>> superglobal.
>>
>> As I mentioned previously, I would rather go with the set($value) {}
>> syntax.
>>
>> Now, back to the part where I agree with you - the inconsistency wherein
>> set has () that denote it is a method but get, isset, and unset do not. I
>> see this inconsistency as something problematic enough to warrant a
>> solution.
>>
>> We could go with the following:
>> public $Hours {
>>   get() { ... }
>>   set($value) { ... }
>>   isset() { ... }
>>   unset() { ... }
>> }
>>
>> Yes, we now have a little bit more meat on the syntax, but in this case, I
>> don't think that it's all that bad. Here's two reasons why:
>> 1) Adding parenthesis denotes that they are all functions - which they
>> are!
>

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Christian Kaps]

Hi,

typehinting should definitely be available for this feature. But I have 
another question. Why not go more consistent with the rest of the 
language? I have mentioned this previously as the first proposal comes 
up on the list. In my opinion the AS3 getter and setter 
syntax(http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb) 
fits more into the language as the proposed one.


Here are my concerns:
- I do not like the extra indentation level and it's ugly to document 
(OK, this is a personal preference)
- It isn't possible to declare a private setter and a public getter, as 
it is possible with methods
- If we ever get return type hinting/checks then we needn't consider 
how the syntax has to look
- We must deal with two different syntaxes for the same thing, because 
both are methods
- IDE's, documentation tools, static analyses tools or similar tools 
have a huge effort to implement this syntax. With the method syntax it's 
only a small effort
- We have to create new rules about how the documentation for this 
syntax should look like


For me the following syntax seems more consistent with the rest of PHP:

public get hours() {}
public set hours(DateTime $dateTime) {}
public isset hours() {}
public unset hours() {}

Or:

public function get hours() {}
public function set hours(DateTime $dateTime) {}
public function isset hours() {}
public function unset hours() {}

Or:

public function get $hours() {}
public function set $hours(DateTime $dateTime) {}
public function isset $hours() {}
public function unset $hours() {}

Cheers,
Christian

Am 09.10.2012 05:08, schrieb Jazzer Dane:
While I understand your concern with set being the only keyword using 
(),

and even agree it's a bit problematic, I see a big problem with using
$value.

Even if $value internally makes sense due to something along the 
lines of *

__setHours($value)* {} being equal to *set {}*, I think using $value
without it ever being defined in the developer's code is not at all a 
good

idea.
If I see $value in the code, I'll logically look for where it was 
defined,
and when I don't see it anywhere else in the code, things are going 
to very

quickly get confusing.
Our best option to combat this confusion is, in my eyes, putting a 
note in

the documentation. That's not enough.

A similar alternative to using $value that I'd argue would be much 
more
sensible would be to, as Denis mentioned, use either a magic constant 
or a

superglobal.

As I mentioned previously, I would rather go with the set($value) {} 
syntax.


Now, back to the part where I agree with you - the inconsistency 
wherein
set has () that denote it is a method but get, isset, and unset do 
not. I

see this inconsistency as something problematic enough to warrant a
solution.

We could go with the following:
public $Hours {
  get() { ... }
  set($value) { ... }
  isset() { ... }
  unset() { ... }
}

Yes, we now have a little bit more meat on the syntax, but in this 
case, I

don't think that it's all that bad. Here's two reasons why:
1) Adding parenthesis denotes that they are all functions - which 
they are!
If anything, adding parenthesis to all of them makes the 
implementation *

more* sensible.
2) It's *only* two more characters per function. On top of that, in 
my
opinion, this syntax is not "ugly". In fact, as I just mentioned - 
this

implementation is arguably *more* consistent with the rest of PHP.

On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest  
wrote:


Seems a fair amount of people would like it with a definable 
parameter
name, though the original RFC I based mine off of is more than 4 
years old

(mine is over a year old already).

The $value is precisely chosen because it is exactly the way C# 
operates
and the original author thought to keep it the same as another 
well-known

language (why re-invent new syntax for no reason).

That being said, javascript does indeed allow it, my concern then 
would be
would we have the parameterized syntax only for set() and not get, 
isset or

unset?

If we do have them for all of them, it's a lot of extra characters 
with no

real need.

I definitely favor set($value) over a magic $Hours for the $Hours
property, but I personally see no problem with the $value, it's not 
magic

it's a locally defined variable.

Internally, this:
   public $Hours {
  get { ... }
  set { ... }
   }

Is implemented as standard functions, while they are hidden through
reflection, these functions exist (as a result of the above 
example):


public __getHours() { ... }
public __setHours($value) { ... }

Lastly, with regards to JavaScript style getters/setters, I don't 
think
I've ever cared what the variable name was, I typically just do 
something

like:

set blah(x) { ... } <-- x is fairly irrelevant and similarly the use 
of

$value is fairly irrelevant.   Thoughts?

> -Original Message-
> From: Jazzer Dane [mailto:tbprogram.