I've updated the RFC to include details on adding isset/unset as well as
references, detailed below:
isset/unset:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
isset { return
-Original Message-
From: patrick.alla...@gmail.com [mailto:patrick.alla...@gmail.com] On Behalf Of
Patrick ALLAERT
Sent: Friday, April 20, 2012 5:36 AM
To: Stas Malyshev
Cc: Clint M Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax
2012/4/20 Stas Malyshev smalys
How these would work with isset - what !empty($this-Hours) return? What
would happen if you do unset($this-Hours)? What happens if you do
$this-Hours++ or sort($this-Hours) (assuming $Hours is an array)?
These things need to be defined in the RFC too.
So I've just tested these things and
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Saturday, April 21, 2012 10:33 PM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax
Hi!
empty() - Returns true for a property retrieved via __get
I like this idea quite a bit, it would allow for more rapid deprecation of
outdated ideas. Wouldn't this require multiple interpreters though? Might add
a lot of complexity to the code as well, possibly not.
-Original Message-
From: Rasmus Schultz [mailto:ras...@mindplay.dk]
Sent:
The only open comments I have on this project is the read-only and
write-only keywords.
Are the dashes acceptable or undesirable?
write-only was not in the original RFC but made sense to have the alternate to
read-only, any objections?
If there is no other discussion for this, I'd like to
The patches are applied to this fork if anyone wants to check it out:
https://github.com/cpriest/php-src
-Original Message-
From: Clint M Priest [mailto:cpri...@zerocue.com]
Sent: Thursday, March 29, 2012 8:14 PM
To: internals@lists.php.net
Subject: RE: [PHP-DEV] (*PATCH*) getters
...@oracle.com]
Sent: Thursday, March 29, 2012 1:14 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] (*PATCH*) getters/setters Implementation
On 03/28/2012 08:13 PM, Clint M Priest wrote:
What are the next steps to get this added to some future release?
Attached is a patch against ~/trunk
I haven't seen any other yeah/neigh comments about these changes, does everyone
agree with them?
-Original Message-
From: Clint M Priest [mailto:cpri...@zerocue.com]
Sent: Thursday, March 22, 2012 2:00 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Accessors v2.4 Proposed Changes
this slated for the next stage, presumably to be put into the
core... What are the next steps?
Thanks,
-Clint
From: Rasmus Schultz [mailto:ras...@mindplay.dk]
Sent: Saturday, February 04, 2012 2:34 PM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: internals Digest 4 Feb 2012
I'd be willing to be a mentor.
-Original Message-
From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf Of Adam
Harvey
Sent: Thursday, March 01, 2012 8:00 PM
To: PHP internals
Subject: [PHP-DEV] Google Summer of Code
Hi all,
Google are running the Summer of Code again
As much as I would love to have __castTo() and __assign() I have to agree with
Stas here that it fundamentally changes the mechanics of if($object) and
unfortunately turns that simple if statement into a possible hour long hunt to
find the code that is doing the damage, if it is even considered
I definitely like the idea of being able to cast objects, I've frequently
wished to be able to cast an object to an array. I would argue against the
single __castTo() and __castFrom() magic methods as large switches get to be
difficult to find/read and doesn't support separation.
I would
+1 for that as well.
-Original Message-
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Sunday, February 26, 2012 7:48 PM
To: John Crenshaw
Cc: Arvids Godjuks; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)
Well said, John! I think that's a
I've used etrace: http://ndevilla.free.fr/etrace/ with php recently, works
nicely. Produces output like:
main
| Crumble_make_apple_crumble
| | Crumble_buy_stuff
| | | Crumble_buy
| | | Crumble_buy (total: 5 times)
| | Crumble_prepare_apples
reflection to access a
backing-field without invoking the
accessor-methods.
Looks nice otherwise! :-)
- Rasmus
2012/2/4 internals-digest-h...@lists.php.net
From: Clint M Priest cpri...@zerocue.com
To: internals@lists.php.net internals@lists.php.net
Cc:
Date: Fri, 3 Feb 2012 13:47:53 +
Can I get access to update the status of bugs? I've gone through a few recent
ones and tested, some are bogus and I'm just adding comments but can close them
if I had access.
https://bugs.php.net/bug.php?id=60940
For example.
to in any way.
-Original Message-
From: Sebastian Krebs [mailto:krebs@googlemail.com]
Sent: Saturday, February 04, 2012 12:21 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 - Issue 2549
Hi,
Am 04.02.2012 19:13, schrieb Clint M Priest
https://bugs.php.net/bug.php?id=60833 seems like a change that nobody should
have a problem with and has a patch file attached, can someone commit this and
close the request?
Could someone review and include?
https://bugs.php.net/bug.php?id=60978
-Clint
The property accessor functionality is done and is detailed here:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Core Patch: http://www.clintpriest.com/patches/php-core/accessors/2.4.diff
The core patch encompasses the entire original RFC and the as-implemented
includes
Okay, that's been removed from the patch. :)
From: John LeSueur [mailto:john.lesu...@gmail.com]
Sent: Friday, February 03, 2012 7:54 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PATCH] Property Getters/Setters (v2.4) for review
Because Zend/zend_language_scanner.c
Type Hinting was not in the original RFC, is type hinting stable enough to be
included with the Property Accessors functionality or is there no clear
agreement made with them yet?
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented?#read-only_and_write-only_properties
Could be:
?php
That's exactly what it's used for.
-Original Message-
From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of jpauli
Sent: Monday, January 30, 2012 10:27 AM
To: Adi Mutu
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] zend guard
Quickly reading the source and trying
Kovacs [mailto:tyr...@gmail.com]
Sent: Saturday, January 28, 2012 4:00 PM
To: Stas Malyshev
Cc: Rasmus Lerdorf; Clint M Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] Uploading a patch fails...
BTW, I would recommend using Wiki and RFC for tracking new features,
especially
I'm trying to upload the latest getters/setters patch to:
https://bugs.php.net/bug.php?id=49526
I get Uploaded file is empty or nothing was uploaded.
Is there a problem or a file size limit? The patch file is 205k now.
-Clint
I've never gotten -d in shebang to work properly, I'd love to see that working.
-Original Message-
From: Ángel González [mailto:keis...@gmail.com]
Sent: Wednesday, January 25, 2012 6:00 PM
To: Robert Eisele
Cc: PHP internals
Subject: Re: [PHP-DEV] Shebang parsing
On 26/01/12 00:22,
Your code example below (with an appropriate getter written) would become:
$foo-__setBar('a')-doSomething() and would work if you return $this at the
end of each of your setters.
-Original Message-
From: Christoph Rosse [mailto:c...@okto.tv]
Sent: Monday, January 23, 2012 2:11 AM
To:
I'm trying to finish up some more difficult pieces of the getter/setter rfc.
Is there any documentation on the compiler anywhere? Any possible disassembler
to see the op-codes in an assembly type of view?
Specifically I'm working on parent::$xxx access of parent getter/setter from
within a
Just updated and tried to compile, getting this:
make: *** No rule to make target
`/opt/php-core/trunk-accessor/ext/hash/hash_salsa.c', needed by
`ext/hash/hash_salsa.lo'. Stop.
I see that commit 322421 removed the hash_salsa.c but perhaps the Makefile
didn't get updated? Anyone else seeing
Looks like wiki.php.net is down... I'm getting an nginx gateway timeout.
That syntax is pretty readable, would there be alternatives such as:
function foo() returns Class3, array or null {
}
-Original Message-
From: Dmitri Snytkine [mailto:dsnytk...@ultralogistics.com]
Sent: Friday, December 23, 2011 7:48 AM
To: 'Ángel González'; 'PHP Developers Mailing
: Will Fitch [mailto:will.fi...@gmail.com]
Sent: Monday, December 12, 2011 5:22 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Accessors v2.2 Patch
Clint,
How about
final public $Hours {}
That would allow for the read only and limit the inheritance.
Sent from my iPhone
[mailto:guilhermebla...@gmail.com]
Sent: Sunday, December 11, 2011 10:35 PM
To: Will Fitch
Cc: Clint M Priest; Pierre Joye; internals@lists.php.net
Subject: Re: [PHP-DEV] Accessors v2 Patch
hi Will,
That's what I've been thinking about.
I have a special necessity to overload a class in a Proxy
Why perpetuate the problem though? I'd tend to think 3 would be the best
solution.
-Original Message-
From: Johannes Schlüter [mailto:johan...@schlueters.de]
Sent: Monday, December 12, 2011 6:52 PM
To: Clint M Priest
Cc: Pierre Joye; internals@lists.php.net
Subject: RE: [PHP-DEV
https://bugs.php.net/patch-display.php?bug_id=49526patch=accessor_v2.diffrevision=latest
I rewrote part of how it handles the job due to abysmal performance of version
1. This one is near the same performance as without the code changes using
__get() and is actually faster in some cases
PM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Accessors v2 Patch
Much better implementation.
As for the failed tests, I would double check and make sure you don't have any
stray debug statements (e.g. printf).
Sent from my iPhone
On Dec 11, 2011, at 2:27 PM, Clint M
There are already two tests against private read and private write, should I
add two for protected as well?
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Sunday, December 11, 2011 6:36 PM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Accessors v2 Patch
oh right, I missed them. Yes, so it is covered as well :)
On Mon, Dec 12, 2011 at 1:42 AM, Clint M Priest cpri...@zerocue.com wrote:
There are already two tests against private read and private write, should I
https://bugs.php.net/patch-display.php?bug=49526patch=v2.2revision=1323662103
This one addresses the read-only, write-only aspects. Though they are not
quite what the RFC specifies...
class TimePeriod {
public $Hours {
get { return 5; }
}
}
$o = new TimePeriod();
$o-Hours = 4;
I've got 122 tests that are failing on a full run, if I write the failed tests
to a file and re-run just those tests, all of them pass. Any ideas whats up?
Ahh, I'm just doing ./run-tests.php with parameters, I'll see what a make test
does.
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Saturday, December 10, 2011 1:15 PM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Failing Tests
hi
I prefer C# syntax myself but thinking about it, supporting both syntax's would
be fairly trivial to add... Thoughts on that?
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Tuesday, December 06, 2011 5:47 AM
To: Clint M Priest
Cc: Rasmus Schultz; internals
/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
functions that may already be available in
some other form I was not aware of, such as strcatalloc or MAKE_ZNODE().
--Clint
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Sunday, December 04, 2011 4:50 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject
for storing two additional pointers for every class
property?
-Clint
-Original Message-
From: Felipe Pena [mailto:felipe...@gmail.com]
Sent: Sunday, December 04, 2011 10:05 AM
To: Clint M Priest
Cc: Pierre Joye; internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters
Per RFC: https://wiki.php.net/rfc/propertygetsetsyntax
Alright, getters/setters has been built. This is my first patch to the php
core. Here is what has been implemented:
http://www.clintpriest.com/patches/accessors_v1.patch (patch against trunk)
Asymmetrical getters/setters syntax:
Trying implement empty getter/setter syntax such as:
public $Hours {
get;
set;
}
Is there any way to inject code into the compile process?
I'm trying via (just some proof of concept code, ignore the buffer overrun
potential)
char
I've implemented a good majority of the getter/setter syntax for objects which
was pretty easy due to the already implemented functionality of __get()/__set().
For static getters/setters there is no such obvious place to hook the new
functionality, I was considering modifying the ZEND_ASSIGN
That would be a resounding no from everyone. :)
-Original Message-
From: Hannes Magnusson [mailto:hannes.magnus...@gmail.com]
Sent: Friday, November 18, 2011 8:16 PM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Multiple Visibility Level Getters/Setters
On Sat
Is there any reason I would have to free a pointer from the language_parser if
I am just storing a reference to $1
I'm doing this:
CG(accessor_node) = $1;
And in doing so it is causing a memory leak, only if I add:
efree($1.u.constant.value.str.val);
Does that memory leak go away.
-Clint
What would everyone think about multiple levels of visibility for
getters/setters?
class Sample {
public $Variable {
public get { return Public; }
protected get { return Protected; }
private get { return Private; }
public set {
The RFC here: https://wiki.php.net/rfc/propertygetsetsyntax
Talks about allowing a sub-class to access a parent getter via
TimePeriod::$Milliseconds or possibly parent::$Milliseconds.
Either of those methods (currently) tries to access a static property in the
parent or defined class. It
Working to implement Getter/Setter Accessor syntax as per
https://wiki.php.net/rfc/propertygetsetsyntax but brand new to php internals
development.
I was planning on having the parser define methods on the class for the
getter/setter such as __getHours() and __setHours() and then have those
’ on the zend_do_abstract_method())
From: Александр Москалёв [mailto:ir...@irker.net]
Sent: Tuesday, November 08, 2011 2:04 PM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Accessors Parsing
2011/11/8 Clint M Priest cpri...@zerocue.commailto:cpri...@zerocue.com
echo $o-Hours().\r\n;
Why use
I didn't change the zend_language_scanner.l, attached is the (.txt) diff that I
had at the original time of writing, I'll give that a try.
I am planning to go by the RFC mentioned below, I've already been emailing with
that original author who tells me most of the feedback he received during
I'm sure the problem is that I hadn't modified the .l file as Nikita suggested,
which I have now done but the build doesn't seem to be affected by changes to
that file so I'm trying to find out how to make that occur. I believe it's via
re2c which I have installed but a make clean/make still
57 matches
Mail list logo
