2010/11/29 Felipe Pena
> 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/
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
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 shoul
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 m
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
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 a
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:
= 0&& $seconds< 60) $this->seconds = $seconds;
}
public function setMinutes($minutes)
{
if ($minutes>= 0&& $minutes< 60) $this->minutes =
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. sea
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 i
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
+1 for next major, but not for middle point release. =)
2010/11/29 Pierre Joye :
> my +1 for new major version only, btw :)
>
> 2010/11/27 Pierre Joye :
>> +1 if "While technically possible this RFC suggests that the following
>> shall NOT be valid for keeping the code readable " also means that t
On Mon, Nov 15, 2010 at 12:07 PM, Jonah H. Harris wrote:
> On Fri, Nov 12, 2010 at 12:10 PM, Jonah H. Harris
> wrote:
>
>> 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 updatin
2010/11/29 Ángel González :
> 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:
>
> class TimePeriod
> {
> protected $seconds;
> protected $minutes;
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. woul
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 wrote:
> Hi
On 2010-11-29, Stas Malyshev 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"
On 2010-11-29, Richard Quadling wrote:
> On 28 November 2010 23:18, 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 clos
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 ar
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;
On Sun Nov 28 06:18 PM, presid...@basnetworks.net wrote:
>
> Link to the RFC:
> http://wiki.php.net/rfc/propertygetsetsyntax
>
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 =
Can someone please approve eyal's account request with the following karma?:
php/php-src/*/tests
Thanks,
Patrick
2010/11/22 Patrick ALLAERT :
> Eyal provided already a fair number of contributions/remarks on the php-qa ML.
>
> Regards,
> --
> Patrick Allaert
> ---
> http://code.google.com/p/pecla
my +1 for new major version only, btw :)
2010/11/27 Pierre Joye :
> +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).
Cheer
Hi Dmitry,
2010/11/29 Dmitry Stogov
> 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 ch
On 28 November 2010 23:18, 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 alway
David Soria Parra wrote:
On 2010-11-29, Clint Byrum 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, b
On Sun, Nov 28, 2010 at 11:48 PM, Christian Kaps
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;
> }
>
> G
On 2010-11-29, Clint Byrum 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
27 matches
Mail list logo
