[PHP-DEV] RFC: Property get/set syntax (added isset/unset and references)
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_null($this-Seconds); }
unset { $this-Seconds = NULL; }
}
}
References:
class SampleClass {
private $_dataArray = array(1,2,5,3);
public $dataArray {
get { return $this-_dataArray; }
}
}
$o = new SampleClass();
sort($o-dataArray);
/* $o-dataArray == array(1,2,3,5); */
Comments?
These would also include automatic implementations which call the respective
functions on the backing field. I could see only allowing isset/unset
automatic implementations if get/set were also specified as automatic
implementations.
Default implementations of isset/unset
I'm also fielding comments/ideas on a way to always provide automatic
implementations of isset/unset for any accessor that didn't define one
automatically. One idea was for the isset (unspecified implementation) which
would return true if the getter provided any value which evaluated to true,
such as this:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
}
}
/* Default Implementation Concept */
isset { return (int)$this-Hours; }
unset { $this-Hours = NULL; }
Note that the automatic implementation of unset is not strictly the same as an
unset() but without any sort of unset implementation a call to unset() would do
nothing. Alternatively we could throw an error to a call on isset and/or unset
against a property which didn't define an implementation.
Thoughts?
-Clint
RE: [PHP-DEV] RFC: Property get/set syntax
isset/unset property hooks
I could definitely see having the isset and unset hooks as well, anyone
disagree with that? I would expect them to syntactically show up as such:
public $Hours {
get { ... }
set { ... }
isset { return true; /* returns bool */ }
unset { unset(...); /* returns void */ }
}
Thoughts?
Operators
I've tested with a number of the operators and they are all working as
expected. I have updated the RFC to reflect that. I will also write tests for
reference access as well as with some functions such as sort(), is_*(), empty()
and some others.
Other suggestions on functions we should write tests for?
read-only/write-only
There are people on both sides of the fence, where do I go from here, put it up
for a specific vote?
parent∷ scope access
For the parent::$Milliseconds comment by Stanislav. This was in the original
RFC and I think it fits well since it's the same syntax that would be used in a
function to access a parent function, such as function a() { /* ... */ return
parent::a(); } Though I have not used the parent::$xxx to access static values
myself I know it's possible. Right now using parent:: format would first look
for a parent accessor, then a parent static accessor, then would follow normal
functionality, to access a parent static reference. I've documented this in
the RFC under Overloading Properties now.
What other format/keyword would make as much sense 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
2012/4/20 Stas Malyshev smalys...@sugarcrm.commailto:smalys...@sugarcrm.com:
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.
My suggestion is to support the same methods for properties as we do for magic
class methods: __set, __get, __isset and __unset.
All the other operations (sort, ++, ,...) should behave exactly as if it was
be implemented with current magic class methods with a usual switch/case
statement.
RE: [PHP-DEV] RFC: Property get/set syntax
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 the accessors perform the same way as with __get()/__set(). empty() - Returns true for a property retrieved via __get() or via a getter -- Any idea why this would be the case for __get()? Is this a bug? unset() - Would unset a temporary variable (the one returned by the getter) -- see previous email re: adding unset/isset property functions. sort() - Does the same thing as with __get()/__set() which is to say, the array is sorted but the property is not updated with the value. Should accessor behave differently than the magic methods? Should this just be documents or should this be fixed? -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Property get/set syntax
-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() or via a
getter -- Any idea why this would be the case for __get()? Is this a
bug?
isset() calls __isset(), empty() calls __isset() and __get(). I'm not sure
what exactly you consider to be a bug.
I see, well the only way to resolve this would be to add isset and unset
property functions as well.
Anyone against it?
unset() - Would unset a temporary variable (the one returned by the
getter) -- see previous email re: adding unset/isset property
functions.
unset() calls __unset().
sort() - Does the same thing as with __get()/__set() which is to say,
the array is sorted but the property is not updated with the value.
Should accessor behave differently than the magic methods? Should
this just be documents or should this be fixed?
sort() works just fine if you define __get to return by-ref.
Returning by reference was not documented in the original RFC, would this
syntax work for everyone?
public $Hours {
get { return $this-a; }
}
--
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] Re: internals Digest 18 Apr 2012 20:34:27 -0000 Issue 2671
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: Wednesday, April 18, 2012 9:42 PM To: internals@lists.php.net Subject: [PHP-DEV] Re: internals Digest 18 Apr 2012 20:34:27 - Issue 2671 On 04/10/2012 06:20 PM, Adir Kuhn wrote: PHP Gotchas, how they came to be, and why we can't simply fix them can't or won't? It seems that the requirement for backward compatibility, as with most software, stands in the way of any substantial leaps, and makes it impossible to do away with outdated cruft. As a result, PHP is dragging around a lot of baggage - both the language itself and the libraries. Hey, here's a crazy thought: ?php6 Now you don't have to be backward compatible - the bytecode needs to remain compatible with bytecode generated by standard ?php tags of course, but you're free to change/improve/deprecate/extend the syntax, update inconsistent APIs, etc. I know this is no small thing, heh. I'm sure there's some technical reason this isn't even feasible or possible... I just figured I'd bring it up anyway, it's always fun to see your reactions to such radical ideas - bring on the flames! ;-) -- 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
[PHP-DEV] RFC: Property get/set syntax
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 move this to the voting phase, any objects? https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented -Clint
RE: [PHP-DEV] (*PATCH*) getters/setters Implementation
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/setters Implementation Thanks for the feedback, I'll take care of some of these. What did you mean about the out of sync regarding naming? With the unexpected values to the methods I'm not sure what you mean, there are no 'expected values' to be passed. For the auto-backed properties it would be assigned to whatever value was being passed, null or whatever. For the non auto-backed properties it would depend on the user-supplied getter/setter implementation. Am I missing something here? Regarding the open questions on read-only/write-only I don't think they are strictly necessary any longer. The original RFC had them for enforcing a value to be read only but it would be equivalent of setting an accessor with just a getter and final although it would allow for it to be over-ridden. Are the read-only/write-only tags desired? I think the test cases that are present are complete, I could not think of any further tests to write or I would have written them, any suggestions? I'll update the RFC with backward compatibility comments though I believe there are none, anyone else see any backward compatibility issues? -Original Message- From: Christopher 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 release? Attached is a patch against ~/trunk A couple of brief comments from the sidelines without having followed previous discussion in detail: - The RFC appears to have open questions e.g about the need for readonly etc keywords - The tests and RFC are out of sync regarding naming, e.g. readonly vs read-only - The RFC makes no mention of backward compatibility issues - Did I miss seeing tests that pass in unexpected values to the methods? - I would expect a larger number of tests overall when the feature is merged/completed. - If these are indeed magic methods they need __ prefixes, so consider the names __getter and __setter - I'd suggest biting the github bullet and creating your own PHP fork with your patches. People will be able to test and you might get more feedback. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] (*PATCH*) getters/setters Implementation
Thanks for the feedback, I'll take care of some of these. What did you mean about the out of sync regarding naming? With the unexpected values to the methods I'm not sure what you mean, there are no 'expected values' to be passed. For the auto-backed properties it would be assigned to whatever value was being passed, null or whatever. For the non auto-backed properties it would depend on the user-supplied getter/setter implementation. Am I missing something here? Regarding the open questions on read-only/write-only I don't think they are strictly necessary any longer. The original RFC had them for enforcing a value to be read only but it would be equivalent of setting an accessor with just a getter and final although it would allow for it to be over-ridden. Are the read-only/write-only tags desired? I think the test cases that are present are complete, I could not think of any further tests to write or I would have written them, any suggestions? I'll update the RFC with backward compatibility comments though I believe there are none, anyone else see any backward compatibility issues? -Original Message- From: Christopher 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 release? Attached is a patch against ~/trunk A couple of brief comments from the sidelines without having followed previous discussion in detail: - The RFC appears to have open questions e.g about the need for readonly etc keywords - The tests and RFC are out of sync regarding naming, e.g. readonly vs read-only - The RFC makes no mention of backward compatibility issues - Did I miss seeing tests that pass in unexpected values to the methods? - I would expect a larger number of tests overall when the feature is merged/completed. - If these are indeed magic methods they need __ prefixes, so consider the names __getter and __setter - I'd suggest biting the github bullet and creating your own PHP fork with your patches. People will be able to test and you might get more feedback. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- 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
[PHP-DEV] RE: Accessors v2.4 Proposed Changes
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 I've been away from this for a while and getting back to it now... Wanted to open discussion back up on these two points that Rasmus and Tom had: 1) Accessor should over-ride the __get()/__set(). If an accessor is set for a property, it would be ineligible for calling __get/__set, anyone disagree? 2) Automatic backing fields should be protected and not public Does anyone else have any comments about this RFC (as-implemented)? https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented http://www.clintpriest.com/patches/php-core/accessors/2.4.diff I'd like to 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 4 Feb 2012 09:08:29 - Issue 2549 On Sat, Feb 4, 2012 at 1:13 PM, Clint M Priest cpri...@zerocue.commailto:cpri...@zerocue.com wrote: The read-only and write-only keywords act a little differently. Without them, attempting a set on an accessor without a setter defined will cause __set() to be called whereas with the read-only it will produce an error. The inverse is true for write-only. I attempted to keep the ability to have lazy initializing of properties via accessors, but that could be written in php slightly differently if the read-only/write-only keywords were not present (due to guards). Doesn't particularly matter to me. I'm hard pressed to think of a real use-case for something like that - seems like this could easily cause confusion, having the getter invoke one mechanism, and the setter an entirely different mechanism. In my opinion, if you declare an accessor (whether get, set, or both) the accessor-mechanism should take over and replace the magic methods. In the case of a read-only or write-only accessor, I'd expect an exception, not a magic method as a secondary fall-back mechanism. Accessor-methods aren't magic, they're concrete properties that execute code when you use them. Accessors give you more compartmentalization than __get() and __set() which work for wild property-names - e.g. in situations where you don't know at design-time whether a property exists; but with accessors, you're defining concrete property-names, so there is no need for magic. In my opinion. And then there's the matter of actually explaining the read-only and write-only keywords to programmers, and the difference in behavior. This would be easier to explain, if the difference wasn't almost a different language-behavior. Normally, public $foo prevents both __get() and __set() being invoked for the $object-foo property - that's been a given for a long time, and it's a mechanism that is easy to explain and easy to understand. While you could certainly explain how this works, and I personally understood your explanation, as said, it's very hard for me to think of a real use-case - so while you can make it understood how this works, technically, it's unlikely that you, as a programmer, will ever actually care or fully understand the differences until someday you run into it. It's less likely to be something you look for to solve a particular problem - which means it's more likely to get in the way. Just my opinion :-) Would it not be more correct to implement an auto-backing field as protected? The reason for implementing accessors in the first place, is usually to prevent direct access to an underlying field. Makes sense, in C# these backing fields are completely inaccessible directly, would that be even better in this case or would protected suffice? There are definitely situations (such as ORM) where you may need access to the backing-field... It's a common requirement when, for example, the set-accessor has side-effects. A dirty-flag, timestamp or version-number, for example - you don't want those invoked when the ORM hydrates an object with database-values. There are also cases when backing-fields get initialized at construction - when a class extends another class, the enhanced constructor might need direct access to the backing-field. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Accessors v2.4 Proposed Changes
I've been away from this for a while and getting back to it now... Wanted to open discussion back up on these two points that Rasmus and Tom had: 1) Accessor should over-ride the __get()/__set(). If an accessor is set for a property, it would be ineligible for calling __get/__set, anyone disagree? 2) Automatic backing fields should be protected and not public Does anyone else have any comments about this RFC (as-implemented)? https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented http://www.clintpriest.com/patches/php-core/accessors/2.4.diff I'd like to 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 4 Feb 2012 09:08:29 - Issue 2549 On Sat, Feb 4, 2012 at 1:13 PM, Clint M Priest cpri...@zerocue.commailto:cpri...@zerocue.com wrote: The read-only and write-only keywords act a little differently. Without them, attempting a set on an accessor without a setter defined will cause __set() to be called whereas with the read-only it will produce an error. The inverse is true for write-only. I attempted to keep the ability to have lazy initializing of properties via accessors, but that could be written in php slightly differently if the read-only/write-only keywords were not present (due to guards). Doesn't particularly matter to me. I'm hard pressed to think of a real use-case for something like that - seems like this could easily cause confusion, having the getter invoke one mechanism, and the setter an entirely different mechanism. In my opinion, if you declare an accessor (whether get, set, or both) the accessor-mechanism should take over and replace the magic methods. In the case of a read-only or write-only accessor, I'd expect an exception, not a magic method as a secondary fall-back mechanism. Accessor-methods aren't magic, they're concrete properties that execute code when you use them. Accessors give you more compartmentalization than __get() and __set() which work for wild property-names - e.g. in situations where you don't know at design-time whether a property exists; but with accessors, you're defining concrete property-names, so there is no need for magic. In my opinion. And then there's the matter of actually explaining the read-only and write-only keywords to programmers, and the difference in behavior. This would be easier to explain, if the difference wasn't almost a different language-behavior. Normally, public $foo prevents both __get() and __set() being invoked for the $object-foo property - that's been a given for a long time, and it's a mechanism that is easy to explain and easy to understand. While you could certainly explain how this works, and I personally understood your explanation, as said, it's very hard for me to think of a real use-case - so while you can make it understood how this works, technically, it's unlikely that you, as a programmer, will ever actually care or fully understand the differences until someday you run into it. It's less likely to be something you look for to solve a particular problem - which means it's more likely to get in the way. Just my opinion :-) Would it not be more correct to implement an auto-backing field as protected? The reason for implementing accessors in the first place, is usually to prevent direct access to an underlying field. Makes sense, in C# these backing fields are completely inaccessible directly, would that be even better in this case or would protected suffice? There are definitely situations (such as ORM) where you may need access to the backing-field... It's a common requirement when, for example, the set-accessor has side-effects. A dirty-flag, timestamp or version-number, for example - you don't want those invoked when the ORM hydrates an object with database-values. There are also cases when backing-fields get initialized at construction - when a class extends another class, the enhanced constructor might need direct access to the backing-field.
RE: [PHP-DEV] Google Summer of Code
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 year, and Dan Brown and I have tentatively agreed to act as organisation administrators if we can get an application together. We have a week from today to apply, but before we can, we need updated ideas. Our old ideas list is at https://wiki.php.net/ideas — if we can get this cleaned up and updated, then I can turn it into a single ideas page for our application. Here's a summary of what's there at the moment, the suggested mentors (if your name is on this list, an indication of whether the idea is still valid and whether you'd still be interested in mentoring would be appreciated), and any thoughts I have on whether they're still viable ideas. Updates welcome — new ideas very very welcome. - Automatic Code Checker (suggested mentor: Nuno Lopes): still sounds like a good idea to me. - Bugs Update (Philip Olson): this seems really thin for a whole project. Are there other improvements currently pending that could turn this into a broader refresh of the bug tracker? - PHP/PECL Build Bot (Elizabeth Smith): sounds good, if we can get hardware to support it. - Zend Bytecode to LLVM Converter (Nuno Lopes): sounds good. - Abstract Extension API and Dependency Interface (Brian Shire, Andrei Zmievski): sounds good. - CGI/FastCGI SAPI Improvement (Dmitry Stogov): pretty sure the merge of FPM has made this moot. - Get Involved - Writing it (Philip Olson): I think the GSoC prohibition on documentation projects would prevent this. - PHP-GTK documentation (no mentor): as above. - Integrated Code Coverage of C and PHP Code (Sebastian Bergmann): sounds good. - Patch Server (no mentor): could this link in with the Build Bot project above? - PHP Authentication System (??): this is three years old — may still be relevant, but the page itself would need a serious update. - New Mirror Management System (Daniel Brown): not sure if this is relevant — systems guys? Daniel? - php.net search improvements (??): sounds good. - PHP.net search SQLite wrapper (??): probably should be rolled into the previous project. - run-tests.php improvements (Zoe Slattery, Stefan Priebsch): sounds good; I'd be prepared to mentor this if we needed to find a new mentor, having just done a bit of exploratory work on this myself of late. - Revamping user comments at php.net (Philip Olson): might also be a bit thin as written, but it depends on where it goes. Remember, we're not limited to ideas on our ideas page (students can also suggest ideas, and often do), but having a strong ideas page will greatly enhance our chances of being accepted, particularly in light of having missed the last couple of GSoCs. As I said, both updates to the existing list and new ideas would be very welcome, either here or on the aforementioned Wiki page. Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
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 a possibility
by someone reading the code.
For the record, I really have only ever needed something like __toArray() so
that objects implementing ArrayAccess could be passed to array internal
functions.
I am interested in object natives though, which this is leading in the
direction of.
-Clint
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Wednesday, February 29, 2012 1:48 AM
To: Anthony Ferrara
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
Hi!
Hey all,
I've created a draft version of the RFC for implementing __castTo()
and __assign():
https://wiki.php.net/rfc/object_cast_magic
I think having cast method may have merits, though use cases where objects need
to be converted to scalars that aren't string are very limited, and cases where
they need to do so transparently are almost non-existent. I think what outlined
in the RFC is a backdoor operator overloading, through rather complex and
unobvious magic. My opinion is that outside of very limited number of cases
(such as implementing complex numbers or matrix algebra - and how frequently
would one need do that in PHP anyway?) operator overloading is way more trouble
than it's worth and makes code nearly unreadable as you never know what exactly
each operator does. For example, if($object) would have completely different
semantics than before, for some objects but not other, and without any obvious
clue to the user what it actually does - and all that to save couple of
keystrokes on if($object-valid())?
Still, if there's a valid use case found, cast magic method and unboxing
method may have merit. So far the cases outlined seem either too artificial and
narrow for language-level functionality, or plain wrong (like SplFixedArray
example - nothing in this proposal would enable it to work with sort, for
example). But I do not exclude other cases can exist.
However, assignment overloading does not seem viable to me.
Also, I'm not sure how this is possible technically: $obj = {expression} is
supposed to replace $obj with the result of the expression, not call methods on
$obj. Doing otherwise would be huge change in the semantics, a complete no go.
Also, it's impossible if $obj is not set - meaning, code $obj = 1 would mean
totally different things depending on if $obj is set or not - again, not a good
idea. It also does not cover many corner cases but I don't even want to go
there since an idea to change semantics of the assignment seems very wrong to
me in principle, so no need to go into the fine details.
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Object Casting - An Alternative to Type Hinting
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 prefer something along the lines of C++ such as:
Cast From:
public __construct(Integer $i);
Cast To:
public Integer();
This would require function overloading (__construct overloading by type) but
with Type Hinting already available for function parameters, this could be done
relatively easily I think.
Doing this would keep code isolated with smaller functions.
-Clint
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Sunday, February 26, 2012 8:57 AM
To: internals@lists.php.net
Subject: [PHP-DEV] Object Casting - An Alternative to Type Hinting
I've gone back and re-read a bunch of the old posts on Type Hinting, and have
come to the conclusion that it won't be done any time soon.
Not because it doesn't have merit, but because there are at least a few
fundamental difficulties that are non-trivial to figure out while still keeping
the usefulness.
So, I started thinking of a way that we can work around it. One technique that
has been passed around is to use object wrappers and pass objects instead of
scalars. Such as was suggested in:
http://marc.info/?l=php-internalsm=119543188808737w=2
One of the problems associated with this, is that before you work with these
types, you need to manually cast them back to the native type they represent.
We can try to deal with this problem using __toString, but I don't think that's
granular enough to really be of much use in solving this problem...
Another method we could use, is if we supported operator overloading in
objects. That way, we could overload the addition operator to handle the
operation. However, this becomes quite problematic, since ordering of
operations and interaction with disparate class trees is going to get rather
messy (and extremely fragile) quite quick.
Let me throw out another possible solution. What if we added two new magic
methods to objects:
public function __castTo($type);
public static function __castFrom($value);
With these two methods, we could enable type-hinting by using something very
similar to auto-boxing. Let me start with a sample
implementation:
class Integer {
protected $value = 0;
public function __construct($value) {
$this-value = $value;
}
public function __castTo($type) {
switch ($type) {
case 'int':
case 'numeric':
return $this-value;
case 'float':
return (float) $this-value;
}
throw new LogicException('Illegal Cast Operation Performed');
}
public static function __castFrom($value) {
if (!is_scalar($value)) {
throw new LogicException('Illegal Cast Operation Performed');
}
return new static((int) $value);
}
}
Now, that enables us to do something like:
$int = new Integer(2);
echo $int + 2; // 4, since __castTo was called with numeric
echo substr(foobar, 0, $int); // fo since __castTo was called with int
That demonstrates the __castTo usages. Now for the __castFrom...
function foo(Integer $int) {
echo $int + 1;
}
Now, under current rules, calling foo(1) would result in a fatal error.
However, we could change that to check if the class being type-hinted for has a
__castFrom method on it. If it does, it would attempt to cast the value into
that class. So calling foo(1) would actually internally call
`Integer::__castFrom(1)`. And since that returns an object of instance
Integer, the hint would pass.
These two additions would solve a few issues with type-hinting. First off, it
solves the cast to vs error if debate on passing a string in the place of
an integer. In this case, it would be up to the
__castFrom() method to determine that (thereby enabling both worlds possible).
Second, it solves the problem of having to wrap clumsy APIs around scalars for
hinting purposes ($foo-getInteger() + 1).
Third, it is still completely optional... Fourth, it keeps and tries to
embrace the dynamic type-cohersion nature of PHP...
Now, that's not to say it's not without problems. Here are a few that I can
think of:
1. How should it deal with references? If I do `function foo(Integer $int)`,
what should happen?
- I would argue that if you're trying to reference, the casting
functionality should not be expected to work at all. But that introduces some
inconsistency there. Not sure how to solve that...
2. Should it support casting from one object to another? Meaning if I pass an
SPLInt to something expecting Integer (from two different trees), should
__castFrom be called?
- I would argue that yes, it should. That would open the door for
compatibility layers to be built for
RE: [PHP-DEV] [RFC] Enum proposal (yet another)
+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 terrific idea! --Kris On Sun, Feb 26, 2012 at 5:44 PM, John Crenshaw johncrens...@priacta.comwrote: From: Kris Craig [mailto:kris.cr...@gmail.com] I actually agree as well. Looking back in the thread, I think my overly broad use of the word strict might have led to some confusion over what I'm advocating. Honestly, this is the biggest problem that the typing debates have had. Someone advocates strict typing when they really mean weak typing (as opposed to the current dynamic typing) but there's always a group of people that assume they mean strict strict strict typing like the old C days. People then panic and get frustrated because the plethora of problems with adding this level of restriction to PHP have already been discussed extensively. Discussion then devolves into denigration and then finally disintegrates completely. If we can agree on some basic terminology I think it would move things forward considerably. I propose these terms: - Strict Typing means the super strict old C style typing that has been proven to be ridiculous in this environment because of the obvious problems inherent in the fact that almost every input is a string. - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) In addition, if someone potentially new expresses support for Strict Typing, let's assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Politely clarify terminology so that everyone can be on the same page. If someone still insists that they want Strict Typing, point them to the prior discussions on the topic which explain exactly what the problems with this are. It might be wise to maintain a wiki article to keep track of the 3 different levels of typing, as well as a summary of the typical arguments pro and con for each of the 3. If people agree that this would be helpful, I'm willing to dig through the archives and try to put this together. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] how to debug a php script ( the C code beneath it)
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 | | | Crumble_skin_and_dice Also, if you want to step-by-step debug I use eclipse CDT on a Linux virtual machine. -Original Message- From: Yader Hernandez [mailto:yader.hernan...@gmail.com] Sent: Monday, February 13, 2012 5:24 PM To: Ángel González Cc: Adi Mutu; PHP Developers Mailing List Subject: Re: [PHP-DEV] how to debug a php script ( the C code beneath it) It's also nice to see what PHP is actually doing and a way to learn the internals of PHP. 2012/2/13 Ángel González keis...@gmail.com On 13/02/12 21:48, Adi Mutu wrote: Hello, Perhaps this is a stupid question, but i haven't coded in C in years and i'm not very familiar with development/debugging tools. If I have a php script say 20 lines, How can I see a path of the corresponding C code which is executed? What If i would like to break at a certain php line in the script, is it possible? Thanks, Why do you want to do it? It looks to me like that you are trying to solve a problem the hard way by doing that. -- 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] Re: internals Digest 4 Feb 2012 09:08:29 -0000 Issue 2549
-Original Message- From: Rasmus Schultz [mailto:ras...@mindplay.dk] Sent: Saturday, February 04, 2012 10:01 AM To: internals@lists.php.net Subject: [PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 - Issue 2549 Why can't the read-only and write-only keywords be implicit instead of explicit? I've never seen another language where you have to explicitly indicate what you're doing. At best, it acts an extra fail-safe to prevent making errors - at worst, it just means more redundant code to maintain, more ways to make errors. Do the benefits really outweigh the value of this? The read-only and write-only keywords act a little differently. Without them, attempting a set on an accessor without a setter defined will cause __set() to be called whereas with the read-only it will produce an error. The inverse is true for write-only. I attempted to keep the ability to have lazy initializing of properties via accessors, but that could be written in php slightly differently if the read-only/write-only keywords were not present (due to guards). Doesn't particularly matter to me. Regarding automatic implementations - according to the wiki, the backing field is implemented as public. Is that correct? Most other languages don't even expose the existence of the backing field. Would it not be more correct to implement an auto-backing field as protected? The reason for implementing accessors in the first place, is usually to prevent direct access to an underlying field. Makes sense, in C# these backing fields are completely inaccessible directly, would that be even better in this case or would protected suffice? Since a high degree of explicitness 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 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 + Subject: [PATCH] Property Getters/Setters (v2.4) for review 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 implementation details and edge cases not defined by the original RFC. Most changes are in zend_compile, zend_object_handlers and zend_language_scanner. Thanks, -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] bugs.php.net access
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.
RE: [PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 -0000 Issue 2549
I guess my thought behind it was that __set() is supposed to be called whenever writing data to inaccessible properties, I sought not to change the default behavior of __set(). In the case of adding a read-only keyword was that it was explicitly stating that the property cannot be written 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: -Original Message- From: Rasmus Schultz [mailto:ras...@mindplay.dk] Sent: Saturday, February 04, 2012 10:01 AM To: internals@lists.php.net Subject: [PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 - Issue 2549 Why can't the read-only and write-only keywords be implicit instead of explicit? I've never seen another language where you have to explicitly indicate what you're doing. At best, it acts an extra fail-safe to prevent making errors - at worst, it just means more redundant code to maintain, more ways to make errors. Do the benefits really outweigh the value of this? The read-only and write-only keywords act a little differently. Without them, attempting a set on an accessor without a setter defined will cause __set() to be called whereas with the read-only it will produce an error. The inverse is true for write-only. I attempted to keep the ability to have lazy initializing of properties via accessors, but that could be written in php slightly differently if the read-only/write-only keywords were not present (due to guards). Doesn't particularly matter to me. Just curious: Why? Whats the benefit in allowing get directly and set via __set() at the same time? Regarding automatic implementations - according to the wiki, the backing field is implemented as public. Is that correct? Most other languages don't even expose the existence of the backing field. Would it not be more correct to implement an auto-backing field as protected? The reason for implementing accessors in the first place, is usually to prevent direct access to an underlying field. Makes sense, in C# these backing fields are completely inaccessible directly, would that be even better in this case or would protected suffice? Since a high degree of explicitness 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/4internals-digest-h...@lists.php.net From: Clint M Priestcpri...@zerocue.com To: internals@lists.php.netinternals@lists.php.net Cc: Date: Fri, 3 Feb 2012 13:47:53 + Subject: [PATCH] Property Getters/Setters (v2.4) for review 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 implementation details and edge cases not defined by the original RFC. Most changes are in zend_compile, zend_object_handlers and zend_language_scanner. Thanks, -Clint -- 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
[PHP-DEV] Bug 60833 Closing Bugs
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?
[PHP-DEV] Patch for bug60978
Could someone review and include? https://bugs.php.net/bug.php?id=60978 -Clint
[PHP-DEV] [PATCH] Property Getters/Setters (v2.4) for review
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 implementation details and edge cases not defined by the original RFC. Most changes are in zend_compile, zend_object_handlers and zend_language_scanner. Thanks, -Clint
RE: [PHP-DEV] [PATCH] Property Getters/Setters (v2.4) for review
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 is a generated file, you could exclude it from your diff, and end up with a much smaller patch. Smaller patches are more appealing :) On Fri, Feb 3, 2012 at 6:47 AM, Clint M Priest cpri...@zerocue.commailto:cpri...@zerocue.com wrote: 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 implementation details and edge cases not defined by the original RFC. Most changes are in zend_compile, zend_object_handlers and zend_language_scanner. Thanks, -Clint
[PHP-DEV] Property Accessors Type Hinting
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
class TimePeriod {
public array $Hours {
...
}
}
?
RE: [PHP-DEV] zend guard
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 things, I suggest its a guard against
recursion in __get and __set handlers.
This way, code such this one won't infinitly loop :
class Foo {
public function __get($p) {
return $this-$p; // this should lead to a recursion loop
}
}
$f = new Foo;
echo $f-barbaz;
http://lxr.php.net/opengrok/xref/PHP_5_4/Zend/zend_object_handlers.c#440
http://lxr.php.net/opengrok/xref/PHP_5_4/Zend/zend_object_handlers.c#zend_get_property_guard
http://lxr.php.net/xref/PHP_5_4/Zend/zend.h#290
Julien.P
On Mon, Jan 30, 2012 at 5:11 PM, Adi Mutu adi_mut...@yahoo.com wrote:
Hello,
Can anybody tell me what this struct is used for ?
I'm new to the internals of php.
Thanks,
A
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Uploading a patch fails...
Okay... Pierre had recommended I upload the patches to that bug report when I first got started. I just finished getting the last of the hard stuff working tonight. The patch is pretty big (though the 200k may have had a lot of white-space changes). It may also be so big because that patch included updates to the Reflection extension as well as tests for just about everything, plenty of code there. Would it be best to break apart the code into sets of diffs, such as: - Reflection - Reflection Tests - Feature - Feature Tests Thanks, -Clint -Original Message- From: Ferenc 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 of this magnitude. This is obviously not a bug, and not a small feature request either... the RFC is already in the wiki, AFAIR it is linked from the ticket also. https://wiki.php.net/rfc/propertygetsetsyntax https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Uploading a patch fails...
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
RE: [PHP-DEV] Shebang parsing
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, Robert Eisele wrote: My specific problem could be tackled in two ways: - Scan . every time cli is called for a php.ini file or - Try to make argv interpretation more intelligent and parse/merge shebang parameters. There are |.user.ini files, but only for CGI/FastCGI http://es2.php.net/manual/en/configuration.file.per-user.php | The second solution, would also open the possebility to define constants or make use of all other cli parameters. Well, there's also a quick hack. We could change php_getopt() in order to make this a valid argument: php -c=/var/www/php.ini What's wrong with (currently working) php -c/var/www/php.ini ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] getters/setters project
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: internals@lists.php.net
Subject: [PHP-DEV] getters/setters project
Hi,
I did not follow the whole getter / setter discussion completely and just have
read the RFC https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented .
I just wanted to know if the new getter/setter syntax will provide
getter/setter methods as well, so I can use fluent-interfaces?
$foo-setBar(a)-doSomething();
Or will I have to write getter / setter methods myself if I want to do this?
Thanks,
christoph
--
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
[PHP-DEV] getters/setters project
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 getter/setter. The lexer is considering this statement to be a static property reference. Alternatively is there someone out there with more experience w/ the compiler / opcodes that could help me complete this? Other than parent::$xxx and static accessors, everything else is done. Here is a wiki as-implemented I've created based on the original RFC if anyone wants to peruse it: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented Thanks, -Clint
[PHP-DEV] salsa.lo
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 this? -Clint
[PHP-DEV] PHP Wiki Down?
Looks like wiki.php.net is down... I'm getting an nginx gateway timeout.
RE: [PHP-DEV] Return Type Hinting for Methods RFC
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'
Subject: RE: [PHP-DEV] Return Type Hinting for Methods RFC
Is this how it's done in Scala?
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Ángel González [mailto:keis...@gmail.com]
Sent: Thursday, December 22, 2011 7:45 PM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel
there should be some token there before the class name, though I'm
unconvinced on which)
What about this?
function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
}
--
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] Accessors v2.2 Patch
This wouldn't quite address the concern. This already works and prevents any
modification/override to the accessor.
The spec talks about being able to allow an over-ride of the get and
non-override of the setter (or in the readonly case, no setter defined).
-Original Message-
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 iPhone
On Dec 11, 2011, at 11:02 PM, Clint M Priest cpri...@zerocue.com wrote:
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;
Results in:
Fatal error: Cannot set read-only property TimePeriod::$Hours, no setter
defined. in %s on line %d
Likewise in the other direction for write-only properties.
The difficulty is that one could extend TimePeriod and define a setter. This
is what the RFC talks about when using a readonly keyword. There presently
isn't a readonly keyword defined, nor a writeonly.
Should we create a readonly/writeonly keyword, or would something along these
lines be better/more flexible?
class TimePeriod {
public $Hours {
get { return 5; }
private final set { }
}
}
Creating (forcing the author to create) a private final setter which would
not allow a set to occur and could not be over-ridden?
I've also added two tests for the read-only and write-only, as it exists in
the above patch.
Pierre, with the new/updated RFC, should I gut the sections that I decided
against (such as the several alternate syntaxes) or leave them in?
-Clint
RE: [PHP-DEV] Accessors v2 Patch
There is currently no parent::get(), parent::set() capability. The RFC has no
mention of being able to call the parent accessor and so I have not explored
that possibility. It would be a nice feature for just such a purpose.
-Original Message-
From: guilhermebla...@gmail.com [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 implementation (an
instance that wraps a real Entity), demanding the load when any getter is
active.
This implementation seems to fit perfectly my needs, while still be cleaning.
I wonder if the user have already implemented a getter in this approach, how
can I overload this one?
Example:
class Foo
{
protected $name {
get { return $this-name; }
set { $this-name = $value; }
}
// ...
}
class FooProxy extends Foo
{
protected $name {
get { $this-__load(); parent::get(); }
set { $this-__load(); parent::set($value); }
}
// ...
}
How would it act in this situation?
Cheers,
On Sun, Dec 11, 2011 at 10:18 PM, Will Fitch will.fi...@gmail.com wrote:
This approach, in theory, is an interceptor itself. Most use-cases around
this approach will be changing or augmenting an existing property that is not
public. If you wanted to modify this interception, you'd need to extend the
class using it and redefine the getter and/or setter.
On Dec 11, 2011, at 10:02 PM, guilhermebla...@gmail.com wrote:
I have just one question, partially unrelated.
How can I make something similar to Interceptors of Java according to
your approach?
For those that have no idea, interceptors is a way to intercept
get/set of a property inside the class and act under this
circumstance.
[]s,
On Sun, Dec 11, 2011 at 8:01 PM, Clint M Priest cpri...@zerocue.com wrote:
To be complete I should probably add something to the reflection system as
well. At present the getters/setters would show up as functions.
What would be preferable?
1) Show up as regular functions and let users fend for themselves?
2) Hide from getMethods() and:
2.1) Provide getAccessors() - Probably returning a new
ReflectionPropertyAccessor class?
2.2) Provide getGetters(), getSetters()
3) Modify ReflectionProperty to include hasGetter() and hasSetter()
Comments?
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Sunday, December 11, 2011 6:47 PM
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 add two for protected as well?
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
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
visit: http://www.php.net/unsub.php
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
RE: [PHP-DEV] Accessors v2 Patch
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] Accessors v2 Patch On Mon, 2011-12-12 at 01:01 +, Clint M Priest wrote: To be complete I should probably add something to the reflection system as well. At present the getters/setters would show up as functions. What would be preferable? 1) Show up as regular functions and let users fend for themselves? 2) Hide from getMethods() and: 2.1) Provide getAccessors() - Probably returning a new ReflectionPropertyAccessor class? 2.2) Provide getGetters(), getSetters() 3) Modify ReflectionProperty to include hasGetter() and hasSetter() Comments? Reflection in PHP typically is leaking the implementation details typically quite a lot instead of abstracting things away (interfaces and Traits are ReflectionClass instances etc.) I didn't look at the implementation but if these accessors are implemented as methods (especially if it can be called just like one) I would go for approach 1) and probably mark with a flag. For everything else we'd probably have to clean-u reflection to leak less details to make sense. johannes -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Sunday, December 11, 2011 6:47 PM 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 add two for protected as well? 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
[PHP-DEV] Accessors v2 Patch
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 (public getter). I also checked all the tests and fixed the issues I found related. There is however some strange behavior that I do not understand. For some reason if I run all of the tests, 100+ or so will fail. If I have the test script write those failed tests to a file and just run those tests, all but four work fine. It appears to be something to do with line endings, in other cases the output does not match expected because of the addition of 'unicode' to the output. I've no idea what's going on here but after 3 days of mucking around, I can't find a solution as to why this is occurring. These failures do not occur on a fresh checkout but nothing I've changed should be causing any of the issues, just no idea here, any help would be appreciated. Felipe: I could not find any segmentation fault tests from before when you posted, nor now. Are you still seeing segmentation faults? Thoughts? -Clint
RE: [PHP-DEV] Accessors v2 Patch
https://bugs.php.net/patch-display.php?bug_id=49526patch=v2.1revision=latest Alright, nevermind on the failing tests, figured that out. I didn't realize the test structure doesn't indicate that it was segfaulting, that fixed all of the failing tests. So... I guess this patch is up for discussion? I don't presently have any static getters implemented, as best I can tell it would require some changes to opcodes, I didn't dive into anything besides exploration there. -Clint -Original Message- From: Will Fitch [mailto:will.fi...@gmail.com] Sent: 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 On Dec 11, 2011, at 2:27 PM, Clint M Priest cpri...@zerocue.com wrote: 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 (public getter). I also checked all the tests and fixed the issues I found related. There is however some strange behavior that I do not understand. For some reason if I run all of the tests, 100+ or so will fail. If I have the test script write those failed tests to a file and just run those tests, all but four work fine. It appears to be something to do with line endings, in other cases the output does not match expected because of the addition of 'unicode' to the output. I've no idea what's going on here but after 3 days of mucking around, I can't find a solution as to why this is occurring. These failures do not occur on a fresh checkout but nothing I've changed should be causing any of the issues, just no idea here, any help would be appreciated. Felipe: I could not find any segmentation fault tests from before when you posted, nor now. Are you still seeing segmentation faults? Thoughts? -Clint
RE: [PHP-DEV] Accessors v2 Patch
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] Accessors v2 Patch Hi Clint, Thanks for the updated patch :) Some suggestions (did not test it yet only review it), - add test cases for non public property (private, protected) - show examples of the concept of readonly property (as it is allowed in the C# equivalent I would also suggest to either take over the RFC (contact the original author) or create your own to update it with a full list of examples, documentation, and all necessary information. This is a complex task with many possible (edge) cases. An updated RFC is a must to be able to discuss such additions. Cheers, On Mon, Dec 12, 2011 at 1:21 AM, Clint M Priest cpri...@zerocue.com wrote: https://bugs.php.net/patch-display.php?bug_id=49526patch=v2.1revisio n=latest Alright, nevermind on the failing tests, figured that out. I didn't realize the test structure doesn't indicate that it was segfaulting, that fixed all of the failing tests. So... I guess this patch is up for discussion? I don't presently have any static getters implemented, as best I can tell it would require some changes to opcodes, I didn't dive into anything besides exploration there. -Clint -Original Message- From: Will Fitch [mailto:will.fi...@gmail.com] Sent: 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 On Dec 11, 2011, at 2:27 PM, Clint M Priest cpri...@zerocue.com wrote: 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 (public getter). I also checked all the tests and fixed the issues I found related. There is however some strange behavior that I do not understand. For some reason if I run all of the tests, 100+ or so will fail. If I have the test script write those failed tests to a file and just run those tests, all but four work fine. It appears to be something to do with line endings, in other cases the output does not match expected because of the addition of 'unicode' to the output. I've no idea what's going on here but after 3 days of mucking around, I can't find a solution as to why this is occurring. These failures do not occur on a fresh checkout but nothing I've changed should be causing any of the issues, just no idea here, any help would be appreciated. Felipe: I could not find any segmentation fault tests from before when you posted, nor now. Are you still seeing segmentation faults? Thoughts? -Clint -- 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] Accessors v2 Patch
To be complete I should probably add something to the reflection system as well. At present the getters/setters would show up as functions. What would be preferable? 1) Show up as regular functions and let users fend for themselves? 2) Hide from getMethods() and: 2.1) Provide getAccessors() - Probably returning a new ReflectionPropertyAccessor class? 2.2) Provide getGetters(), getSetters() 3) Modify ReflectionProperty to include hasGetter() and hasSetter() Comments? -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Sunday, December 11, 2011 6:47 PM 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 add two for protected as well? 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
[PHP-DEV] Accessors v2.2 Patch
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;
Results in:
Fatal error: Cannot set read-only property TimePeriod::$Hours, no setter
defined. in %s on line %d
Likewise in the other direction for write-only properties.
The difficulty is that one could extend TimePeriod and define a setter. This
is what the RFC talks about when using a readonly keyword. There presently
isn't a readonly keyword defined, nor a writeonly.
Should we create a readonly/writeonly keyword, or would something along these
lines be better/more flexible?
class TimePeriod {
public $Hours {
get { return 5; }
private final set { }
}
}
Creating (forcing the author to create) a private final setter which would not
allow a set to occur and could not be over-ridden?
I've also added two tests for the read-only and write-only, as it exists in the
above patch.
Pierre, with the new/updated RFC, should I gut the sections that I decided
against (such as the several alternate syntaxes) or leave them in?
-Clint
[PHP-DEV] Failing Tests
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?
RE: [PHP-DEV] Failing Tests
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, Which tests fail? What are the diff? Maybe upload them somewhere or send them to the list (answer yes at the end of make test). On Sat, Dec 10, 2011 at 4:30 PM, Clint M Priest cpri...@zerocue.com wrote: 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? -- 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] Re: Patch: getters/setters syntax Implementation
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@lists.php.net Subject: Re: [PHP-DEV] Re: Patch: getters/setters syntax Implementation On Tue, Dec 6, 2011 at 4:23 AM, Clint M Priest cpri...@zerocue.com wrote: 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 C# like setter/getter is definitely what I would like to have in PHP, it is a very clear and known syntax, while being features rich. 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] Re: Patch: getters/setters syntax Implementation
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
RE: [PHP-DEV] Patch: getters/setters syntax Implementation
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);
Standard __get()/__set() functionality checks for the more specifically defined
function name and calls them. I thought this would make the most sense since
it would allow us to leverage the existing inheritance functionality. This
comes out with respect to interfaces and traits in that only errors had to be
changed (for clarity) on interfaces and no changes to traits were necessary to
support the new functionality.
For the automatic get/set functionality, I essentially built the function body
myself within zend_do_end_accessor_declaration(). One point of contention here
is that internally it defines a __$Hours property which would be accessible
from various points. I believe the standard C# get/set does not allow any
access to the underlying data storage. In order to accomplish that there would
need to be some non-standard storage or a super-private level or something. I
did not explore that possibility as of yet.
I did add 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@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation
hi Clint!
Thanks for your work so far!
On Sun, Dec 4, 2011 at 1:33 AM, Clint M Priest cpri...@zerocue.com wrote:
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to the
voting phase. There is no need to hurry as the next release where this patch
could go in is next year.
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] Patch: getters/setters syntax Implementation
Ignore this patch for now, I'll get these issues addressed and I also want to
improve the performance a bit.
Felipe, I'll check out those failing tests, I found the CODING_STANDARDS doc
and will read it.
With regards to performance, I'm creating the __getHours string on each
invocation. I see that Hours has the zend_literal value. What would be the
best place to cache the hash_value for future calls?
Alternatively, what about adding a get/set function pointer to the property to
avoid string manipulation/hash calculation? Only issue I see is larger (much
larger?) memory 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: getters/setters syntax Implementation
2011/12/4 Felipe Pena felipe...@gmail.com:
Hi,
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);
Standard __get()/__set() functionality checks for the more specifically
defined function name and calls them. I thought this would make the most
sense since it would allow us to leverage the existing inheritance
functionality. This comes out with respect to interfaces and traits in that
only errors had to be changed (for clarity) on interfaces and no changes to
traits were necessary to support the new functionality.
For the automatic get/set functionality, I essentially built the function
body myself within zend_do_end_accessor_declaration(). One point of
contention here is that internally it defines a __$Hours property which
would be accessible from various points. I believe the standard C# get/set
does not allow any access to the underlying data storage. In order to
accomplish that there would need to be some non-standard storage or a
super-private level or something. I did not explore that possibility as of
yet.
I did add 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@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation
hi Clint!
Thanks for your work so far!
On Sun, Dec 4, 2011 at 1:33 AM, Clint M Priest cpri...@zerocue.com wrote:
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to the
voting phase. There is no need to hurry as the next release where this patch
could go in is next year.
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
I've fixed the zend_compile.c and zend_object_handlers.c to build with
--enable-maintainer-zts. (some TSRMLS_CC missing and TSRMLS_DC usage
instead of TSRMLS_CC) Other thing I have noticed that you have not
followed our coding standards about brackets and comments (we don't
use the C++ style one). And about the comments looks as the patch
isn't finished or you just forgot the remove them?
http://dpaste.com/665851/plain/
--
Regards,
Felipe Pena
Check out also the failing tests in Zend/tests/* (including segmentation fault)
--
Regards,
Felipe Pena
[PHP-DEV] Patch: getters/setters syntax Implementation
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:
public $Hours {
public get { return $this-_Hours; }
protected set { $this-_Hours = $value; } }
Default getter/setter implementations:
private $Hours {/* Implements private $__Hours;
*/
public get; /* { return
$this-__Hours; }
public set; /* { $this-__Hours =
$value; }
}
Interfaces (Forces implementation by implementing classes):
private $Hours {
get;
set;
}
Traits:No changes necessary, implementation worked without further changes
Errors: Updated errors to refer to getter/setter implementation when related
Note:
This does not interfere with typical __get()/__set() functionality which will
take effect whenever there is not a specific getter/setter written.
I have also included 8 .phpt test files which tests the new functionality
What are the next steps to get this added to some future release?
[PHP-DEV] Inject code within Compiler?
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_code[1024] = ;
sprintf((char*)injected_code,
{ return $this-%s; }, Z_STRVAL(var_name-u.constant));
znode *injected_node =
emalloc(sizeof(znode));
Z_STRVAL(injected_node-u.constant) = (char*)injected_code;
Z_STRLEN(injected_node-u.constant) = strlen(injected_code);
zend_do_abstract_method(function_token, modifiers, injected_node TSRMLS_CC);
However this is causing a segfault, I'm assuming this is because I'm not
initializing something of the znode properly.
How can I do this?
Thanks,
-Clint
[PHP-DEV] Supprting static getter/setter
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 opcode which would look back to the previous opcode (which should be a ZEND_FETCH_W) to identify the class/variable and then call the setter when appropriate. Does that seem like a good strategy or would you recommend some other way? -Clint
RE: [PHP-DEV] Multiple Visibility Level Getters/Setters
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, Nov 19, 2011 at 02:46, Clint M Priest cpri...@zerocue.com wrote:
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 { ... }
private set { ... }
}
}
No please.
That will create a major WTF factor.
-Hannes
[PHP-DEV] Freeing $1 from zend_language_parser.y
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
[PHP-DEV] Multiple Visibility Level Getters/Setters
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 { ... }
private set { ... }
}
}
Whichever getter/setter would be called with the most restricted access, so
externally public, internally protected (if inherited) or private from within.
Any value to this? I can see some use cases and wouldn't be any more difficult
to implement into what I'm already doing.
-Clint
[PHP-DEV] Getters/Setters and parent getter/setter access
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 probably break existing code if we tried to make the parent:: or TimePeriod:: syntax to access the parent accessor. Anyone have any suggestions on an alternative syntax? I'm sure I could change it so that parent:: or TimePeriod:: from within a getter/setter would cause it to access the parent getter/setter but that would create an inconsistency within the language. Ideas? -Clint
[PHP-DEV] Accessors Parsing
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
functions called in leiu of __get() if they are defined, does that seem like a
reasonable strategy for this?
More specific problems on the parser side of things, here is what I have now:
getter_setter_declarations:
getter_declaration
setter_declaration
| setter_declaration
getter_declaration
| setter_declaration
| getter_declaration
| /* empty */
;
getter_declaration:
method_modifiers T_GET
{ zend_do_begin_function_declaration($2, $$, 1,
ZEND_RETURN_VAL, $1 TSRMLS_CC); }
'{' inner_statement_list '}'
{ / $$ != Hours Here!! ***/
zend_do_abstract_method($$, $1, $4 TSRMLS_CC);
zend_do_end_function_declaration($2 TSRMLS_CC); }
setter_declaration:
T_SET '{' inner_statement_list '}'
class_variable_declaration:
T_VARIABLE { $$ = $1; / Capture variable name / } '{'
getter_setter_declarations '}'
| class_variable_declaration ',' T_VARIABLE
{ zend_do_declare_property($3, NULL, CG(access_type)
TSRMLS_CC); }
| class_variable_declaration ',' T_VARIABLE '=' static_scalar
{ zend_do_declare_property($3, $5, CG(access_type) TSRMLS_CC); }
| T_VARIABLE {
zend_do_declare_property($1, NULL, CG(access_type) TSRMLS_CC); }
| T_VARIABLE '=' static_scalar{ zend_do_declare_property($1,
$3, CG(access_type) TSRMLS_CC); }
;
I'm just working on the getter now.
1) I am able to get the T_VARIABLE name passed through to the
zend_do_begin_function() using $$ however $$ is no longer correctly set by
zend_do_abstract_method(). What would be a more appropriate way to store the
variable znode? I see there are a number of stacks in the compiler_globals,
would using one of those or creating a new one be appropriate?
1.1) Alternatively to #1, is there a way to access the T_VARIABLE znode from
the zend_do_begin_function_declaration() line? (Reach re patterns from
previous/prior matches/lines)
2) I am having trouble with building the function name (2nd param to
zend_do_begin_function) since that function needs to have a znode as the input.
I could stuff code in here to concat the strings together and build a znode
but since there is sparsely any real code in this file I hesitate to do so.
Any recommendations here?
3) An interesting situation with the above code is that the function is
declared and is seen through a ReflectionClass() but calling it indicates that
the function does not exist, I think that is because $$ was cleared/changed by
the time zend_do_abstract() is called, is this something I should add a check
for? (Calling zend_do_abstract() with a function name that was not previously
seen via zend_do_begin_function_declaration())
For reference, here is the PHP test class I am using:
#!/opt/trunk/sapi/cli/php
?php
class TimePeriod {
public $Seconds;
public function __construct($Seconds) {
$this-Seconds = $Seconds;
}
public $Hours {
get {
return $this-Seconds / 3600;
}
/* set { $this-Seconds = $value * 3600; } // The variable $value
holds the incoming value to be set*/
};
}
$o = new TimePeriod(3600);
echo $o-Seconds.\r\n;
echo $o-Hours().\r\n;
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Accessors Parsing
In this particular case I was just trying to see if Hours() had properly been defined as a callable function. Eventually that function name would become __getHours(), this particular line was just a test (which is where I discovered that the $$ was no longer set to ‘Hours’ 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 as method call? Why not echo $o-Hours; ? With regards, Alexander Moskaliov ir...@irker.netmailto:ir...@irker.net
RE: [PHP-DEV] Help w/ Parser
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
initial inception has been integrated into the RFC.
Does anyone have any feedback about that RFC as it is now? The one thing I
would like to see different about how it works vs c# is that if $Seconds were
defined as a getter/setter, $this-Seconds from within the getter/setter would
access the data storage, rather than the getter/setter function so that one
does not have to defined an additional datastore for each and every
getter/setter.
-Original Message-
From: Hannes Magnusson [mailto:hannes.magnus...@gmail.com]
Sent: Monday, November 07, 2011 8:04 AM
To: Hartmut Holzgraefe; php-...@zerocue.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Help w/ Parser
On Mon, Nov 7, 2011 at 12:31, Hartmut Holzgraefe hartmut.holzgra...@gmail.com
wrote:
On 11/07/2011 10:12 AM, Keloran wrote:
this looks cool if you get it to work
+1 want have! :)
Same here.
As long as someone doesn't think this creates precedence for importing C#
features and thinks implementing partial classes will be cool :)
Btw; https://wiki.php.net/rfc/propertygetsetsyntax
..and only text/plain attachments come through.
-Hannes
Index: Zend/zend_language_parser.y
===
--- Zend/zend_language_parser.y (revision 318862)
+++ Zend/zend_language_parser.y (working copy)
@@ -179,6 +179,8 @@
%token T_CLASS class (T_CLASS)
%token T_TRAIT trait (T_TRAIT)
%token T_INTERFACE interface (T_INTERFACE)
+%token T_GET get (T_GET)
+%token T_SET set (T_SET)
%token T_EXTENDSextends (T_EXTENDS)
%token T_IMPLEMENTS implements (T_IMPLEMENTS)
%token T_OBJECT_OPERATOR - (T_OBJECT_OPERATOR)
@@ -666,8 +668,14 @@
| T_FINAL { Z_LVAL($$.u.constant)
= ZEND_ACC_FINAL; }
;
+getter_setter_declaration:
+ T_GET '{' '}'
+ | T_SET '{' '}'
+;
+
class_variable_declaration:
- class_variable_declaration ',' T_VARIABLE
{ zend_do_declare_property($3, NULL, CG(access_type)
TSRMLS_CC); }
+ T_VARIABLE '{' getter_setter_declaration '}'
+ | class_variable_declaration ',' T_VARIABLE
{ zend_do_declare_property($3, NULL, CG(access_type)
TSRMLS_CC); }
| class_variable_declaration ',' T_VARIABLE '=' static_scalar
{ zend_do_declare_property($3, $5, CG(access_type) TSRMLS_CC); }
| T_VARIABLE {
zend_do_declare_property($1, NULL, CG(access_type) TSRMLS_CC); }
| T_VARIABLE '=' static_scalar{ zend_do_declare_property($1,
$3, CG(access_type) TSRMLS_CC); }
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Help w/ Parser
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 results in the same
error.
Is there something I need to run to process zend_language_scanner.l?
-Original Message-
From: Nikita Popov [mailto:nikita@googlemail.com]
Sent: Monday, November 07, 2011 12:12 AM
To: php-...@zerocue.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Help w/ Parser
I don't see an attachment. Could you send it again with .txt as file extension?
If you want 'get' to be recognized as T_GET you need to define such a token in
the lexer (zend_language_scanner.l). Did you do that?
On Mon, Nov 7, 2011 at 3:53 AM, php-...@zerocue.com wrote:
I'm having trouble getting some changes to the parser to recognize
some new syntax. I've attached a patch of what I've done.
Here is the syntax I am trying to get to be parsed properly:
?php
class TimePeriod {
public $Seconds;
public function __construct($Seconds) {
$this-Seconds = $Seconds;
}
// Getters/Setters
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value * 3600; } // The variable
$value holds the incoming value to be set
}
};
?
After compiling and attempting to execute the above PHP file, I'm
getting this parse error:
Parse error: syntax error, unexpected 'get' (T_STRING), expecting get
(T_GET) or set (T_SET) in /mnt/hgfs/svn/php-src-test/test.php on line
13
Why is the parse recognizing the 'get' as T_STRING rather than get (T_GET)?
Thanks,
-Clint
--
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
