a couple of convenience 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@l
emory footprint 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:
/setters syntax Implementation
2011/12/4 Clint M Priest :
> 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 loo
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; inte
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
https://bugs.php.net/patch-display.php?bug_id=49526&patch=accessor_v2.diff&revision=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 (publ
Sunday, December 11, 2011 1:41 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
O
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 wrote:
> There are already two tests against private read and private write, should I
> add t
https://bugs.php.net/patch-display.php?bug=49526&patch=v2.2&revision=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;
From: 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 i
[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
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: [PH
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 List
Looks like wiki.php.net is down... I'm getting an nginx gateway timeout.
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
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 get
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'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, Rober
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
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,
> especiall
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 thi
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:
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 implementa
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
seems to be a design goal, it would
> probably make more sense if you had to use reflection to access a
> backing-field without invoking the
> accessor-methods.
> Looks nice otherwise! :-)
> - Rasmus
2012/2/4
> From: Clint M Priest
> To: "internals@lists.php.net&
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.
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
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
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 prefe
+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 terrifi
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'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 this
o get 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
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 Ch
r Jones [mailto:christopher.jo...@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 releas
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
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: Wed
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 t
as parent::?
-Clint
-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
201
> 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
> -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() - Retu
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 !is
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 its
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 re
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
fu
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 mailto:cpri...@zerocue.com>>
echo $o->Hours()."\r\n";
Why
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 would
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
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 opc
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 injected
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:
pu
57 matches
Mail list logo
