Re: [PHP-DEV] git anyone?
On 2010-11-29, Clint Byrum cl...@ubuntu.com wrote: On Sat, 2010-11-27 at 16:26 +, Lester Caine wrote: I've not used git or hg much at all, but bzr has always satisfied my needs for DVCS, and has recently gotten much faster and more space efficient than it was in the past. Sorry, but I think bzr is not a good fit. It's numerous changes to the repository format make it impossible to use. It's either slow if you use an old version, or it's incompatible with old clients, let's say on an old debian box. So I think php.net is better of using mercurial or git, but if we put together an RFC for a migration, I'll make sure bzr is covered as well in an evaluation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Sun, Nov 28, 2010 at 11:48 PM, Christian Kaps
christian.k...@mohiva.com wrote:
...
/**
*
*/
public function set name(string $name) {
$this-name = htmlentities($name);
$this-name = strip_tags($this-name);
}
/**
*
*/
public function get name($name) {
return $this-name;
}
Greetings,
Christian
For whatever it's worth, I think that this syntax fits much better
into PHP than do either of the those in the RFC.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
David Soria Parra wrote: On 2010-11-29, Clint Byrumcl...@ubuntu.com wrote: On Sat, 2010-11-27 at 16:26 +, Lester Caine wrote: I've not used git or hg much at all, but bzr has always satisfied my needs for DVCS, and has recently gotten much faster and more space efficient than it was in the past. Sorry, but I think bzr is not a good fit. It's numerous changes to the repository format make it impossible to use. It's either slow if you use an old version, or it's incompatible with old clients, let's say on an old debian box. So I think php.net is better of using mercurial or git, but if we put together an RFC for a migration, I'll make sure bzr is covered as well in an evaluation. Personally I would need a very good reason to add yet another DVCS to the mix here! I've not found bzr as easy to link to from hg as git is. In fact I've not actually got it to play at all as yet ... while hg does work into git with only the problems of managing multiple repo's which is still work in progress on both of them. That said, bzr does seem to handle the multiple repo's in a more user friendly manor? It is just a pity that there is NOT a single target solution for DVCS as everybody is currently scurrying off to their own corners :( The barriers have already been drawn rather then there being concensus on some sort of standard. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 28 November 2010 23:18, presid...@basnetworks.net wrote:
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
I'd really like this feature to be part of PHP.
I don't particularly like the use of what looks like a closure for the set/get.
I used to code in Delphi and I always like the way in which their
properties were defined.
Essentially, the setter and getter are normal methods which are cherry
picked for a property [1].
?php
class TimePeriod
{
protected $seconds;
public property Hours read getHours write setHours;
protected function getHours()
{
return $this-seconds / 3600;
}
protected function setHours()
{
$this-seconds = $value * 3600;
}
// This property is read-only
public property Minutes read getMinutes;
protected function getMinutes()
{
return $this-seconds / 60;
}
public property Milliseconds read getMilliseconds write setMilliseconds;
public function getMilliseconds()
{
// This method is public
return $this-seconds * 60;
}
protected function setMilliseconds()
{
// This method is protected
$this-seconds = $value * 3600;
}
}
For me, the advantage here is that I can independently the methods
from the property. If I want to force a subclass to implement a
setter/getter, then I can abstract the function in the base class.
Sure, some may say that I should be using an interface. I disagree as
I probably don't want the methods to be public. Protected or even
private and/or final.
The classic example is one of shapes. Every shape has a public $area
property, but the value would be provided by an abstract protected
TShape::getArea(); method. I can also finalise them, so, for example,
a triangle shape could have a final protected getArea() method and all
sub classes of triangles (scalene, isosceles, equilateral) would not
implement their own getArea() method.
The downside is certainly that the code is more verbose than I would
guess many people would like.
Regards,
Richard.
[1] http://www.delphibasics.co.uk/RTL.asp?Name=Property
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
Hi Dmitry, 2010/11/29 Dmitry Stogov dmi...@zend.com Hi Felipe, I'm wondered it works out of the box with so small patches :) However, both patches introduce new parser conflicts and it would be grate to avoid them. I will check if there is any way to avoid it. Also the patches need to be checked for memory leaks in case of exceptions thrown from constructor and chained function(s). Yes, I already did several tests to check this. It also probably makes sense to add array deference chaining e.g. new Foo()[] (just for language consistency). Hmm, looks good to me. :) Thanks. -- Regards, Felipe Pena
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
my +1 for new major version only, btw :) 2010/11/27 Pierre Joye pierre@gmail.com: +1 if While technically possible this RFC suggests that the following shall NOT be valid for keeping the code readable also means that the patch implements it as well (force the function visibility property usage). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: eyalt
Can someone please approve eyal's account request with the following karma?: php/php-src/*/tests Thanks, Patrick 2010/11/22 Patrick ALLAERT patrickalla...@php.net: Eyal provided already a fair number of contributions/remarks on the php-qa ML. Regards, -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor 2010/11/21 Eyal Teutsch eya...@zend.com: mainly submitting PHPTs fixes. -- 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] RFC: C-sharp style property get/set syntax for PHP
Hi!
Nice RFC, just an idea for an alternative syntax (added to the RFC as #2):
property Hours {
get { return $this-seconds / 3600; }
set { $this-seconds = $value * 3600; } // The variable $value holds
the incoming value to be set
}
class TimePeriod
{
private $seconds;
public [Hours] $hours1;
public {use Hours;} $hours2;
}
If you change property to class or trait and get to __get you
need almost no new syntax :)
--
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: C-sharp style property get/set syntax for PHP
Richard Quadling wrote:
I'd really like this feature to be part of PHP.
I don't particularly like the use of what looks like a closure for the
set/get.
I used to code in Delphi and I always like the way in which their
properties were defined.
Essentially, the setter and getter are normal methods which are cherry
picked for a property [1].
?php
class TimePeriod
{
protected $seconds;
public property Hours read getHours write setHours;
protected function getHours()
{
return $this-seconds / 3600;
}
protected function setHours()
{
$this-seconds = $value * 3600;
}
// This property is read-only
public property Minutes read getMinutes;
protected function getMinutes()
{
return $this-seconds / 60;
}
public property Milliseconds read getMilliseconds write setMilliseconds;
public function getMilliseconds()
{
// This method is public
return $this-seconds * 60;
}
protected function setMilliseconds()
{
// This method is protected
$this-seconds = $value * 3600;
}
}
For me, the advantage here is that I can independently the methods
from the property. If I want to force a subclass to implement a
setter/getter, then I can abstract the function in the base class.
Sure, some may say that I should be using an interface. I disagree as
I probably don't want the methods to be public. Protected or even
private and/or final.
The classic example is one of shapes. Every shape has a public $area
property, but the value would be provided by an abstract protected
TShape::getArea(); method. I can also finalise them, so, for example,
a triangle shape could have a final protected getArea() method and all
sub classes of triangles (scalene, isosceles, equilateral) would not
implement their own getArea() method.
The downside is certainly that the code is more verbose than I would
guess many people would like.
Regards,
Richard.
[1] http://www.delphibasics.co.uk/RTL.asp?Name=Property
setMilliseconds() should have $value as parameter instead of a magic name.
What about allowing this syntax to attach the property to a variable?
For instance:
?php
class TimePeriod
{
protected $seconds;
protected $minutes;
protected $hours;
public property Seconds read $seconds write setSeconds;
public property Minutes read $seconds write setMinutes;
public property Hours read $seconds write setHours;
public function setSeconds($seconds)
{
if ($seconds = 0 $seconds 60) $this-seconds = $seconds;
}
public function setMinutes($minutes)
{
if ($minutes = 0 $minutes 60) $this-minutes = $minutes;
}
public function setHours($hours)
{
if ($hours = 0 $hours 24) $this-hours = $hours;
}
}
We only want to perform checks on write, so instead of writing the trivial
getters, the property is set to the variable itself. Child classes could
reattach it to a function if needing more control.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 2010-11-29, Richard Quadling rquadl...@gmail.com wrote:
On 28 November 2010 23:18, presid...@basnetworks.net wrote:
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
I'd really like this feature to be part of PHP.
I don't particularly like the use of what looks like a closure for the
set/get.
I used to code in Delphi and I always like the way in which their
properties were defined.
Essentially, the setter and getter are normal methods which are cherry
picked for a property [1].
?php
class TimePeriod
{
protected $seconds;
public property Hours read getHours write setHours;
protected function getHours()
{
return $this-seconds / 3600;
}
protected function setHours()
{
$this-seconds = $value * 3600;
}
snip
For me, the advantage here is that I can independently the methods
from the property. If I want to force a subclass to implement a
setter/getter, then I can abstract the function in the base class.
I prefer this as well. It often aids readability to use fluent
interfaces when performing operations that are simply changing state,
and being able to call the setters directly would make that possible:
$time-setHours(3)
-setMinutes(17)
-setSeconds(34);
Additionally, this seems like a very natural fit with traits, making it
possible to really succinctly define behavior to mix in with classes.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 2010-11-29, Stas Malyshev smalys...@sugarcrm.com wrote:
Nice RFC, just an idea for an alternative syntax (added to the RFC as #2):
property Hours {
get { return $this-seconds / 3600; }
set { $this-seconds = $value * 3600; } // The variable $value holds
the incoming value to be set
}
class TimePeriod
{
private $seconds;
public [Hours] $hours1;
public {use Hours;} $hours2;
}
If you change property to class or trait and get to __get you
need almost no new syntax :)
Not really. With __get() and __set(), it's entirely likely that the class into
which the trait is mixed in might override this already -- and not take into
account the properties. That would be quite a brittle solution.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
Care should be taken in the case of new myClass()-foo() just creates an object to call a method but a static method would be more efficient here. However, well used (fluent interface for exemple) make me think +1 for that patch. J.Pauli On Mon, Nov 29, 2010 at 12:40 PM, Felipe Pena felipe...@gmail.com wrote: Hi Dmitry, 2010/11/29 Dmitry Stogov dmi...@zend.com Hi Felipe, I'm wondered it works out of the box with so small patches :) However, both patches introduce new parser conflicts and it would be grate to avoid them. I will check if there is any way to avoid it. Also the patches need to be checked for memory leaks in case of exceptions thrown from constructor and chained function(s). Yes, I already did several tests to check this. It also probably makes sense to add array deference chaining e.g. new Foo()[] (just for language consistency). Hmm, looks good to me. :) Thanks. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi! public property Hours read getHours write setHours; I actually like that, though I think we should support the whole existing semantics, i.e. get/set/isset/unset. And probably keep the names, so we don't call the same thing both read and get. Having them called __get etc. would even remove the need for another keyword, probably, but this looks ugly :( -- 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] Supporting Binary Notation for Integers
On Mon, Nov 15, 2010 at 12:07 PM, Jonah H. Harris jonah.har...@gmail.comwrote: On Fri, Nov 12, 2010 at 12:10 PM, Jonah H. Harris jonah.har...@gmail.comwrote: RFC updated with links to GCC, Python, and Ruby syntax definitions. I just noticed the patch (written against 5.3) doesn't apply cleanly to trunk and will be updating that shortly. In that same vein, I wanted to confirm whether the process for all new functionality is to provide a patch for trunk-only, or trunk+ back-ports? I've posted a replacement of the 5.3 patch with one against trunk. I'm working on a project that seems to consume all of my time, so sorry for the delay. -- Jonah H. Harris Blog: http://www.oracle-internals.com/
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
+1 for next major, but not for middle point release. =) 2010/11/29 Pierre Joye pierre@gmail.com: my +1 for new major version only, btw :) 2010/11/27 Pierre Joye pierre@gmail.com: +1 if While technically possible this RFC suggests that the following shall NOT be valid for keeping the code readable also means that the patch implements it as well (force the function visibility property usage). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Hello - been pointed this way for suggestions - Including.
Been pointed this way by some folks that this is the place to set
suggestions on changes to the functions or language. I have two at the
moment, and that is to the including functions (include, require,
include_once, require_once). They need to be considered separately as they
address two different problems.
Tag Selection at include.
First is the problem of short tags and they aren't being widely used because
of the problems they cause for XML files.
Why not allow the tag type to be chosen at file include? This should bypass
the objections seen in http://wiki.php.net/rfc/shortags
The parameter would be set by a constant.
Val Constant Effect
0PHP_TAGS_INI Use the ini setting. Default.
1PHP_TAGS_STANDARD Use standard PHP tags.
2PHP_TAGS_SHORT Use PHP short tags.
3PHP_TAGS_NONE No tags allowed in file, parse as PHP.
4PHP_TAGS_SCRIPTScript tags script type=php/script
5PHP_TAGS_ASP ASP style tags % %
PHP_TAGS_NONE is suggested as a possible bonus mode this approach allows
that wouldn't be feasible otherwise. In this mode the engine treats the
whole file as PHP and doesn't allow mode switching. This might allow the
engine to parse the file faster. Importantly it would allow framework
designers to enforce that certain files not have HTML in them - such as a
database class, or a custom child class. Admittedly it doesn't stop
echo'ing the html, but it drives home the point to all but the densest that
perhaps this isn't the place to be printing/echoing. It would encounter the
problem of current tools assuming that a PHP file will always have a
starting ?php tag.
The tag method selected affects the file being included only, so tag modes
that are undesirable in some circumstances - short tags - can be segregated
from those circumstance.
Namespace Defined At Include.
This addresses a separate problem from the above, but involves the same
functions - though it might be better to have another rather than a new
parameter on the include statements. The problem is that files always
include to the global namespace, then need to defined their namespace. This
behavior is undesirable with PHP template files and putting a namespace tag
at their start is clumsy at best. Two solutions are proposed - they aren't
exclusive to each other.
Solution 1. Allow Namespace to be declared as file is included.
Hence
include('file.php', __NAMESPACE__);
Would include the code in file.php into the current namespace. If file.php
declares a namespace, then that namespace becomes a sub namespace.
Solution 2. New function to set target namespace.
includeNamespace( __NAMESPACE__ ); // will set current namespace as the
default files include into.
Both could be adopted.
Ok, that's all.
RE: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Mon Nov 29 09:27 AM, Stas Malyshev wrote:
Hi!
Nice RFC, just an idea for an alternative syntax (added to the RFC
as
#2):
property Hours {
get { return $this-seconds / 3600; }
set { $this-seconds = $value * 3600; } // The variable $value
holds
the incoming value to be set
}
class TimePeriod
{
private $seconds;
public [Hours] $hours1;
public {use Hours;} $hours2;
}
If you change property to class or trait and get to __get
you need almost no new syntax :)
Right, it looks the same but the subtle difference is 'property Hours'
wouldn't be registered as a class. It's just container code for get(), set()
methods that would get 'compiled' into opcodes in the class TimePeriod (the
property exists vs. searching for it in runtime). So you can think of it as
a special 'trait' that only applies to properties.
The idea behind this syntax is you can move the 'property' definition out of
the class so that you can test and re-use it somewhere else (like traits).
That might not be problem if you can define properties in traits (needs to
be explained in the RFC):
trait TimeUnits {
public property Seconds
{
get { return $this-seconds; }
set { $this-seconds = $value; }// The variable $value holds the
incoming value to be set
}
public property Minutes
{
get { return $this-seconds / 60; }
set { $this-seconds = $value * 60; }
}
public property Hours
{
get { return $this-seconds / 3600; }
set { $this-seconds = $value * 3600; }// The variable $value holds
the incoming value to be set
}
}
class MyTime {
uses TimeUnits;
protected $_seconds;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 11/29/10 11:51 AM, Jonathan Bond-Caron wrote: Right, it looks the same but the subtle difference is 'property Hours' wouldn't be registered as a class. It's just container code for get(), set() methods that would get 'compiled' into opcodes in the class TimePeriod (the property exists vs. searching for it in runtime). So you can think of it as a special 'trait' that only applies to properties. The idea behind this syntax is you can move the 'property' definition out of the class so that you can test and re-use it somewhere else (like traits). That might not be problem if you can define properties in traits (needs to be explained in the RFC): I think I'd prefer to use Traits for externally-defined properties rather than defining a new top-level construct. It's fewer moving parts and we don't need to figure out how autoloading would be affected. (Autoload would work the same way it does now for traits... whatever that is.) That would then imply we do need to be able to declare the existence of a property and whether it has get, set, or both independently of the definition, just like methods, so that we can have a proper interface/trait split for properties just as for methods. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 11/29/10 8:30 AM, Ángel González wrote:
What about allowing this syntax to attach the property to a variable?
For instance:
?php
class TimePeriod
{
protected $seconds;
protected $minutes;
protected $hours;
public property Seconds read $seconds write setSeconds;
public property Minutes read $seconds write setMinutes;
public property Hours read $seconds write setHours;
public function setSeconds($seconds)
{
if ($seconds= 0 $seconds 60) $this-seconds = $seconds;
}
public function setMinutes($minutes)
{
if ($minutes= 0 $minutes 60) $this-minutes = $minutes;
}
public function setHours($hours)
{
if ($hours= 0 $hours 24) $this-hours = $hours;
}
}
We only want to perform checks on write, so instead of writing the trivial
getters, the property is set to the variable itself. Child classes could
reattach it to a function if needing more control.
Another advantage here would presumably be performance. If there's no
getter defined then the engine could simply map $foo-bar to the class
member directly (which is really fast) and not to a method, so there's
no added overhead there. That still leaves the question of what happens
with name collisions, though.
... and that makes me think that someone is sure to ask about runtime
changes to the property structure sooner or later, as we keep asking
about methods (and *sort of* have figured out with binding closures to
objects, if that did actually get committed), so I'll go ahead and ask
it now. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Mon, 2010-11-29 at 12:18 -0600, la...@garfieldtech.com wrote: Another advantage here would presumably be performance. If there's no getter defined then the engine could simply map $foo-bar to the class member directly (which is really fast) and not to a method, so there's no added overhead there. That still leaves the question of what happens with name collisions, though. Don't kow what you mean by the engine in this case? The compiler? - no the compiler can't a) it has no idea what type $foo is b) think about inheritance etc. The executor - well there's no win possible. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 11/29/10 12:41 PM, Johannes Schlüter wrote: On Mon, 2010-11-29 at 12:18 -0600, la...@garfieldtech.com wrote: Another advantage here would presumably be performance. If there's no getter defined then the engine could simply map $foo-bar to the class member directly (which is really fast) and not to a method, so there's no added overhead there. That still leaves the question of what happens with name collisions, though. Don't kow what you mean by the engine in this case? The compiler? - no the compiler can't a) it has no idea what type $foo is b) think about inheritance etc. The executor - well there's no win possible. johannes I was referring to the compiler I guess. I don't do C so I have no idea what it's capable of. If that's not a possible performance optimization point, then blargh. I still want to keep the performance implications in mind, as this sounds like something that we'd want to use a lot but could also cost a lot more than it seems at first glance if we're not careful. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Mon, 2010-11-29 at 13:40 -0600, la...@garfieldtech.com wrote: I still want to keep the performance implications in mind, as this sounds like something that we'd want to use a lot but could also cost a lot more than it seems at first glance if we're not careful. By making properties in memory a little bigger one might write the accessors in the same table as the actual properties one might possibly reduce the CPU requirement abit. While one has to touch most places dealing with properties internally (while that's probably needed anyways). But well, unless there is an implementation all performance ideas are guesses ... educated guesses at best. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Richard Quadling wrote: As for reading $seconds directly ... Well. If you think of the element that follows read as $this-, then if the parser can handle both ... read $seconds read getSeconds then yes for both. If not, then I'd guess that the getSeconds version should be the one we use as the value may not actually exist without some processing. Richard. If it begins with $, it's a variable name, so map to that class member variable. If it is instead a plain T_STRING, take that as a member call. I'm not sure to be understanding the issue you're mentioning. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi !
This is my first email here (I'm just a PHP user, with only very basic C
skills, but I'm working on it), and I would love to contribute to this project.
I have been working with Objective-c lately, and it has a very flexible and
short way to deal with properties, which could look like this in PHP :
?php
class TimePeriod {
protected $seconds;
protected $minutes;
protected $hours;
@synthesize (readwrite) $hours, $minutes;
@synthesize (readonly) $seconds;
}
NB : I intentionally skipped the @property declaration wich I believe is a
specific need for objc (used to allow dot syntax usage).
In objc, this notation allows to :
- use dot syntax for accessing properties (using their getters/setters only,
all properties are protected in objc)
- write your own getters/setters (only the missing ones are generated)
In Php, the pros of this syntax would be :
- very concise
- no interference with existing code (except certain conditions)
- allows to override generated getters and setters with custom code
- may work with the existing code base
The cons :
- new syntax to learn (even if it is quite simple)
- need to use pre-determined setters and getters names to keep simplicity,
which could potentially lead to BC break in some (hopefully rare) cases.
What do you think about it ?
Regards,
Benjamin
Le 29 nov. 2010 à 17:10, Richard Quadling a écrit :
2010/11/29 Ángel González keis...@gmail.com:
Richard Quadling wrote:
setMilliseconds() should have $value as parameter instead of a magic name.
What about allowing this syntax to attach the property to a variable?
For instance:
?php
class TimePeriod
{
protected $seconds;
protected $minutes;
protected $hours;
public property Seconds read $seconds write setSeconds;
public property Minutes read $seconds write setMinutes;
public property Hours read $seconds write setHours;
public function setSeconds($seconds)
{
if ($seconds = 0 $seconds 60) $this-seconds = $seconds;
}
public function setMinutes($minutes)
{
if ($minutes = 0 $minutes 60) $this-minutes = $minutes;
}
public function setHours($hours)
{
if ($hours = 0 $hours 24) $this-hours = $hours;
}
}
We only want to perform checks on write, so instead of writing the trivial
getters, the property is set to the variable itself. Child classes could
reattach it to a function if needing more control.
Ouch. I messed up on the example code. Completely forget that there
was a parameter to process...
As for reading $seconds directly ...
Well.
If you think of the element that follows read as $this-, then if
the parser can handle both ...
read $seconds
read getSeconds
then yes for both.
If not, then I'd guess that the getSeconds version should be the one
we use as the value may not actually exist without some processing.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
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] [RFC] new foo()-bar()
2010/11/29 Felipe Pena felipe...@gmail.com
It also probably makes sense to add array deference chaining e.g. new
Foo()[] (just for language consistency).
Hmm, looks good to me. :)
I've updated the patch with the bracketed version to include the array
dereferecing support:
http://felipe.ath.cx/diff/instance-method-call-3.patch
?php
class foo extends ArrayObject {
public function __construct($arr) {
parent::__construct($arr);
}
}
$arr = array(1, 2, 3);
$value = (new foo($arr))[1]; // int(2)
?
Some tests: http://felipe.ath.cx/diff/instance_direct_access_001.phpt
--
Regards,
Felipe Pena
