Hi,
I also find this syntax confusing and I think it has a huge WTF factor.
Some thoughts about the syntax:
- At the first glance, it isn't clear which visibility the getter or
setter has
- The extra indentation level makes the code more unreadable
class Foo {
/**
*
*/
private $_bar;
/**
*
*/
public $bar{
/**
*
*/
set {
if ($bar) {
$this->_bar = $bar * 12;
} else {
$this->_bar = 0
}
}
/**
*
*/
private set {
if ($this->_bar === null) {
return 0;
}
return $this->_bar;
}
}
/**
*
*/
public function baz() {
}
}
- What about type hints?
I prefer a more AS3 like getter and setter syntax.
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb
Have you read my previous mail http://news.php.net/php.internals/56762.
I think this syntax fits more to PHP because its similar to the already
existing(magic) getter and setter syntax.
What do you think?
Christian
Am 06.12.2011 04:23, schrieb Clint M Priest:
I believe the attempt with the RFC was to mimic the syntax that C#
went with, the RFC is here:
https://wiki.php.net/rfc/propertygetsetsyntax
The first public would apply to either of the get/set which did not
have it further defined, for example:
public $Hours {
get { ... }
private set { ... }
}
Also, with automatic implementations (at present) the parent access
level controls the automatic property generation:
private $Hours {
public get;
public set;
}
Would define an internal variable of $__Hours as private. Perhaps it
should always be a private internal variable, it was not designated
in
the rfc and I made it this way to be the most flexible for the
author.
-----Original Message-----
From: Rasmus Schultz [mailto:ras...@mindplay.dk]
Sent: Monday, December 05, 2011 5:11 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: Patch: getters/setters syntax Implementation
2011/12/4 Clint M Priest <cpri...@zerocue.com>:
Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch
In the end it is a relatively simple patch. The new syntax
effectively
creates internal functions on the object and the system looks for
those functions and calls them at the appropriate time.
Example:
class z {
public $Hours {
public get { return $this->_Hours; }
protected set { $this->_Hours = $value; }
}
}
Defines:
$o->__getHours();
$o->__setHours($value);
You forgot to declare the backing field z::$_Hours in this example.
From a semantic point of view, I find it misleading to first declare
$Hours as public, then lowering the bar by making the set-accessor
protected.
The most common use-case for accessors is public - so I would suggest
a syntax more along the lines of this:
class z {
private $_hours;
get $hours { // accessor is public by default
return $this->_hours;
}
protected set $hours {
$this->_hours = $hours; // local variable $hours is the new value
}
}
And perhaps a short form for added convenience, where the
backing-field is automatically added for you - e.g.:
class z {
get $hours { // accessor is public by default
return $value; // $value provides access to the backing field
(same way $this provides access to the object context)
}
protected set $hours {
$value = $hours; // local variable $hours is the new value,
$value references the backing field
}
}
thoughts?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
