Re: [PHP-DEV] [VOTE] PHP Technical Committee
It would be also good to know why people vote no. +1 for that, even if only a brief sentence. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] include cleanup
On 2/13/2023 4:13 AM, Arvids Godjuks wrote: Good day dear Internals! I've been following this thread/RFC from its inception to the current moment. I have watched the situation deteriorate and at this point, I have major concerns about the events that transpired, the motivations of some decisions and the apparent major lack of communication. But the worst thing, in my opinion, is that the mistakes that were made about a decade ago are happening in this thread: Cubstomping and alienating new contributors who are willing to take on major amounts of work and are willing to take on the long-term maintenance. This happened to me years ago and while I'm still here and reading the threads, I backed off from contributing any further. Many weeks of getting up early to work on the code for an hour before I had to head to work thrown away without even any better reason than "long-term maintenance" without me sticking around to do so. Just turned me off from the whole situation. I'm not alone in these concerns, but those people can do their own messaging. What I do not understand the most is the apparent "Not in my backyard" attitude to this RFC that seems to be happening. Improving the codebase ALWAYS requires breaking things and to be absolutely frank, I do not see how "merging conflicts" can be a sound reason for refusing header file shuffling. Or, in this case, "breaking extensions". I mean, the fixes are simple - update the header files. The author of the RFC is willing to provide the documentation/comments so it is easy to do. PHP 5 => PHP 7 engine transition was a major multi-year endeavour that was multiple orders of magnitude harder and broader problem, but everyone stuck to it and it was done. This RFC is nowhere even close to that but offers long-term improvements to the project. I am concerned about the apparent unwillingness to take on code cleanup projects. Can everybody involved cool their heads for a week, come back and talk this one out and make a plan for how to make the improvements in a way that parties can agree it should be handled? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Pass Scope to Magic Accessors
On 1/19/2023 12:40 PM, Marco Pivetta wrote: Not just that, but `debug_backtrace()` already exists for that purpose. I have use debug_backtrace() exactly for this purpose in the past. It was to make a protected property readable/writable, but only by certain "friend classes." It's pretty trivial to make happen with debug_backtrace() and even more so if you wrap it in its own reusable function. I don't see the need to implement this in the language since it's possible to achieve in userland trivially. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator
Nikita, I'm a bit worried that using this as a standard test suite may (repeatedly?) give us a false sense of security to go ahead with compatibility breaking changes. Composer packages, almost by definition - tend to be of higher quality than the 'average' PHP code (at the very least they're redistributable, but arguably Composer users are more advanced than the average developer - even more so those who publish packages). On top of that - probably the some of the most redistributed pieces of code in the PHP space - aren't covered by Composer at all (e.g. WordPress). Is this scanner available in a form that users could run it against their code basis and have it report to a server, perhaps after showing what it would report? This way, users and less polished code could be put to the same test. -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Abstract properties
Here here. :) On 3/17/2013 5:45 AM, Nikita Popov wrote: On Sun, Mar 17, 2013 at 10:03 AM, Ferenc Kovacs wrote: I'm also interested about the rationale behind this design decision. Just for the record, this would have been one of the things that the accessors proposal would have added. -- -Clint
Re: [PHP-DEV] Voting on PHP features
Unfortunately my experience with that process has been that many people will vote who had no part in the discussion. On 3/16/2013 3:16 PM, Sherif Ramadan wrote: On Sat, Mar 16, 2013 at 5:28 AM, Sébastien Durand wrote: Hi guys, *I think it could be a nice little improvement to add an extra form field (*160 chars max),* that would let users quickly comment on why they voted "yes" or "no".* * * *It would help having a better sense of what's going on and** to understand why this proposed feature is a good language design or not, without having to review countless messages on the mailing list.* * * I'm pretty sure that's the purpose of the discussion stage is before a feature is put to a vote. The purpose of the vote should be pure and simple. Yay or Nay. *My two cents,* * * *Sébastien* -- -Clint
Re: [PHP-DEV] PHP User Survey
On 2/20/2013 2:35 PM, Christopher Jones wrote: Hi Paul, My thesis is the other way round. More people in the community need to become PHP core developers. This is historically how PHP development has occurred, since nobody has idle time to adopt projects they are not 100% behind. Increasing user involvement is easier (and more often) said than done. I'd prefer to see effort spent mentoring, rather than running surveys. I've suggested this very thing in the past and even with a framework (albeit only in an email thread), I think a mentoring program of sorts would really benefit the core team. It could even be kept in small groups where 1 mentor dedicates to answer and/or find the answer for a group of 1 to 2 people who are keen on learning to help with the core. I would think that a separate mailing list for this type of mentorship would probably make sense, just to keep the chaffe off the internals list to a minimum. It would take some (at least 1) of the current core developers to step up and commit to helping. I ran into a lot of trouble learning what I know about the core and most of the tough question I had went unanswered for one reason or another, was quite infuriating at the time. I do have a lot of reservations about a survey. But if you do run one, I'm sure I'll look at the results. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Autoboxing Draft
There is also a PECL extension already under development that will
probably fill this void so many people would like to see filled.
On 2/25/2013 7:43 AM, Nils Andre wrote:
Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
the list at first. There has been ongoing discussion about new APIs and so
fort, so this is a suggestion for language cleanup by Autoboxing. I'd
really appreciate comments.
== Introduction ==
This RFC tries to approach the need for Autoboxing in PHP, or, to make
primitive types behave as if they were objects when being used or accessed
in an objectional fashion. Autoboxing can be discussed from various
perspectives, which is far beyond the scope of this document, which much
more addresses the fact that the language of PHP must be cleaned up in
order to grow more in terms of maturity and hence, in user accpetance.
== Autoboxing in brief ==
Autoboxing is that we can use primitive types, like integers, strings,
booleans and array as if they were objects, but without being constructed
as objects themselves.
Autoboxing is widely discussed, and somehow a must-have in OOP as a
consequence to having primitive types (for the sake of performance and
memory overhead) but keeping the language OOP-consistent.
== Why PHP needs it ==
PHP needs autoboxing as a means to restructure the language and make it
more predictable. One big flaw of today's PHP is, that it is unstructured
and chaotic with its builtin functions, as, for example, those dealing with
strings. Not going too much into details here, many programmes always have
to look up the function definition because very similar functions have
their parameters in different orders or simply don't act in a predictive,
well-structured manner. This article is a good read to sum it up:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
The problem derives from the fact that PHP has not been designed top-down,
but has been developed the bottom-up way over many years: As of today, the
language offers features other languages don't have, but struggles with
it's buried bodies from the past (mainly because compatibility had and
still has to be kept.)
By _adding autoboxing_ for all primitive types (Booleans, Strings,
Integers, Arrays), we would clean up the language in a very consistent
manner, but still retain backwards compatibility.
== How it could be implemented ==
We would not need much programming, because we simply map the new autoboxed
notation to the old code. We suggest the new notation to reproduce the Java
notation and parameter sequence closely, because it is pretty
straightforward and consistent (see, for example, the Javadocs on
java.lang.String).
== Syntax ==
The mapping is very straigtforward. Consider this:
$a = "This is a string";
$b = $a->toUpperCase()--> $b = ucase($a)
$b = $a->substring(0,4) --> $b = substr($a, 0, 4)
It would also allow many brilliant constructs like the following
if ($b->startsWith("This")) { ... }
in contrast to
if (substr($b,0,4) == "This") { ... }
Notice that the latter is error-prone, because if the condition changes one
would always have to match the string on the right handside to the length
of it on the left.
== Compatibility ==
The old notation could be switched on/off at any time.
The old notation would be switched on by default until, say, PHP 6, and can
then be enabled/disabled by either a compile flag, INI setting or some "use
\PHP5\*;" or something on top of a PHP file, which then makes the old
notation available to any code that follows/any file that is included
afterwards. As a consequence, \PHP5 will be the namespace comprising all
"old"/compatibility stuff.
== Advantages ==
- Cleanup of the language
- Consistency and predictability improved a lot (also in constrast to
possible userland classes - which would then all be slightly different)
- No lacking backwards compatibility
- Easier learning for new PHP programmers (beginners to PHP would be much
more pointed to learning OOP than procedural programming)
- Easier switching for programmers from Java to using PHP and vice versa
(now that PHP grew very mature, attract the Java folks with the cool stuff
PHP offers)
- Little overhead (as far as I am aware) to implement
- Nicer language syntax (see References)
== Disadvantages ==
- I don't know how complicated it is to implement. So far we don't have any
extensions for this on PECL, except for strong typing (see reference). From
a theoretical point of view, it is just mapping.
- There might be heaps of ways to implement, as the other autoboxing RFC
offers one possiblity. Certainly we need discussion on the best way to
implement. Maybe also "autoboxing" is the wrong word, as this RFC simply
suggests to map primitive types to some objectual syntax.
== References ==
This RFC [[https://wiki.php.net/rfc/autoboxing]] views it from the angle of
nicer syntax.
[[
http://php.webtutor.pl/en/2011/04/13/strong-data-typing-in-php-part-ii-autoboxing-and
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
On 2/21/2013 5:17 AM, David Muir wrote:
On 21/02/2013, at 6:12 AM, Lazare Inepologlou wrote:
Long code is not always equivalent to readable code. A shorter syntax could
improve readability in *some* cases.
Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );
Short:
$users->OrderBy( $x ==> $x->Surname );
I think your example proves the opposite. The fist example was much easier to
read and understand than the second.
That all depends on how many languages you're versed in, the short
syntax above is common in many modern languages and has no clarity
issues for me.
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] moving some READMEs to the wiki
On 1/29/2013 6:54 PM, Stas Malyshev wrote: Hi! I think having stuff on the wiki is nice, but for things related to the code - e.g., APIs, builds descriptions, etc. - they should stay in the code. They are easier to find there and easier to keep up-to-date, and also ensure they have the content relevant to specific version. We could have a wiki mirror - if somebody volunteers to maintain the wiki structure and keep it up-to-date. Do we have such person? I think first we need to create a place - wiki or manual, but somewhere - where this content is created and kept up-to-date, and properly versioned when relevant. When it happens, we can start replacing some of the docs with the links to this content. I agree that the repo should be the "source" from which the wiki pages flow, but making them more readily accessible to people not even aware of their existence (never downloaded a tarball) would really improve visibility for non-core. I know Ferenc already said there is something like it now, perhaps it can be updated to bring these files into the wiki in an automated fashion? If that's something that is needed/desired, I could head that up as a step in the direction of building the number of core devs. Alternatively as mentioned just a moment ago, the Wiki format is plainly readable in text form so if we just switched to writing these repo files in a more wiki-friendly format, they can simply be mirrored into the wiki to make them more widely consumable without taking them out of the repo. -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/17/2013 12:20 PM, Clint Priest wrote: I'm happy to say that Property Accessors is ready for a vote for inclusion in 5.5 release. Nikita and I (as well as Stas a bit) have all been working hard to make this happen for 5.5, voting and the specifications are here: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting Thanks, -Clint Voting has been closed, proposal declined. 34 to 22. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 1/29/2013 5:23 AM, Anthony Ferrara wrote: Additionally, I don't like the precedent that this sets for future releases. That it's ok to break the timebox for some feature. In this case I think we can justify it, but future cases may use this to justify waiting when it's not completely justified in itself. I'm not sure how we can rectify this concern, but I figured it was worth mentioning. I would agree with this sentiment, time boxing from my own personal experience just completely breaks down if you let anything get in the way of it, if you let that box slip for any reason, other reasons become easily justifyable. If 5.5 is due for release, we should not delay it for 2 months to get an opcode cache into core. Additionally: 1) I believe Optimizer+ is the opcode cache that's been discussed but it's not thread safe? 2) Isn't APC the standard? Is it in such bad shape it is not even being considered any longer? 3) There has never been a bundled opcode cache that I'm aware of, one more release without one is not going to surprise many people 4) Waiting for a 5.6 release will give everyone an entire year to get this into core and well tested which based on all the hoopla about how critical APC/opcode caches are to the core it makes sense that integration is going to be a long and painful process. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting periods
On 1/28/2013 6:12 AM, Peter Cowburn wrote: On 28 January 2013 12:03, Clint Priest wrote: If you're still worried about this making it in, don't worry. Nikita and I have given up, to the determinant of the community. Then please close the voting. Since there is no "maximum voting period" and 5.5 is not in a feature freeze yet, I left the voting open, in case some people decided to read the patch and change their minds. I see no reason to close the vote unless I'm required to do so or the game is up. I share Pierre's sentiment that this vote is pretty ridiculous. People have been asking for this feature (present in every other modern language) for 5+ years. I spent two years going through the *tedious* RFC discussion process, wrote the software, Nikita made it even better to have it shot down without even reasonable explanations as to why "from most people." Some people gave good explanations (Sherif Ramadan) even if I don't agree with them. Very few others did and it really leaves us/me with no direction to go. No reason for the rejection ergo no way to "improve this, or improve that." Some are resting on the idea that the ROI isn't there just aren't listening to the community. I'd love nothing more than to have this proposal accepted, and perhaps I will give it another go in the future. I figured at the very least I should contribute in other ways to PHP so that I eliminate the "big RFC from a new developer" aspect of the situation, which I think ultimately was the deciding factor. -Clint -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
On 1/28/2013 2:09 AM, Christian Stoller wrote:
In userland we can only do something like
$str = new String('my_string_class');
echo $str->length();
But that's useless.
It would be great if method calls on primitive types could be supported, like
in Nikic' proof of concept (https://github.com/nikic/scalar_objects).
$str = 'my_string_class';
echo $str->length();
I would really like to see that in PHP. It's not only a nicer and shorter way
to code but it would also be a solution for the function naming inconsistency
;-)
+1 from that, fortunately since it's an extension it won't be subject to
a vote, you can use it or not. :) The core seems to be heavily
protected by the core developers.
Best regards
Christian
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting periods
On 1/28/2013 5:19 AM, Zeev Suraski wrote: I feel that this is what was done in this particular case, not the other way around. That what brought me to bring up that subject here in the first place. This particular RFC was the only RFC where I noticed this weird 'no sooner than' language, and it seemed intentional to me - given the fact it's a very controversial feature opposed by most core devs. If we want to change the default voting period to two weeks, that's fine - but IMHO it should be for future RFCs after it gets approved. Actually, it was not done on purpose but was mimicking what many other RFC "vote sections" do, I thought it was the way it was supposed to be done, see: https://wiki.php.net/rfc/incompat_ctx https://wiki.php.net/rfc/array_column If you're still worried about this making it in, don't worry. Nikita and I have given up, to the determinant of the community. -Clint Zeev -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
On 1/25/2013 8:43 PM, Stas Malyshev wrote: Hi! Realistically couldn't we just introduce a configuration parameter to keep "the inconsistent parameter order," perhaps along with a script to suggest the changes needed to bring some code up to speed? People think that "introduce a configuration parameter" is a solution to almost any BC problem in the engine. It's not true, actually it's the opposite - now you have to maintain two code bases, one for one value of the parameter and one for another. Now imagine there's 10 such parameters, for different things in PHP, and you get 1024 options to test you application on. That's why we try to reduce behavior-modifying options to a minimum. Config options are for configuration, not for changing engine behavior in BC-breaking way. That's one of the reasons why magic_* were not a good idea and we had to get rid of them. And imagine integrating a library that is written with one set of engine options into application that expects another set of options. Now imagine application that uses a dozen of third-party libraries (in current open-source world, it's not too many at all), each of them expecting its own set of engine-modifying options. It would very quickly become a complete nightmare. So I think we should try to keep PHP behavior unified and avoid behavior-modifying switches as much as possible. I agree all of that would suck, but would it suck less than the alternatives for the most people involved? -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
On 1/25/2013 7:02 PM, Stas Malyshev wrote: Hi! Well, how about renaming the functions, create aliases for BC and throw E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled with the distribution to migrate to the new convention? Well, the problem with these things is this: suppose you have testing suite that verifies your code. What you do with E_DEPRECATED? You can treat them as failure, and that means in hypothetical PHP 6 release you code is broken, and you can't release it until you fixed it - so that means for you the effect it as if the function was effectively removed. On the other hand, you can ignore it - and then when these functions are removed, you get all your code broken, and while it is not removed, it's like we didn't do anything. Depending on just what is going to change, a simple script people can run to scan their code and spit out a diff of recommended changes they can simply review and approve of could be pretty painless. Then again you probably have people that would be subject to vendor updates without the ability to run the script or understand the changes it recommends. May be a small minority though. Are we talking mostly needle/haystack & haystack/needle type BC changes here or other more nefarious things? Realistically couldn't we just introduce a configuration parameter to keep "the inconsistent parameter order," perhaps along with a script to suggest the changes needed to bring some code up to speed? Would be a bit more in the core, for a time, but would allow people to transition when they wanted to, without all of the errors... -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On 1/25/2013 4:37 AM, Julien Pauli wrote: On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf wrote: And I can understand the lack of help. It is probably the most complicated piece of the entire stack. It is a an op_array juggler doing a complex dance on a tight rope backwards and blindfolded. It is essentially multi-threaded in that there are multiple processes all reading and writing the same chunk of memory while dealing with a compiler that spits out context-sensitive op_arrays that were never designed to be cached and executed this way. I'm not sure if anyone has a deep understanding of APC and the problems the existing compiler design causes for it, perhaps another great place to start on this project is to get a list of the high-level problems the compiler does or doesn't do that could be changed. Then we can break those down and identify the parts of the engine that will require some re-work. I firmly believe that we need opcode caching in core. I'm rather skeptical that simply moving pecl/apc to ext/apc is going to help users in any way. People have no trouble finding and installing APC today. The real issue here is robustness and lag time between a PHP release and and solid APC release and that has to do with resources which are scarce due to the code complexity. This is the real problem we need to solve. Either by a number of people stepping up to help with the existing APC code, or perhaps more realistically making it a priority in PHP 5.6 to streamline the engine and the executor for opcode caching and either including a heavily simplified version of APC or writing a new one. That feels like a safe idea. I'm convinced that having more internals documentation will help developpers understand at least the engine (that's what interest us here). I agree that bringing some more documentation can only help; people with less experience or who have missing areas of expertise in the core will more easily be able to step up and help with the problem. I know it's a hard task, but we all here have blogs where sometimes we write great articles about a part of internals, I think we should focus on working alltogether writing a real technical doc for the engine, that will help people (like me for example), understand some dark parts of it, and then find ideas or solutions for it to evolve the right way. This may only be my perception, but in having to learn what I did for the failed accessors project I felt like there were 2 or 3 more or less identical ways the compiler and/or executor was doing the same thing. Without further understanding I presumed it was because as time went by a new "way" was added because the old way just wasn't enough. In essence adding to the technical debt. Possibly/probably just a misconception of my own but that's the way it felt. I'd be happy to jump in and help fix this in any way I can but I don't even know where the string starts or what it looks like to unravel the problem at this point. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] C# properties vs. accessors RFC
On 1/23/2013 5:04 PM, Crypto Compress wrote: guard->in_unset = 1; /* Prevent recursion */ zend_call_method_with_1_params(&object, zobj->ce, &zobj->ce->__unset, ZEND_UNSET_FUNC_NAME, NULL, member); guard->in_unset = 0; /* Prevent recursion */ a) That applies to __unset (magic method) only b) guard is name specific (another name would have a different guard) c) Those three lines are not new code, they have just been moved around a bit. The code (for unset accessors) you are looking for is here: https://github.com/cpriest/php-src/blob/accessors-5.5/Zend/zend_object_handlers.c#L986 this code would only prevent nested/parallel access to same accessor but not circular? e.g.: getter -> setter -> null-checker -> null-setter -> getter sorry it this is a dumb question :) cryptocompress -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] C# properties vs. accessors RFC
On 1/23/2013 4:40 PM, Rasmus Lerdorf wrote: I appreciate that, I'm hearing through the grapevine that some of the "no" voters haven't even looked at the patch. Just to be fair, I suspect quite a few "yes" voters haven't looked at, nor understood the patch. -Rasmus I'd bet good money that's true too, neither of which is a good thing. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] C# properties vs. accessors RFC
On 1/23/2013 3:17 PM, Levi Morrison wrote: Clint: I'm sorry that you spent all that time without hearing feedback from a lot of the "No" voters. Had they been participating all along perhaps it could have been avoided. We'll never know. I appreciate that, I'm hearing through the grapevine that some of the "no" voters haven't even looked at the patch. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] C# properties vs. accessors RFC
On 1/23/2013 3:07 PM, Crypto Compress wrote: > I'd just like to point out the fact that RFC v1.1 from a year ago was exactly as above but people wanted all of these other features. They were not a property, they had no "guarding", no unset, isset, etc. The original RFC that was exactly as c# had it, nobody liked it. It was changed to its current incarnation because it now mimics exactly what everyone is use to with __get(), etc. i think you refer to RFC 0.3 (could not find C# in 1.1): https://wiki.php.net/rfc/propertygetsetsyntax#properties_in_c Well actually you're right. .3 was written by Dennis long ago and I wrote accessors to be exactly as that document described except where there was ambiguity. The 1.1 document had already deviated from his original RFC by way of discussion but I had not been tracking them as separate documents. If you go back in history on https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented you will see a point where it matches the original spec more or less completely. cryptocompress -- -Clint
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/23/2013 1:00 PM, Marco Pivetta wrote:
Actually, having the properties shown even if virtual allows us to
access them in a reflection-ish manner without doing dangerous
assumptions like "does the setter/getter exist"?
The fact that the property is virtual is very useful, even though in
dumping it doesn't show any value. I don't see any radical difference
in debugging or ease of use in general.
Actually, doing the same things with magic getters/setters would
probably imply having to think more about the trace we want to follow
when analyzing our bugs. It is just a matter of being aware of new
setter/getters (that are anyway in our trace).
If you stop and think about it, the current accessors are identical in
functionality to defining a private variable for every __get().
So these two sets of code work and act identically:
class Foo {
private $bar;
public __get($name) {
if($name == 'bar')
return $this->bar;
}
public __set($name, $value) {
if($name == 'bar')
$this->bar = $value;
}
public __isset($name) {
if($name == 'bar')
return isset($this->bar);
}
public __unset($name) {
if($name == 'bar')
unset($this->bar);
}
}
-- OR --
class Foo {
public $bar { get; set; }
}
Except in the first case, you have to look at four sections of code to
find "everything that applies to bar" and if you add 5 or 6 more dynamic
properties, you have 4 huge switch statements, again with all the code
split up everywhere.
With Property Accessors, it's all right there. This of course is a very
simple case, if you actually USE the dynamic nature of __get(), etc then
you've got a ton more code.
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] C# properties vs. accessors RFC
On Jan 23, 2013, at 1:23 PM, Steve Clay wrote:
> First of all, I think the functionality provided by Clint and Nikita's RFC
> [1] is in demand and would be an asset to PHP, but I also think it can
> repackaged more simply.
>
> People are comparing the RFC to C# [2], but while they look similar, C# has a
> simpler implementation we should learn from.
>
> 1. C# draws a firm line between property and field, keeping both concepts
> simple.
>
> A "field" is like a PHP property. There's no more to understand.
>
> A "property" is simply a set of functions emulating a field, and $value is
> available in the setter body. There's no more to understand.
>
> Importantly, I think, the property takes the place of a field; there's never
> a "shadow" field of the same name to think about. The obvious downside is you
> must use a distinctly-named field for storage, but the upside is conceptual
> and behavioral simplicity. There's no need for "guarding" mechanisms and
> rules about where "$this->prop" will mean field access or trigger
> getter/setter; we know there is no field "prop", period.
>
> As Sharif Ramadan pointed out, it also makes state snapshots clearer as there
> is no value stored under "prop" to potentially confuse. Under the RFC, every
> property would show up as a field *even if the accessors didn't use that
> field*.
>
> 2. C# has no issetter/unsetter.
>
> IMO customizing these functions is completely unneeded for the vast majority
> of use cases and could be replaced by simpler logic: isset($this->prop) calls
> the getter and compares to NULL; unset($this->prop) passes NULL to the setter.
>
> 3. C# has no auto-implementations.
>
> IMO auto implementations have some value removing boilerplate, but we should
> not make them violate #1. We could have the property syntax specify what
> field to use for underlying storage, or simply conclude that the boilerplate
> is worth the clarity.
>
>
> I think the path forward is to determine how we can serve the same goals as
> this RFC, but retain the conceptual simplicity of the C# implementation and
> maybe syntax that strays less from current PHP.
>
> I have some ideas that I could start forging into an RFC. Consider this:
>
> class Foo {
> private $_bar;
> public function get bar { return $this->_bar; }
> public function set bar { $this->_bar = $value; }
> }
>
> Advantages I see over the RFC:
> * It's clearer that the accessors map to regular methods, and you know how to
> control visibility of methods and how they're inherited.
> * It's clearer $bar doesn't exist as a property, and it will never show up in
> state inspection.
> * You know $_bar is a plain PHP property, and you can initialize it directly
> in the constructor; we don't need an "initter".
> * There are no guards/proxies/shadow property to think about
>
> As for type-hinting, I think that could be achieved by a separate, simpler
> mechanism: type-hinting the properties.
>
> class Foo {
> private Bar? $_bar;
> }
>
> $_bar is a regular property, but which can only be set to a Bar or to null
> ("?" implies nullable). That gives you simple typed properties (useful and
> simpler to understand without accessors), but also suggests how to combine
> these to get "typed accessors":
>
> class Foo {
> // settable anywhere
> public Bar $bar;
>
> // "read only"
> protected Baz? $_baz;
> public function get baz { return $this->_baz; }
> }
>
>
> Down the road we could further address how to shorten this syntax but while
> keeping it clear that accessors are just functions and properties are just
> value stores.
>
I'd just like to point out the fact that RFC v1.1 from a year ago was exactly
as above but people wanted all of these other features. They were not a
property, they had no "guarding", no unset, isset, etc.
The original RFC that was exactly as c# had it, nobody liked it.
It was changed to its current incarnation because it now mimics exactly what
everyone is use to with __get(), etc.
>
> [1] https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
> [2] http://msdn.microsoft.com/en-us/library/x9fsa0sw(v=vs.80).aspx
>
> Steve Clay
> --
> http://www.mrclay.org/
>
> --
> 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] [VOTE] Property Accessors for 5.5
On 1/23/2013 8:31 AM, Sherif Ramadan wrote:
Except that everything that's proposed here is possible today with __get,
__set, __isset and __unset. So already today you can't assume that a
property is a "variable". In fact, you could build something like this
using __get, etc extremely dirty:
class Foo {
public function __get($name) {
$method = 'get' . ucfirst($name);
if (method_exists($this, $method)) {
return $this->method();
}
return $this->$name; // public properties
}
public function __set($name, $value) {
$method = 'set' . ucfirst($name);
if (method_exists($this, $method)) {
return $this->method($value);
}
return $this->$name = $value; // public properties
}
}
The difference in functionality that this provides is the ability to
custom-scope getters and setters. And it's a LOT cleaner...
Just a reminder on that cleanliness... Symfony: 3,805 functions that are
getters or setters, Zend Framework: 4,080 functions that are getters or
setters, not even counting what is being done with __get().
This is not true. Magic getters and setters make a distinction that
accessors do not. That distinction is that they can only work on
inaccessible properties. Accessors offer no such distinction. They are
explicitly defined and as such their properties are not magical even though
they provide somewhat magical characteristics.
When you use var_dump to debug the property of an object, or the object
itself, for example, you would expect that whatever value is returned for
that property is either stored in memory somewhere or is the result of a
magic getter. Now, if it is the result of a magic getter there is no
confusion between whether this is an actual property or magic getter,
because a look at var_dump of that object tells us the whole story.
Actually you could say that last sentence is precisely opposite of the
truth in that a var_dump() will *never* expose properties that are
available via a magic __get() therefore a var_dump() already mis-leads
the developer because there can be properties that can be retrieved
which are not shown by a simple var_dump().
With accessors you now make the case that the property can be the result of
any computation and as such var_dump only reveals the underlying storage
unit and has no awareness of any computation.
class foo {
public $bar {
get() { return 'baz'; }
}
}
var_dump(json_encode(new foo),new foo, (new foo)->bar);
// gives us
string(12) "{"bar":null}"
object(foo)#1 (1) {
["bar"]=>
NULL
}
string(3) "baz"
There's a subtle difference here that's not obvious at first. The
difference is that we have no way of knowing whether "bar" is the result of
an accessor or a an actual property without closely examining the code.
There's no easy way to debug who went wrong when this causes a problem. If
the property is now acting as a method we have to start treating it like a
method in order to debug it. That could mean backtraces, exception
handling, and a variety of other things that I really find weird to have to
do with an a property.
Now, let's examine the alternative. Using magic methods...
class foo {
private $bar;
public function __get($name) {
if ($name == 'bar') {
return 'baz';
}
}
}
var_dump(json_encode(new foo),new foo, (new foo)->bar);
string(2) "{}"
object(foo)#1 (1) {
["bar":"foo":private]=>
NULL
}
string(3) "baz"
There had been very recent talk of having an accessor output something
to the effect of:
object(foo)#1 (1) {
["bar":"foo":accessor]=>
NULL
}
I would actually favor the idea that nothing can see the property value
except the accessor and this would mean that a var_dump() would call the
accessor. By having var_dump() read the value of the underlying
property directly it really violates the entire idea of an accessor.
Every other language that implements accessors (and it's most modern
languages) there is no actual underlying property. This is the way 1.1
originally proposed it, but that was not what people wanted, they did
not want to have to declare a backing property of their own and so it
was changed.
The result of the current RFC is a result of the endless discussion that
was had on this topic. It's really not appropriate to vote against
something if you did not make your voice heard when discussions of some
aspect were happening.
At least here we know that "bar" is undoubtedly a private property so
whatever we got from (new foo)->bar must be the result of a magic getter.
There's only one place to look for that (in the magic method). With an
accessor I could easily create a situation where a bug manifests itself
anywhere in the code and not necessarily in the accessor itself that
accessor effectively becomes a method that does computation rather than
handling mere storage and retrieval.
I really really feel this is a way to g
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On Jan 22, 2013, at 6:00 PM, Christopher Jones wrote: > On 01/22/2013 01:27 PM, Clint Priest wrote: >> In terms of cost of maintenance, I was under the impression that >> since I wrote it, I would be maintaining it which is why I applied >> for and you approved a VCS account for me. > > The concern is historical and not personal. Frequently the long-term > contributors to PHP have been left to stabilize, integrate (e.g. with > APC), and then maintain code that was contributed. > > I do note & appreciate your outstanding perseverance and leadership in > working through the RFC process. > Thanks, its been a long hard road for two years. I've wanted to contribute to PHP for years but there was a steep learning curve. I'm personally honored to have been given a VCS account and would like to see the project flourish far beyond where it is presently, I fully intend to be a long term core contributor to this project. I would also like to thank Nikita as he has done a lot with the project as well. Were it not for him, it would not be ready for release. -Clint > Chris > > -- > christopher.jo...@oracle.com http://twitter.com/ghrd > Newly updated, free PHP & Oracle book: > http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html > > -- > 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] [VOTE] Property Accessors for 5.5
On 1/22/2013 9:24 AM, Levi Morrison wrote:
For those that have voted against this proposal, are there any
clarifications that can be made or questions answered?
I can say that this bit is particularly confusing:
public $foo {}
My understanding that this code will not emit any warnings when
interpreted, but the $foo property has no getter nor setter. You can
call isset which will return false but unset will emit a warning, yes?
This is correct except in the case where you are inheriting the
property. The above, on it's own class would be pointless.
I would think that the above snippet would create a property with all
public, default implementations.
If you are looking to create a public property with default
implementations, the following will suffice and has for a long time:
public $foo;
I see why it doesn't: it doesn't
permit you to declare only a getter and no setter.
Not sure what you mean here, you can declare a property with a getter
and no setter, such as:
public $foo { get; }
Which allows the property to be read, but not written, this is what the
asymmetrical access is about.
This is just one more reason for me to vote no on this.
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/22/2013 11:20 AM, Rasmus Lerdorf wrote: On 01/22/2013 03:18 AM, Clint Priest wrote: For those that have voted against this proposal, are there any clarifications that can be made or questions answered? There seems to be a lot of userland support for this proposal from people who don't have voting rights. The simple explanation from me is that the ROI isn't there on this one. It adds a lot of code complexity for very little return. Yes, it saves a couple of lines of boilerplate code for a few people, but the cost is high in terms of ongoing maintenance and potential issues for opcode caches as well. If you look at the split in voting you will notice it is pretty much split along the lines of the people who have to maintain this code vs. the people who would like a shiny new feature. Hey Rasmus, With all due respect, I think you missed the post where Nikita Popov analysed two of the biggest PHP based frameworks around, Symfony (Standard) and Zend Framework where he found that there were 3,805 and 4,080 functions which served as a getter or a setter. I do not think his analysis even included any usage of __get() or __set(). Here is his original gist of his analysis: https://gist.github.com/3884203 In terms of cost of maintenance, I was under the impression that since I wrote it, I would be maintaining it which is why I applied for and you approved a VCS account for me. Lastly, I'm not sure if you have looked over the code, but a very large amount of duplicate code has been cleaned up and centralized, both property accessors and magic accessors use the same pre/post function and logic. I can honestly say that adding the feature to the project would *improve* the code base. -Rasmus -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/22/2013 6:55 AM, Marco Pivetta wrote: @Lester your explanation simply exposes the fact that your resources to upgrade to newer technologies are insufficient. This doesn't mean that newer technologies don't have to exist. And no, it won't be possible to fix all bugs/flaws before getting a new feature. We'd all be running in circles looking for perfection :) I can agree that some things need fixing though, perhaps Lester could put together an RFC detailing the myriad of things he deems critical to be fixed. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/17/2013 12:20 PM, Clint Priest wrote: I'm happy to say that Property Accessors is ready for a vote for inclusion in 5.5 release. Nikita and I (as well as Stas a bit) have all been working hard to make this happen for 5.5, voting and the specifications are here: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting For those that have voted against this proposal, are there any clarifications that can be made or questions answered? There seems to be a lot of userland support for this proposal from people who don't have voting rights. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/20/2013 3:11 PM, Gordon Oheim wrote:
Am 17.01.2013 19:20, schrieb Clint Priest:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make
this happen for 5.5, voting and the specifications are here:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
Thanks,
-Clint
Thanks Clint and Niki for your work. Sorry to respond only now that
the voting process has already started. I usually don't
follow/participate on internals due to the noise and poisoned
atmosphere (but that's a different story). Also thanks Niki for taking
the time to answer all my questions I had about this beforehand.
My main issue with the implementation at hand is the weird way in
which we allow the visibility on the properties to be declared, e.g.
public $foo { get; protected set; }
The visibility keyword on the property is watering down the visibility
semantics. Either the property is public (then it can be set) or it is
not public. I would have much less of a problem with this, if
declaring visibility on a property could only be loosened but not
tightened. That would at least be consistent with how visibility works
with inheritance. It would be much better though to remove the
visibility keyword from the property altogether. It almost never tells
the truth.
This is basically an argument against asymmetrical visibility altogether
which is one of the most useful features of this proposal. I think
there are many use cases where an object wants to be able to emit a
message (value) but not receive one and being able to declare that fact
is important.
Removing the visibility keyword from the property altogether would
also remove the purported default visibility that is applied to the
accessors. I say "purported" because doing
public $foo { get; protected set; }
will also change the unset accessor to protected, which makes perfect
sense when you think about it but is completely unobvious when the
declaration claims the default visibility of all accessors to be
public. The default visibility of isset is that of get and the default
visibility of unset is that of set instead.
To add to the confusion, doing
public $foo { get; protected set; public unset; }
WILL work and change the visibility of unset back to what the property
claims it is. This should not be necessary when visibility on the
keyword defines the default visibility. I guess it's safe to say that
having the visibility on the property does very little to express
anything meaningful about the property or the default visibility of
*all* the accessors.
Perhaps this is just a documentation problem in that somewhere the
implication that public applies to all accessors when it should really
say that it applies to all declared accessors.
It is perfectly logical that when you cannot set a value, then you
cannot unset a value.
Defining what you have done above is declaring that you want to allow
people to get or unset the value, but not set it directly. This makes
sense in some usage scenarios. As an example, perhaps $foo represents
an internally generated id which is generated on the first call to the
getter, you don't want outsiders to specify the id, but you're okay with
having it unset so that a new one can be generated with the internal
generation mechanics on the next get request.
As an aside, your previous example can also be declared like this:
public $foo { get; protected set; unset; }
unset is explicitly declared and implicitly implemented and is public,
isset would be implicitly declared and implicitly implemented and follow
the visibility of the getter.
isset/unset only follow the get/set visibility if isset/unset are left
undeclared.
If this could be changed, I'd be more willing to vote pro the proposal.
TL;DR: The visibility keyword on the property is almost never giving
an accurate information about the accessor visibility. Thus, it should
be removed or replaced for clarity's sake.
I think I've made the case above that this isn't accurate, it always
affects declared accessors which do not have their own visibility specified.
Regards,
Gordon
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] References in rfc:propertygetsetsyntax
On 1/21/2013 12:36 PM, Richard Quadling wrote:
Hello.
This may have already been covered, so apologies ...
With https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#references,
the return by reference is handled by the use of &get{}.
How about pass-by-reference for set{}?
It works, it was simply not included in that section, which it now is:
Documented in the references section:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2?&#references
Normally, a function definition dictates this.
But if $value is already passed, a reference to it (&$value) is not
going to be referencing the external variable surely?
Whilst objects are always passed by reference (I assume this is still
the case for this rfc and I can see no reason why it isn't), and I
think I can see the sort of issues that setting an accessor to a
reference (binding the value of a property in this class to something
external to the class - yeah - just eek!), is this an issue?
Will users _want_ ...
set(&$value){ $this->externally_linked_var = $value; }
I'm not expecting any changes to anything, just looking for clarification.
Regards,
Richard.
--
-Clint
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
On 1/20/2013 9:26 AM, Nikita Popov wrote:
I now added a patch for this proposal: https://gist.github.com/4579298 (For
more detailed individual commits see here:
https://github.com/nikic/php-src/commits/alternativeSyntax)
One thing I hadn't noticed is that the proposal was to move the
typehint, what happens in this case then:
public DateTime $date {
get;
set(stdClass $value);
}
Would the above produce a compilation error on the stdClass part?
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/20/2013 7:35 AM, Sherif Ramadan wrote:
Now $surface shows us the following from var_dump
object(surface)#1 (3) {
["area"]=>
NULL
["width"]=>
int(4)
["height"]=>
int(2)
}
Sounds like a reasonable approach to me... var_dump()
1) Should not invoke the getters..
2) Should indicate that they are property accessors (perhaps not even
show the underlying guarded property?)
Possibly:
object(surface)#1 (3) {
["area":accessor]=>
NULL
["width":accessor]=>
int(4)
["height":accessor]=>
int(2)
}
This could easily be changed if nobody had any further disagreements
with this?
Only issue I could see would be existing code that may parse var_dump()
might break if it wasn't written to accept something other that
private/protected...
--
-Clint
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/17/2013 4:24 PM, Steve Clay wrote:
> https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
I'll say my peace on this. This is a very good implementation, and as
long as authors use accessors that depend on a separate property for
storage (like other langs require), everything will be
straightforward. Otherwise, I fear they're in for some confusing
behavior.
Consider the code from the RFC:
class TimePeriod {
public $Hours {
get { return $this->Hours ?: "not specified"; }
set { $this->Hours = $value; }
}
}
$tp = new TimePeriod();
$tp->Hours; // "not specified"
isset($tp->Hours); // true!?
$tp->Hours isset, the property exists and it's value is non-null.
The auto implementation of isset compares $this->Hours to NULL, but
since $this->Hours goes through the getter, it will return "not
specified". So the property will always appear to be isset.
* The guards seem spooky: A set of tokens ($this->prop) will have
varying behavior (e.g. direct prop read vs. getter call) *depending on
the call stack*.
This is the same as would occur with isset against an undefined
property, that would call __isset(), followed by __get() which would
then compare the value to NULL.
* Giving issetter/unsetter no direct access to the property limits
functionality and leads to weirdness like the example above.
This is possible, simply by supplying your own implementation of
isset/unset that calls isset/unset, such as:
public $foo {
get; set;
isset { return isset($this->foo); }
unset { unset($this->foo); }
}
The above five lines of code is exactly equivalent in functionality to:
public $foo;
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Property Accessors for 5.5
I'm happy to say that Property Accessors is ready for a vote for inclusion in 5.5 release. Nikita and I (as well as Stas a bit) have all been working hard to make this happen for 5.5, voting and the specifications are here: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting Thanks, -Clint -- -Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
On 1/13/2013 8:01 AM, Mark wrote:
I'm guessing this RFC won't make it in PHP 5.5? Too bad since it did
seem like a very nice feature to have.
I don't know if it is very helpful but posting nevertheless. I'm a
C++/Qt/QML/PHP developer and for me the proposed syntax in the v1.2
document makes perfect sense and is intuitive to use. As for the
earlier example about isset...
i'd expect an example like this:
class SomeClass {
public $date {
get;
set(DateTime $date);
}
}
$temp = new SomeClass();
i'd expect "isset($temp->date)" to return exactly the same as if the
class where defined like this:
class SomeClass {
public $date;
}
That's correct, it will.
Furthermore, isset() will never throw an error, even if it would not be
legal to call isset or get (from 1.1 RFC changes).
I don't know if that issue was already sorted out but i wanted to
share my expectations in that regards.
Will this make PHP 5.5? Or will it be deferred to 5.6?
Nikita, Stas and I are working very hard to make it into 5.5, we expect
to propose a vote sometime in the next couple of days.
** Any remaining feedback is appreciated, the RFC is being kept up to
date w/ current understood consensus. **
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: cpriest
Fix bugs, develop features and contribute to the core. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_map() function modification
On 1/12/2013 11:46 AM, Alexey Zakhlestin wrote: There is a function for this: http://docs.php.net/array_combine Nobody ever knows that one, I use it frequently, so useful. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] array_column() function
My .02 cents here... I'm used to array_pluck(), even when I first saw it I was like WTH is that? When you read the description though, 'plucking' is a verb which describes the action the function is taking, while column is a noun and does not describe the action the function is taking. In fact I have my own userland array_pluck() function. Ergo, array_column() doesn't make sense, array_get_column() might make sense, while array_pluck() makes sense. I'm fine with an alias or either one really, just pointing out the logic of "pluck." -Clint On 1/12/2013 9:34 AM, Ben Ramsey wrote: On 1/12/13 9:19 AM, Derick Rethans wrote: I'm liking this, why start with an function alias already when introducing a new feature? I figured this would be a frequent question, and I was right. :-) In earlier discussions (June 2012), when I first introduced array_column(), much of the discussion revolved around the name and not the functionality. I agreed with arguments for array_column() and arguments for array_pluck(), so I added an alias. Here's why I think the alias should be considered: 1) Userland PHP developers instantly recognize array_column(). It's self-descriptive, and they know what it means. 2) Developers coming from other languages (Ruby, JavaScript, etc.) will instantly recognize array_pluck(). It's what they'll be looking for to do the same thing, but they won't be looking for array_column(). -Ben -- -Clint
Re: [PHP-DEV] A remark about PHP's Vision and new things.
That is seriously funny On Jan 11, 2013, at 11:35 PM, Levi Morrison wrote: >> Can we re-write PHP with PHP? ;) > > Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP > > -- > 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] A remark about PHP's Vision and new things.
On 1/11/2013 1:17 PM, Stas Malyshev wrote: Hi! A function that is related to a zend_function struct could be placed anywhere, in any file and can be named in any way. Finding it is like looking for a needle in a haystack, then you add macros. You can do macros in C++ too, and you can have detached functions too. And it is perfectly possible to make mess with classes, I have seen it many times. Thinking that the language would somehow make you write good code is an illusion. It can help you or fail to help you, but it can never make you. C has tools to help you, though some of them aren't as powerful as I would wish for, it still has them. When I first started with working with the php-core I was doing everything wrong because it's a big mess, that's what happens with C, it It has nothing to do with C. Thinking that if PHP core was written in you would instantly get what's going on after 3 minutes looking in the code is, again, an illusion. PHP core is complex, because it does complex things. It also somewhat messy as any organic growth project becomes after 15 years. Nothing has anything to do with the language. You don't need C++ to not put new zend_hash functions into zend_compile.c. You just need common sense and knowledge how the project works. That's true, but you can't put a method on a ZendHash class without defining it within the class definition. I forget that C++ does let you actually implement that function outside of the class definition, but it's not a method of the class if it's not in the class definition. I've gotten too use to the way PHP does it where all of the code for the class is within the class definition it's-self, not quite the same as C++. Can we re-write PHP with PHP? ;) -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A remark about PHP's Vision and new things.
It's a pretty decent read, but the major point that his article about the virtues of C misses a huge mark. Software written in C, when they become of sufficient size become completely impossible to keep track of. A function that is related to a zend_function struct could be placed anywhere, in any file and can be named in any way. Finding it is like looking for a needle in a haystack, then you add macros. When I first started with working with the php-core I was doing everything wrong because it's a big mess, that's what happens with C, it has no organization requirements whatsoever and unless everyone who is working on the project is highly organized in the same fashion it will become a disorganized mess. Sure, C++ adds a lot of things that *can* overly complicate things but at the very least it requires organization, something that most projects sorely need. Even so, C++ is not the only object oriented language out there. -Clint On 1/11/2013 12:35 AM, Pierre Joye wrote: No. C++ is horrible. Very good read: http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html On Jan 11, 2013 5:06 AM, "Clint Priest" wrote: Oooh, a rewrite? Can we write it in an object oriented language this time? Please? Pretty Please??? :D On 1/10/2013 9:49 PM, guilhermebla...@gmail.com wrote: Stas, I totally agree and Pierrick and I faced all these problems during the creation of patch. If PHP doesn't all have support required for a given feature, let's just not only discuss feature, but also the required support too. Named parameters is a great example. I'd also name another one, ReflectionNamespace; namespaces are converted to strings and attached to their classes during compile time and you can never reflect over them to grab for example their names. I even mentioned to Andi back in 2010 that ZE gets re-written every 5 years. That happened in 2000, 2005 and we're now hitting walls because of "monster" changes required to implement feature A or B. Maybe it's time to consider a rewrite again? Cheers, On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev wrote: Hi! I strongly suggest to anyone following the (too many) threads about annotations to try the C# annotation and see what it allows. It goes As far as I can see, C# annotations rely on two very important things: 1. Compiler support. Compiler really knows a lot about what annotations do. 2. Extensive library support. Annotations themselves are just passive metadata, what makes them work is .net framework that uses them. This means to make annotations as useful in PHP we would have to have substantial support in the engine (including bytecode caching provisions, etc.) and some libraries that require very latest-and-greatest version of PHP. Another thing is that we're not having some features that are used extensively in C# annotations, main being named parameters support. I am saying this not to oppose the idea of annotations or the idea of looking into C# and other languages (actually, I think anybody who talks about it should look at least into what C# and Java do with it - and also what Python does, which is completely different direction, just to know other options). I'm just saying porting this to PHP may be less than straightforward. -- 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 -- -Clint -- -Clint
Re: [PHP-DEV] PHP is not ...
I can't disagree with some of your sentiments, that new things are being developed while there are some "old things" that are incomplete or in dis-repair. Unfortunately, PHP being developed as it is, there are only so many people able to work on the core. My own story with php-core was like this. I personally started using accessors in other languages long ago and I was forced to use __get() in php in order to have any sort of lazy loading or dynamic calculations. My own large project has grown to the point where there are a few __gets() that are just ridiculous in size and that's when I decided to check out if PHP was ever going to get accessors so that I could properly compartmentalize my code. I found that Dennis had written an RFC several years before but never had the time (or possibly the ability, not sure) to write it. I had started with C and C++ some 20 years ago, but hadn't written in it in 8 or 9 years. I had talked with Dennis about the original proposal and he helped me a bit w/ the internals list/ideas/processes at the beginning, but really it was up to me to get it done. So I stepped up and made it happen, it's been a long road, the worst of which has been both the RFC process (everyone has a voice, nobody has authority) and the lack of help for the tough problems I encountered. My point is there are only so many people that work on the core and if they are not interested in improving it in the ways that you are, then you need to step up and do it yourself. Learn C if you must, it has some sharp edges but it's not an alien language. It's nice to sit and point at all the problems, but if you can't fix them yourself and you can't convince someone who can to do it, then maybe it's time to step up and learn how to do it yourself, then everyone can benefit; that's what I'm doing. -Clint On 1/11/2013 6:25 AM, Florin Razvan Patan wrote: Hi Arvids, This is exactly what I've stated yesterday here, you can read it at http://news.php.net/php.internals/64820 but I've yet to receive an answer for it. The problem is that someone will actually need to implement the whole thing again, in C, again, and it's going to be painful (again). I can only say that I'm really sorry that I don't know C in order to be able to contribute. This is indeed a sensible subject and I wouldn't want to be hated by the current developers / contributors but like I've said, at some point it must be addressed. Best regards, Florin Florin Patan / @dlsniper On Fri, Jan 11, 2013 at 2:06 PM, Arvids Godjuks wrote: I have to agree with Lester. It seems that there is a conspiracy to push annotations into PHP :D No, really, it's like goons decided that PHP needs annotations no matter what and just flooded the mailing list. I think: "The line must be drawn here, this far, no further!" © Star Trek Before adding more major stuff we should cope with what was already added and get it into shape. Traits are getting a rewrite for the 5.5 release and APC can't catch up because of the traits. This is the first big problem that needs to be solved. Unicode is the second big problem. As far as I know there was some work done on mb_string like enabling func_overload by default, but there are functions missing that are in standard string extension. Just continue on course and get more people involved. Maybe make a roadmap and try to stick with it. 3rd problem is PDO. It lags behind for years and as far as I know from the words of Perrie, no one is willing to touch it and it's a mess. I will not even start on the fact that it lacks tons of functionality and is extremely limiting when you start to do some serious stuff. The fact that virtually every framework bases it's DB layer on the PDO makes it even worse - a fast comparison between PDO and mysqli shows how limiting the PDO is. Just an example, mysqli has mysqli_ping. You can't do that in PDO, so I had to send a query "SELECT NOW()" every 10-15 seconds to the MySQL server to keep the connection alive. Because when PDO looses connection, it gives you an error and you can't just reconnect and continue. Oh, the PHP function API issue, like array vs string. Huge amount of improvements can be done here. This is just what gets into mind and I stumble upon regularly. Maybe these problems should be addressed first before adding more stuff? Arvids. -- -Clint
Re: [PHP-DEV] A remark about PHP's Vision and new things.
Oooh, a rewrite? Can we write it in an object oriented language this time? Please? Pretty Please??? :D On 1/10/2013 9:49 PM, guilhermebla...@gmail.com wrote: Stas, I totally agree and Pierrick and I faced all these problems during the creation of patch. If PHP doesn't all have support required for a given feature, let's just not only discuss feature, but also the required support too. Named parameters is a great example. I'd also name another one, ReflectionNamespace; namespaces are converted to strings and attached to their classes during compile time and you can never reflect over them to grab for example their names. I even mentioned to Andi back in 2010 that ZE gets re-written every 5 years. That happened in 2000, 2005 and we're now hitting walls because of "monster" changes required to implement feature A or B. Maybe it's time to consider a rewrite again? Cheers, On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev wrote: Hi! I strongly suggest to anyone following the (too many) threads about annotations to try the C# annotation and see what it allows. It goes As far as I can see, C# annotations rely on two very important things: 1. Compiler support. Compiler really knows a lot about what annotations do. 2. Extensive library support. Annotations themselves are just passive metadata, what makes them work is .net framework that uses them. This means to make annotations as useful in PHP we would have to have substantial support in the engine (including bytecode caching provisions, etc.) and some libraries that require very latest-and-greatest version of PHP. Another thing is that we're not having some features that are used extensively in C# annotations, main being named parameters support. I am saying this not to oppose the idea of annotations or the idea of looking into C# and other languages (actually, I think anybody who talks about it should look at least into what C# and Java do with it - and also what Python does, which is completely different direction, just to know other options). I'm just saying porting this to PHP may be less than straightforward. -- 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 -- -Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
On 1/10/2013 6:57 PM, Nikita Popov wrote: Even more generic, we just could use existing ReflectionProperty like this (this is standard API, no changes needed): (new ReflectionProperty(get_parent_class(), 'foo'))->setValue($this, $val); Yes, this is even more long-winded, that's why maybe we should have shortcut function for it. Depends on how frequently in practice we expect to do it. I like this idea as a solution to the problem. It would be ideal if parent::$foo would work but since that is not currently a reasonable option, either leaving the user land programmer to use reflection to do it or to provide them with a shortcut way to do it is a good interim solution to the problem. I'm not sure that we really even need a 'shortcut' to do it, we'd need some other people to chime in on that and how often the parent accessor would want to be called. > I know that this is not an optimal solution, but I would much prefer > this over some new syntax like "parent->foo". Once (if) static I like this approach more too. +1 as well > properties have better engine support we can switch to the cleaner > parent::$foo way. But until then I think that this is a good compromise, I'm afraid we couldn't though since parent::$foo already means something else - it's a static property "$foo" of the class that is parent of current class. We could redefine it in this specific context, in theory, but that would be strange special case and I don't think it would be good idea to do that. Our syntax kind of assumes the object has only one class and all properties belong to this class, so we don't have a proper syntax to express the idea of "same property, but with different scope". I try to see :: as a scope resolution operator rather than a static access operator. For methods that's how it works (you can call instance methods with it in a different scope, e.g. parent scope). So doing the same for properties isn't far off. But yes, I do agree that this would be rather tricky and could open another big can of worms (like we have with method calls from incompatible contexts), so it might not actually make sense to go down that path. I agree with that general sentiment as :: as a scope resolution operator, it's just that right now, for ::$ that always translates to static property access which is the current conundrum. > This is just a rough idea of what I'd do. The exact way this would work > still needs further discussion. E.g. one could make passing the property > name optional and assume the current property as default. Or one could If you assume current property you'd have to store it somewhere to pass it and have API for that function to extract it, which sounds like very tight coupling for this function. Maybe something like __PROPERTY__ would be better? The current property can be obtained through EG(current_execute_data)->function_state.function. This holds the accessor function and the property can be taken from its name. Though this is obviously all a bit dirty and is probably not a good idea. Probably better to let people explicitly pass the property name. Nikita Is everyone okay with a long winded way to get/set the parent accessor if necessary? (new ReflectionProperty(get_parent_class(), 'foo'))->setValue($this, $val); Alternatively, reflection in some cases takes an object instance (ReflectionObject), we could extend ReflectionPropertyAccessor so that it could take an object, then something that is slightly shortened would work, like this: (new ReflectionPropertyAccessor($this, 'foo'))->setValue(45); That presently doesn't work, but could be made to work, especially considering it's a new sub-class anyways. If we don't like setValue() being different b/w ReflectionProperty and ReflectionPropertyAccessor we could upgrade both classes to accept an object instance as its constructor argument... -- -Clint
Re: [PHP-DEV] [RFC] Reflection annotations reader
This version of annotations (attributes?) is much more interesting than
the most recent version, but I could see this syntax as being a problem
if it were allowed to apply to plain functions because then the parser
would have difficulty distinguishing from an array. I suppose the same
could be said of applying it to a class.
In essence though, this prior revision is exactly the kind of thing that
I would be interested in if we could get past the parsing issues...
On 1/9/2013 1:57 PM, guilhermebla...@gmail.com wrote:
Pierrick, before update v3 of patch, let's first clarify things that need
to be discussed.
Rasmus, you have no idea how happy you made me for a gentle comment
pointing something we should think before propose a patch instead of on
(sorry for the wording) bitching about the idea.
There're tons of elements that need to be addressed before working on a
patch.
The latest annotations RFC is a small subset of what other languages
support. To a more complete feature-wise, it is required to go to a
previous revision: https://wiki.php.net/rfc/annotations?rev=1302087566
Some of the elements that needs to be considered:
- Should we support nested annotations?
- How [Foo()] will be different from new Foo()? If they are not different,
is there an alternative to not bloat lexical parsing?
- How parameters would be injected? Is constructor the only way to inject
parameters?
- How would we handle optional parameters, like [Foo("bar", null, null,
"woo")]?
- Suppose you wanna fix the optional arguments by named parameters, like
[Foo("bar", test="woo")]. Doesn't it diverge with PHP interests of not
supporting parametrized arguments? Should we modify the former or the
later? Personally I'm a fan of named parameters.
- How would we deal with inheritance? Should a method, for example, inherit
the same annotations from parent or not?
- Suppose that you define annotations to fix the inheritance problem, how
would it be?
- How would we cast possible usages of an annotation to only class, method
or property? Using annotations too?
- How would it be the syntax to declare a new annotation?
- Would it be possible to modify an annotation value using Reflection, for
example?
- How could it be handled on APC to minimize the performance impact?
Let's discuss? Thanks.
On Wed, Jan 9, 2013 at 2:24 PM, Marco Pivetta wrote:
@Stas we've already come to that, and this is a way to store metadata: the
discussion here is just if and how it should get to PHP :)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] - "attributes" rather than "annotations"
I was just looking into C# attributes at the time since I had used them
in the past.
It was a loose translation to something for php from the example on this
page:
http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.stringlengthattribute.aspx
In essence the example would be something along the lines of "$s must be
a string with length exactly 4 and if not, trigger_error() with the
given error message and error level.
One of the beautiful things about the C# way of attributes is that they
can be user-defined, so long as they are written to the API for C#
Attributes.
A similar type of thing could occur for PHP, the recent use case of
Nullable for Type Hints would be a great use of such attributes, but
there are dozens of other uses for them, especially if implemented in a
way similar to C#.
On 1/9/2013 10:42 AM, Stas Malyshev wrote:
Hi!
class a {
[php:Param($s) = StringLength(4, ErrorMessage='Parameter $s length
cannnot exceed 4.', ErrorLevel=E_USER_ERROR)]
public function foo($s) { ... ]
}
What this is supposed to do?
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision
Just a thought here, but perhaps what PHP needs now is a working group that works together to do some basic management of PHP as a language, take into account what the users are wanting, talking about, requesting and setting a vision and direction and make plans for what will and won't and when. In short I think PHP lacks direction because "everyone has a voice" and "nobody has authority." In the last two years of working on property accessors I think I have found this to be the most dis-tasteful aspect of working on the project, no person, document or group that leads. On 1/9/2013 11:45 AM, Anthony Ferrara wrote: Stas, On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev wrote: I seriously hope it never comes to this in PHP Would you shut up with this rhetoric already? All it does is show that you're completely and utterly out of touch with the reality of modern development. Frankly, I'm getting sick and tired of seeing these recurring themes of "PHP is not java" and "I never want this". If you never want this, then don't contribute to the discussions at all. If you have solid feedback to provide, then provide it. But saying "We're supposed to be simple language for doing cool stuff on the web" shows you have no idea what people have been doing (or don't want to acknowledge) with the language for the past 5 years. And that brings us to the root of the problem. Discussion like this is due to the fact that there's no clear "official" vision for PHP. Each participant brings their own concept and vision, and treats it like it's everyone else's vision as well (which is the exact reason for your reply). The need for voting is a byproduct of this lack of vision, not a requirement in its own right. For all the problems that a Benevolent Dictator brings to a project, this is not one of them. This is a case where a dictator that sets the vision in clear and unambiguous terms would actually improve the process quite significantly. Instead of worrying about voting or everyone doing what they want, there's a benchmark to measure proposals against. For example, imagine these different visions for PHP (which I know for a fact are shared on this list): 1. "PHP Should Strive To Be A Full Featured Object Oriented Language". In this context frame, things like annotations, mixins, generators, etc become the focus. As would moving the error handler to exceptions. And a host of other changes (boxing primitive types when treated like an object, etc). Adding functions like array_get_whatever would be frowned upon... 2. "PHP Should Remain A Procedural Language WIth Some OO Features" In this context frame, a lot of the stuff I said above goes away. And adding new array functions would be the norm. And it's plain to tell that exceptions shouldn't be implemented for errors. 3. "PHP Should Be Implementation Neutral, and Support All Paradigms Equally". This is as close to the current implementation as we currently are. We support procedural, OOP and functional constructs. But how deep does it go? Where's the line. PHP NEEDS a vision. It needs something to guide development. Not everyone will agree with it. And that's the point. It levels the playing field for contributions and discussions. Rather than every developer playing for themselves and saying "I hope this never happens", it puts it in the context of "I don't believe this fits our vision". Note the difference in tone between them. It's an ongoing joke about how abusive and unproductive the internals list is. I for one am sick of it. And rather than keeping ignoring it (or walking away), I'd rather see it fixed. Anthony -- -Clint
Re: [PHP-DEV] - "attributes" rather than "annotations"
We should probably be referring to this type of syntax as attributes
rather than annotations since annotations are currently defined in
docblock comments and are recognized by certain software and utilities.
Whereas annotations have no effect on compilation or at runtime,
attributes do have the possibility of affecting compilation or runtime.
I like the idea of having a schema parameter like metadata: as that
would allow php to reserve php: for example. Almost like a namespace,
in fact it could actually be a namespace, such as:
class a {
[php:Param($s) = StringLength(4, ErrorMessage='Parameter $s length
cannnot exceed 4.', ErrorLevel=E_USER_ERROR)]
public function foo($s) { ... ]
}
I also think that providing no schema should be allowed as well, such as:
[: ... ]
We could, again, model this after the C# model whereby user-land
attributes may be defined, PHP could also provide it's own standard ones.
The only reason I mention C# here is that it's been in wide use for some
time now.
On 1/9/2013 6:03 AM, Yahav Gindi Bar wrote:
On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps wrote:
Hi,
I agree here, I think the above, if possible would be best. In my
mind annotations should proabably be limited in scope to class
declarations and thus only before a class keyword, before a property
or method declaration.
In none of those scopes would [ ] be a parsing issue I believe...
The one case would be at the beginning of a class, but if simply
added something such as:
[:SomeAttribute(xyz,abc),**SomeAttribute2]
It could never be confused with short array syntax and is still brief.
I think when implementing real annotations, then it should be possible to
declare arrays in it. So I think the square brackets don't work.
[Foo([1,2,3])]
Cheers,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
But the colon prefix won't cover this case?
You can, as I've mentioned in my post at the doc-block parser discussion,
use a keyword inside the brackets to symbolize annotation, for example
[metadata: Key]
[metadata: MaxLength(10)]
[metadata: Relations(["foo", "bar", "baz"])]
public $id;
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] - True Annotations
Just starting a new thread here to discuss true annotations vs a
DocBlock Parser:
RFC Referenced:
https://wiki.php.net/rfc/annotations
On 1/9/2013 2:09 AM, Peter Cowburn wrote:
On 9 January 2013 01:08, Rasmus Schultz wrote:
I've started working on a new proposal, but I'm getting hung up on the
syntax - if we can't use angle brackets anymore, what can we use? Virtually
every symbol on a standard US keyword is an operator of some sort, does
that mean those are all out of the question?
e.g. thinking of concrete possible basic syntax, neither of the following
delimiters would work:
[Foo('bar')]
Why would this not work? I'm struggling to think of a place where one
would want to use an annotation where it could be misinterpreted as an
array literal. If anything, the visual "conflict" or association with
the array syntax is a good thing in my book: my brain parses it as an
array of one or more annotations.
I agree here, I think the above, if possible would be best. In my mind
annotations should proabably be limited in scope to class declarations
and thus only before a class keyword, before a property or method
declaration.
In none of those scopes would [ ] be a parsing issue I believe...
The one case would be at the beginning of a class, but if simply added
something such as:
[:SomeAttribute(xyz,abc),SomeAttribute2]
It could never be confused with short array syntax and is still brief.
--
-Clint
Re: [PHP-DEV] [RFC] Reflection annotations reader
If we had true annotations, its certainly something the engine could put to use... See my previous post in this thread. -Clint On Jan 8, 2013, at 7:38 PM, Rasmus Schultz wrote: > To summarize: > > A native implementation of PHP-DOC block parser for run-time purposes > (annotation libraries) is already available in the Reflection API, and > already goes as deep as it needs to - going beyond simply finding and > extracting the docblocks would make little sense, as every annotation > library has it's own individual syntax, behaviors and features. There may > be a some libraries that could use a native implementation if it happens to > fit their needs, but they most likely won't use it, because (A) they won't > win anything by doing so, and (B) these libraries would become incompatible > with anything other than bleeding-edge PHP. > > A native implementation of PHP-DOC parser for offline purposes > (documentation generators) is already available in userland, does the job > fine, and does not rely on the Reflection API (as someone mentioned) > because loading every class in a large codebase is not feasible. If you > provide a separate PHP-DOC parser, these projects most likely won't use it, > because (A) see above and (B) see above. > > Who else would need to parse PHP-DOC blocks and why? > > Bottom line, who is this feature for, what will they do with it, and most > importantly, why would they use it? > > > On Tue, Jan 8, 2013 at 3:55 AM, Stas Malyshev wrote: > >> Hi! >> >>> First of all, there are already plenty of established userland >>> implementations - so there is really no need for this. >> >> On the contrary, plenty of implementations means there's a need in this >> functionality, and it might be a good idea to have one standard >> implementation if it can cover like 80% of use cases. >> >>> >>> Whatever you decide on in terms of syntax, most likely won't satisfy >> every >>> the needs of every userland annotation library, so at least some of them >>> most likely won't use it. You'd be creating more work for the maintainers >>> of these frameworks, and they don't standard to gain anything from that >>> work. >> >> Since when "it does not satisfy all needs of all users, and some of them >> may end up not using it" is an argument for not including functionality? >> And how it's more work for maintainers if they just won't use it? >> >>> On the other hand, I would be interested in having support for actual >>> annotation syntax (not docblocks) added to PHP. Real annotation syntax >> >> Can we please not hijack the topic? We discussed annotations many times >> already, if you have better proposal than current RFCs please create >> your own RFC (or ask one of the current RFC authors for collaboration) >> and start a new topic >> >> -- >> Stanislav Malyshev, Software Architect >> SugarCRM: http://www.sugarcrm.com/ >> (408)454-6900 ext. 227 >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][discussion] 5.3 EOL
Would this 1 or 2 year period begin from release date of 5.3 or as of around now/vote? -Clint On Jan 8, 2013, at 4:00 AM, Pierre Joye wrote: > On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig wrote: > >> Would a voting option to tie it to the release of a future PHP version, >> rather than a fixed time interval, be appropriate? > > > Like in end it when 5.x is released? Not sure it helps in anyway, but > that's possible already if we choose to begin the EOL cycle with the > release of 5.5 (yearly release). > > 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reflection annotations reader
Just a thought on this, some other languages support attributes which is
similar but could also allow the engine to use them for things. As a quick
example (roughly based on what I've seen in c#) but applied to PHP use case:
class a {
[$date(Nullable)]
public function foo(DateTime $date) { ... }
}
-Clint
On Jan 6, 2013, at 3:58 PM, Yahav Gindi Bar wrote:
> Hi internals!
>
> In one of the discussions (about the "deprecated" keyword, to be specific),
> it was been said that adding ability to read doc-comment annotation could
> be handy. Personally, I really think it can be great.
>
> So, I've created an RFC that propose to improve the Reflection extension by
> adding the ability to read annotations decorated in the doc-comment.
>
> https://wiki.php.net/rfc/reflection_doccomment_annotations
>
> What is your opinion about this?
>
> Regards,
> Yahav.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reflection annotations reader
-Clint
On Jan 6, 2013, at 5:11 PM, Sebastian Krebs wrote:
> 2013/1/6 Yahav Gindi Bar
>
>> On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta wrote:
>>
>>>
>>> I think that our work is to isolate each annotation so it'll be easy to
access, then, it'll be easy enough to write the code that creates
>> "complex
annotations", such as constructors and so on, in userland.
>>>
>>> In fact, there's probably no need (now) to go on and build a full
>>> annotation reader that instantiates classes and does fancy stuff as we
>>> currently do in doctrine/common.
>>> A fast parser is more than enough I suppose. That's our bottleneck
>>> (besides scanning files).
>>>
>>>
>>> Marco Pivetta
>>>
>>> http://twitter.com/Ocramius
>>>
>>> http://ocramius.github.com/
>>
>> So the problem is the syntax which is difference?
>> When wrote this RFC, I just though about basic cases...
>>
>> Though I agree with you that the main problem is the syntax.
>> We can extract the entire doc-comment and only isolate between annotations,
>> so doc-comment like:
>> /**
>> * @Route("/")
>> * @ORM(Key="foo")
>> * @var string
>> */
>>
>> Will be : array( 'Route("/")' => "", 'ORM(Key="foo")' => "", "var" =>
>> "string" )
>> But the question is it really worth it, since you'll probably need to
>> create some sort of "sub-parser" that uses this isolated annotations array
>> and apply on them your syntax.
>
> As a suggestion, that should cover most (all?) cases: The identifier could
> be defined as "between @ and the first non-alphanumeric character" (it
> should probably allow some special like "/", or "\" to allow namespace-like
> annotations). @Route("/") would be array( 'Route' => '("/")'. Now a
> secondary parser only needs to take care about ("/"), but for example it
> can already directly test, whether or not the annotation exists.
>
>
>>
>> That's being said, if we'll see performance improvements, I really think
>> that it's a good solution to start with, since because its not an
>> Attributes, I don't think that we should dictate the syntax for each
>> application. Each application will get the doc-comment annotation and will
>> be able to apply on it its own syntax and fancy stuff... I think that it's
>> the best solution because of BC too.
>
> To throw that in: Multiline-annotations must be taken into account too :)
>
>
> Regards,
> Sebastian
>
>
>>
>> What do you think?
>
>
>
> --
> github.com/KingCrunch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
Bringing up this old issue a bit.
Nothing was ever said of unset? Should unset be benign?
Since unset() is intended to take an action (rather than check on state)
shouldn't an invalid unset (one with a guarded property that doesn't
have a setter) emit a warning?
On 10/30/2012 10:37 PM, Clint Priest wrote:
Would you say the same of unset? Always benign?
On 10/29/2012 2:14 PM, Stas Malyshev wrote:
Hi!
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this->b = $x; }
}
}
$o = new a();
if(!isset($o->b)) {
/* delete files */
}
echo (int)isset($o->b); /* This should return false and not emit any
sort of warning/notice? */
isset should return false, since $b is not set value. It should not
produce any warning. Of course (int) would produce 0 then ;)
I mean specifically, there is no getter defined, therefore the result
if isset is indeterminate and while I can see it not causing execution
No, the result is determinate - it's false. That's the point of isset()
in PHP and that's how it is used in existing code.
to stop I don't see it being a good idea to not warn the developer that
what they've attempted is not correct. Without a getter, isset() is
not a legal call (since the value cannot be retrieved).
isset() should always be legal. This is the way to check if $o->b is
legal.
--
-Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
The problem I see with your proposal is that get/isset/unset could all
bypass the setter which I think is a bad idea.
If the problem is simply this "hidden state" that keeps being referred
to, I thought the solution I mentioned before would be better.
To re-iterate that prior idea is to make it behave identically to __get().
The first call to a getter would initiate the (calling) guard, any other
access outside of the getter from that point forward would return NULL,
but the access by the getter would return the property.
It would stop the infinite loop, stop invalid access, the author could
see where they've gone wrong (a warning could be emitted even) and we
maintain the current solution without introducing more complexity (which
would probably lead to further problems).
For your pro's listed
* I don't think a local variable named $prop (for example) is very clear
that it's going to modify a property of $this, I would expect
$this->prop and that $prop would be modifying a local value.
* That's a misconception that I accidentally let perpetuate because I
wasn't careful when I confirmed your alternate verbiage.
And then it adds the evil's listed.
-Clint
On 1/5/2013 3:03 PM, Steve Clay wrote:
On 1/5/13 2:05 PM, Clint Priest wrote:
I like the alternate idea here, but I'm not sure what advantage it
has over the current
situation?
See the "Pros" I listed. The primary being a clear differentiation
between calling accessors and handling of the storage value associated
with the property.
if an accessor is
already "in the call chain" then it will not be called again and
"standard property rules"
take effect.
I see that as not simpler, and in fact leading to small bugs whenever
getters/setters start becoming complex enough to call outside methods.
Consider this:
class Foo {
public $bar = 2 {
get { return $this->calcBar(); }
}
public function calcBar() {
return $this->bar * 3;
}
}
echo $foo->bar; // 6
Within calcBar, "$this->bar" is the raw property (2), because hidden
state has "unwrapped" (if you will) the property.
echo $foo->calcBar(); // 18
But here, within the first call of calcBar "$this->bar" triggers the
getter. Now, of course, this is a foolish implementation, but within
any method that could be called from the getter/setter, the symbol
$this->bar could mean two completely different things; I think this is
bad.
If, as I proposed, the storage var were only accessible as $prop in
the accessor scopes, that would force authors to pass $prop to any
supporting methods, clarifying intent. $this->bar would *always* be
accessor calls.
In this model, I think infinite-loop-causing recursions would be
easier to spot. If absolutely necessary we could always throw a fatal
error whenever a getter was called twice in the same call chain.
Steve
AFAICT C# strictly separates fields ("properties" in PHP) and
properties (a set of
accessors that emulate a field).
So the RFC provides 3 features (using C# terms):
1. A property API
2. A built-in storage variable so you don't need a separate field
3. Access to the storage variable as if it were a field of the same
name
I think #2 is useful, avoiding the need to make a separate field
just to make properties
read-only or type-hinted. However I think the complexity and
confusion we're running
into is mostly caused by #3.
I think we might be better served by having another way to access
this storage variable.
What if instead, we have the storage var available as $prop inside
all the accessors?
These would be the default implementations:
get { return $prop; }
set($value) { $prop = $value; }
isset { return $prop !== NULL; }
unset { $prop = NULL; }
Pros:
* Makes clear that $prop is regular var access, and that
$this->PropertyName *always*
goes through accessors
* Gives isset/unset full access to the storage var, which allows
doing things that can't
be done via setter/getter. E.g. you could actually implement a
property being "unset",
which would be different from having it set to NULL.
Cons:
* Allows "evil", like having reads affect the storage var.
* Allows authors to hang themselves with recursive accessor calls,
BUT those mistakes
would be apparent from looking at the code.
What functionality possible in the RFC would be lost by this?
Steve Clay
Steve Clay
--
-Clint
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
+1 from me as well. On 1/4/2013 8:41 AM, Nikita Popov wrote: Hi internals! I already brought this up before, but I think the discussion at that time was not very constructive and largely off-topic, so I'm bringing it up again. To make sure everything is clear I wrote an RFC document: https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax This RFC proposes an alternative syntax for typehinting accessors, which will in particular also allow to typehint properties directly, even if no accessors are used (public DateTime $date). What are your opinions on this? Thanks, Nikita -- -Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
I like the alternate idea here, but I'm not sure what advantage it has
over the current situation?
This line of reasoning revealed a difference between what your verbiage
suggestion from a few days ago suggests and what is true.
With the "guards" it's pretty simple what occurs. If an unset
(accessor) is called, and another unset is called on that property, the
same internal function which handles unset is called. In the 2nd
instance, it see's that the unset is already being guarded and so the
ordinary "unset" functionality is invoked.
Therefore, take a look at this gist: https://gist.github.com/4463107
I will need to update the RFC because your previous summary which I took
verbatim I missed being incorrect. It's really, in my book, a lot
simpler to say that if an accessor is already "in the call chain" then
it will not be called again and "standard property rules" take effect.
This is why a getter can get its value directly. It's also why if that
getter calls some other code which tries to "get" the value, that get
also bypasses the getter (which prevents infinite loops).
-Clint
On 1/5/2013 12:06 PM, Steve Clay wrote:
On 1/3/13 5:43 PM, Stas Malyshev wrote:
The whole problem here is that the only reason why it is a problem is
because of the accessors that have hidden state in guards. If it were
regular variables (and for all the API consumer knows, they are) there
Please ignore this if it's been debated before:
AFAICT C# strictly separates fields ("properties" in PHP) and
properties (a set of accessors that emulate a field).
So the RFC provides 3 features (using C# terms):
1. A property API
2. A built-in storage variable so you don't need a separate field
3. Access to the storage variable as if it were a field of the same name
I think #2 is useful, avoiding the need to make a separate field just
to make properties read-only or type-hinted. However I think the
complexity and confusion we're running into is mostly caused by #3.
I think we might be better served by having another way to access this
storage variable.
What if instead, we have the storage var available as $prop inside all
the accessors? These would be the default implementations:
get { return $prop; }
set($value) { $prop = $value; }
isset { return $prop !== NULL; }
unset { $prop = NULL; }
Pros:
* Makes clear that $prop is regular var access, and that
$this->PropertyName *always* goes through accessors
* Gives isset/unset full access to the storage var, which allows doing
things that can't be done via setter/getter. E.g. you could actually
implement a property being "unset", which would be different from
having it set to NULL.
Cons:
* Allows "evil", like having reads affect the storage var.
* Allows authors to hang themselves with recursive accessor calls, BUT
those mistakes would be apparent from looking at the code.
What functionality possible in the RFC would be lost by this?
Steve Clay
--
-Clint
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
On 1/4/2013 4:29 PM, Stas Malyshev wrote: Hi! This shouldn't be an issue because it is not possible to set the property without going through the setter, which would be a type hinted accessor function. It is possible, if this property's guard is set. Since guard works for all code called from inside the setter, if setter is doing something not trivial (meaning, calls any functions, explicitly or implicitly) it is possible to set the property directly. Since the value you are getting is defined by the getter, there are no guarantees there too. So effectively, unless both getter and setter are implicit, this does not give you anything compared to the typed setter. I think I was referring to the possibility I mentioned in another email about a second call to a getter which was already guarded would return NULL and likewise a second call to a setter which was already being guarded would do whatever __set() does...? Ignored? -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Agreed. Some people may actually be using $parent as a variable name, not difficult to imagine. So far parent->foo seems to be the answer. -Clint On 1/4/2013 4:23 PM, Stas Malyshev wrote: Hi! One other possible alternative would be to treat parent "like a variable..." $parent->foo That would be a big BC problem and also require serious changes to handle it (look how $this is implemented - it's not regular variable at all). So $parent is probably a non-starter. -- -Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Uhm.. brain fart. I was thinking $this->$foo was normal when I wrote this up, I would change my last statement from the earlier email to any syntax which did not include a $. That being said then, I think I favor parent->foo the best. One other possible alternative would be to treat parent "like a variable..." $parent->foo On 1/4/2013 5:09 AM, Clint Priest wrote: Speaking of which, parent::foo ( with :: but no $) might work as well, almost *any* character change could work... parent:::$foo parent:$foo parent->$foo parent->foo parent.$foo parent.foo I favor having the $ in some solution though... -Clint On Jan 4, 2013, at 5:04 AM, Clint Priest wrote: Missed that bit... I think that would add two bits of inconsistency though... (Without the $) -Clint On Jan 4, 2013, at 1:18 AM, Stas Malyshev wrote: Hi! A recent suggestion from Stas is to use parent->$foo (note the use of -> rather than ::) I actually proposed parent->foo. parent->$foo implies the name of the variable is "$foo", not "foo" - just as in $this->$foo. Yes, I know it does not match parent::$foo - but I can't do much about it. In any case, better not to add another inconsistency to the list of existing ones. -- 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 -- -Clint
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
This shouldn't be an issue because it is not possible to set the property without going through the setter, which would be a type hinted accessor function. Ergo, an attempt to set the value to an invalid value would cause a fatal error and thus the setter would not be able to then set it to the invalid value. On 1/4/2013 9:15 AM, Levi Morrison wrote: This proposal looks really good to me. It cuts out a lot of syntax and boilerplate for a commonly used case. However, there is one issue that I know somebody is going to raise: Argument: If you change the value of the property without using the setter then `get` could return something that has a type mismatch with the type-hint. If I understand the current RFC for properties correctly, the only place that a property can be directly written to without the accessor is inside of the `__setProperty` method. This almost nullifies the argument completely. The only other place for possible error would be assigning a value in the constructor that does not match the type-hint. However, because we adding a new syntax we *could* disallow assigning a value if it really was that problematic. I do not personally feel that would be necessary. I feel that this argument is not weighty enough to stop the proposal for this improved syntax. -- -Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Speaking of which, parent::foo ( with :: but no $) might work as well, almost *any* character change could work... parent:::$foo parent:$foo parent->$foo parent->foo parent.$foo parent.foo I favor having the $ in some solution though... -Clint On Jan 4, 2013, at 5:04 AM, Clint Priest wrote: > Missed that bit... I think that would add two bits of inconsistency > though... (Without the $) > > -Clint > > On Jan 4, 2013, at 1:18 AM, Stas Malyshev wrote: > >> Hi! >> >>> A recent suggestion from Stas is to use parent->$foo (note the use of -> >>> rather than ::) >> >> I actually proposed parent->foo. parent->$foo implies the name of the >> variable is "$foo", not "foo" - just as in $this->$foo. Yes, I know it >> does not match parent::$foo - but I can't do much about it. In any case, >> better not to add another inconsistency to the list of existing ones. >> >> -- >> 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] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Missed that bit... I think that would add two bits of inconsistency though... (Without the $) -Clint On Jan 4, 2013, at 1:18 AM, Stas Malyshev wrote: > Hi! > >> A recent suggestion from Stas is to use parent->$foo (note the use of -> >> rather than ::) > > I actually proposed parent->foo. parent->$foo implies the name of the > variable is "$foo", not "foo" - just as in $this->$foo. Yes, I know it > does not match parent::$foo - but I can't do much about it. In any case, > better not to add another inconsistency to the list of existing ones. > > -- > 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] [PHP-RFC] Property Accessors 1.2 Updates / Clarifications
Please note that I have updated and clarified v1.2 with some recent feedback: 1) Steve Clay suggested the term Guarded Property and dropping Shadowing. The "Shadowing" section has been renamed to "Guarding," some of the wording was updated and the "For Additional Clarity" was updated with nearly identical wording Steve suggested which I think brings even greater clarity. 2) The parent::$foo issue I recently posted about was changed near the end of the "Overloading Properties" section, which shows the proposed parent->$Milliseconds form. Seeing it color coded in this light makes it even more appealing and apparent I feel. 3) Removal of Accessor section was added. This was brought up as a question as to what happens and I felt what should be done is what is defined there. Other possible alternatives to number 3: 3a) The public $Foo = 5 declaration would not "shed" it's inherited accessors, they would remain or could be re-defined (but not removed). 3b) The public $Foo = 5 declaration would not be allowed with the = 5 and it would not shed its inherited accessors as 3a For maximum flexibility, I favor the proposed solution as it provides for the most flexibility, it would allow sub-classes to re-define a guarded property as a traditional property, or keep it as a guarded property (modifying the getter, adding a setter, etc). On 1/2/2013 5:36 AM, Clint Priest wrote: Here is the updated RFC incorporating the feedback from previous rounds of discussion. https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 I'm posting it for final review so I can move to voting on Jan 7th. Please note that the current fork is not quite up-to-date with the RFC but will be within a few more days. -Clint -- -Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Note, there has been a show stopper of an issue with the current RFC that many minds have been talking about how to solve. The problem is with parent::$foo accessing the parent accessor. In summary, the difficulty is that this is parsed as a static property access and during compilation there is no guarantee that the parent class structure can be accessed (to confirm/deny that it's really an accessor and not a static property reference). This guarantee is not possible because you can define the parent class after the subclass. So... on to solutions that have been discussed and shot down. 1) Change the zend opcodes for static property references to identify the true state at run-time. This would be a "hack" to be certain and has been shot-down for that exact reason. This is also the reason that static accessors has been abandoned for this first iteration of the feature, because static properties are handled entirely differently from object based properties. 2) Rewrite the way static property references work, such that they make calls into zend_object_handler.c, which is probably something that should be done anyways as a separate RFC and project, at which point this problem would probably be trivial to solve. 3) Introduce a new opcode which could somehow solve this problem by introducing an additional step to determine whether its a parent accessor reference or a static property reference. This would also be "hackish" because the proper solution is #2 and beyond the scope of this RFC. A recent suggestion from Stas is to use parent->$foo (note the use of -> rather than ::) Pros: - It should not have any problems being implemented - It would move this RFC to completion Cons: - It does create an inconsistency in that nowhere else (that I know of) does parent->$foo do something. It may also sound like it should work because parent::__construct() works just fine, but that works fine because it goes through a different opcode system than static accessors do. Really, other than doing something like the above, the only other way would be for a getter to access it's parent by calling the function directly, such as parent::__getFoo() but this is undesirable for a number of reasons: 1) It forces the user to access the parent property accessor in a different way than is used everywhere else 2) It forces the user to utilize an underlying implementation detail that is not guaranteed to stay the same (it may change) 3) It's certainly not as syntactically nice as parent->$foo would be. As a final alternative to this problem, we could simply not allow a parents accessor to be used, which I think is probably the worst choice of all. Thoughts? There is a github ticket discussing this issue as well here if you'd like to chime in there on some more technical conversation about this issue: https://github.com/cpriest/php-src/issues/8 If anyone can think of any other way to solve this such that parent::$foo could work, I'm all ears but I'm out of ideas on this one and I think Stas's idea is just fine. On 1/2/2013 5:36 AM, Clint Priest wrote: Here is the updated RFC incorporating the feedback from previous rounds of discussion. https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 I'm posting it for final review so I can move to voting on Jan 7th. Please note that the current fork is not quite up-to-date with the RFC but will be within a few more days. -Clint -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
Not really sure what to say about this, we can either guard against
recursion or not, I see
no reason *not* to guard against recursion except that it could allow
unauthorized direct
access when the guard is active.
I guess a third option could be that if the property is attempted to be
accessed while
being guarded and that access is not from within the accessor, then it
issues a warning (or not)
and returns NULL.
Thoughts?
On 1/3/2013 4:43 PM, Stas Malyshev wrote:
Hi!
I think infinite recursion is a potential issue for lots of logging setups
("let's log
when someone calls the logger!") and situations where you have multiple values
to keep in
sync. The accessor implementation shouldn't try to solve these design problems.
The whole problem here is that the only reason why it is a problem is
because of the accessors that have hidden state in guards. If it were
regular variables (and for all the API consumer knows, they are) there
wouldn't be any question about if we're allowed to read $user->username
or not - if it's public, of course we can read it. So the problem exists
because the hidden state exists. It's not the problem of the code that
uses public APIs in completely legal way, it is the problem of our
implementation that we have hidden state that changes how variable
access works. With __get we mostly ignored it since recursion blocker
leads to the same result as if the variable did not exist - which is the
case for __get anyway, kind of - so it was less explicit. With accessors
it may become more painful.
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/2013 9:33 AM, Steve Clay wrote:
On 1/3/13 5:58 AM, Clint Priest wrote:
class Foo {
public $bar = 2 {
get;
set;
}
}
Consider properties not based on shadowed values:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this->realbar; }
set { $this->realbar = $value; }
}
}
What would be the point of this? Why not just do this:
class Foo {
private $realbar = 2;
public $bar {
get { return $this->realbar; }
set { $this->realbar = $value; }
}
}
Here, initializing the shadow property is useless. It's similar to the
case where you want to have the initial value of a traditional
property be the result of an expression (and you can't because it
would create a chicken-egg problem during construction).
Option 1: The most powerful solution I see is to have an init function
that's implicitly called before first access (and with direct write
access to the shadow property if needed). Consider trying to emulate
the crazy document.cookie API:
class Document {
private $cookieProps;
public $cookie {
get { return /* based on cookieProps */; }
set { /* set some cookieProps */ }
// called implicitly before the first access (not before the
constructor runs)
// and would have direct access to the shadow property.
init { /* set up cookieProps */ }
}
}
Pros: can run any code necessary to initialize the property
Cons: must make a function just to have a default
Option 2: Keep the traditional syntax, but instead of always setting
the shadow property, call the setter with the given initial value
directly before the first access.
Pros: familiar syntax; more expected behavior in some cases
Cons: what if there's no setter?; cannot run arbitrary setup code;
setter can't distinguish between a "user" set and the implicitly set
before first access.
Option 3: A mix of both. The shadow property is always initialized
with the value from the traditional syntax. If needed, you can have an
init that's called before first access.
Pros: For simple shadowed properties, just works as you'd expect and
with familiar syntax; Still allows robust initialization before first
access if needed.
Cons: Author must remember that traditional syntax only useful for
shadow prop.
I like the idea of an init function, but that would have to wait for a
further release I think, or delay this whole project a year.
Adding the ability to specify an = X value to a property with accessors
would be trivial.
Steve Clay
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/2013 8:21 AM, Steve Clay wrote:
On 1/3/13 1:48 AM, Stas Malyshev wrote:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this->date = $x; $this->timestamp =
$x->getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t; $this->timestamp = $t; $this->date = new
DateTime("@$t"); }
}
}
What happens to it? Would it get into infinite loop or will just set the
value twice? What would be the correct way to write such a code (note
I think infinite recursion is a potential issue for lots of logging
setups ("let's log when someone calls the logger!") and situations
where you have multiple values to keep in sync. The accessor
implementation shouldn't try to solve these design problems.
__get()/__set() already implement infinite recursion guards, Accessors
are just doing the same thing.
class UserContext {
protected $user;
public $logger;
public $username {
get() { $this->logger->log("Getting username"); return
$user->name; }
set($n) { $this->user = User::get_by_name($n); }
}
}
class Logger {
protected $ctx;
public function __construct(UserContext $ctx) {
$this->ctx = $ctx;
$this->logfile = fopen("/tmp/log", "a+");
}
public function log($message) {
fwrite($this->logfile, "[$this->ctx->username] $message\n");
}
}
$u = new UserContext();
$u->logger = new Logger($u);
$u->username = "johndoe";
echo $u->username;
What would happen with this code? Will the log be able to log the actual
user name, and if not, how you protect from such thing? $username is a
part of public API of UserContext, so whoever is writing Logger has
right to use it. On the other hand, whoever is using logger->log in
UserContext has absolutely no way to know that Logger is using
ctx->username internally, as these components can change completely
independently and don't know anything about each other besides public
APIs.
What I am getting at here is that shadowing seems to create very tricky
hidden state that can lead to very bad error situations when using
public APIs without knowledge of internal implementation.
Again, the problem is not shadowing (not even in use here) but really
general information hiding. You can create these problems anytime you
have hidden information and interdependent objects, and it's an API
design problem.
Steve Clay
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
Just getting back to you on #1 and #2...
#1: It seems the majority want to have these internally created accessor
functions visible, which they presently are through get_class_methods,
etc. They are currently hidden by Reflection. I favor the latter, as is
implemented in Reflection since an accessor is "like a method" but is
not quite a method. At any rate, unless anyone voices support for
accessors being hidden from the non-reflection methods, then the current
Reflection changes regarding filtering them from getMethods() will go away.
One alternative here is that I could add a parameter to getMethods()
which would either filter or not filter accessors, which would let
whomever work the way they want to. Defaulting to... which way?
#2:
class a {
public $Foo {
get {
echo "Getting \$Foo, __FUNCTION__ = ".__FUNCTION__.",
__METHOD__ = ".__METHOD__.PHP_EOL;
return 5;
}
}
}
$o= new a();
echo $o->Foo;
Outputs:
Getting $Foo, __FUNCTION__ = __getFoo, __METHOD__ = a::__getFoo
5
I will add to the RFC that __FUNCTION__ and __METHOD__ work as expected.
On 1/2/2013 3:08 PM, Clint Priest wrote:
On 1/2/2013 11:08 AM, Steve Clay wrote:
A few remaining questions. The RFC makes it clear that
ReflectionClass::getMethods() does not return internal method names
like __setSeconds.
1. Are these names visible via get_class_methods() / method_exists()
/ is_callable()?
This is the only remaining point of contention but I would expect
however it is resolved, all methods of reflection would match.
2. Inside an accessor, what do __FUNCTION__ and __METHOD__ evaluate as?
I would have to test them but they are methods so they should evaluate
as you would expect, I'll test.
3. What happens if a class/subclass contains a regular method
__setSeconds?
Same thing as a duplicate function declaration error, since that's
what it is, remember that the prefix __ is reserved for php internal
use, if I recall correctly userland code should not be using a double
underscore.
Steve Clay
On 1/2/2013 11:41 AM, Steve Clay wrote:
The RFC does not specify whether it's a fatal error to define a class
(directly or via extends/traits) which has both a traditional
property and accessor with the same name, but I think this should be
prohibited to avoid confusion.
One might expect this to work if the traditional property is private
in a parent class, but I think even if the patch allowed that special
case (I've not tried it), it should not.
As of the current fork there is no difference between a property and a
property with accessors except that a property with accessors will
always route through the accessor methods. In other words a
property_info structure is created for either type.
Ergo, the same rules apply, a second declaration of a property with
the same name will cause a compilation error.
--
-Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/2013 12:48 AM, Stas Malyshev wrote:
Hi!
Within get: $this->Hours can read the underlying property but not write
to it, if it attempts to write, that write would go through the setter.
Within set: $this->Hours = 1 can write to the underlying property but a
read of the property would go through the getter.
Are the accesses also applying to called functions/accessors? I.e.
consider this:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this->date = $x; $this->timestamp =
$x->getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t; $this->timestamp = $t; $this->date = new
DateTime("@$t"); }
}
}
What happens to it? Would it get into infinite loop or will just set the
value twice? What would be the correct way to write such a code (note
the real code of course could be much more complicated and probably
involve dozen of properties with complex dependencies between them).
This recursion is protected in the same way that the code above would be
protected using __get/__set in that the first set::$date locks the
setter, so technically in this case the 2nd call to $this->date = new
DateTime(...); would directly access the underlying date property.
I don't like this personally (because now the $timestamp setter is
directly accessing the underlying $date variable) but this is precisely
what would happen if this same code were implemented with __get() and
__set().
Also, if this applies to functions called from getter/setter (which
seems to be the case from the code, unless I miss something), consider this:
class UserContext {
protected $user;
public $logger;
public $username {
get() { $this->logger->log("Getting username"); return
$user->name; }
set($n) { $this->user = User::get_by_name($n); }
}
}
class Logger {
protected $ctx;
public function __construct(UserContext $ctx) {
$this->ctx = $ctx;
$this->logfile = fopen("/tmp/log", "a+");
}
public function log($message) {
fwrite($this->logfile, "[$this->ctx->username] $message\n");
}
}
$u = new UserContext();
$u->logger = new Logger($u);
$u->username = "johndoe";
echo $u->username;
What would happen with this code? Will the log be able to log the actual
user name, and if not, how you protect from such thing? $username is a
part of public API of UserContext, so whoever is writing Logger has
right to use it. On the other hand, whoever is using logger->log in
UserContext has absolutely no way to know that Logger is using
ctx->username internally, as these components can change completely
independently and don't know anything about each other besides public APIs.
What I am getting at here is that shadowing seems to create very tricky
hidden state that can lead to very bad error situations when using
public APIs without knowledge of internal implementation.
Again this is creating recursion and the same rules that apply to
__get()/__set() apply here, your fwrite() access of
UserContext::$username when called through the getter for $username is
already locked and thus the fwrite() line directly accesses the
underlying property.
Same as before, this is exactly the same behavior you would get with
__get() and __set(). These guard mechanisms were put in place with a
revision to __get()/__set() shortly after they were first released
(first release didn't allow recursion at all).
We could possibly also catch this scenario and either show a warning on
the fwrite() direct access or a fatal error or just allow the direct
access. Since __get() and __set() already work this way, it's probably
fine as-is, even if not perfect OO.
Anyone know what would happen in such a case with another language that
supports accessors? My guess would be infinite recursion... (no guards)...
Within isset/unset: the same rules apply, a read goes through the getter
and a write goes through the setter.
With this code:
class Foo {
public $bar {
get;
set;
}
}
How could I make it set to 2 by default and isset() return true when I
instantiate the class? Currently, I see no way to assign default values
for properties. Is it planned?
In the changing over to accessors being distinct from properties into
"properties with accessors" I had considered this and think it would be
great. Unless I had some trouble with the lexer it should be trivial to
add, would be something like this:
class Foo {
public $bar = 2 {
get;
set;
}
}
Anyone object to this addition to the spec?
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
That has not been covered and it is a problem, just tested it.
Anyone have any preferences on a resolution?
Only thing that really needs to occur is that the function names need to
be unique, we could prefix any capitals in a variable name with an
additional _ such that:
class A {
public $Foo { get; set; }
public $foo { get; set; }
}
Would mean there would be these function names:
A::__get_Foo();
A::__set_Foo();
A::__getfoo();
A::__setfoo();
Along w/ their unset/isset'rs.
This is what happens as of right now:
Fatal error: Cannot redeclare a::__getfoo() in
/opt/php-core/git/trunk-accessor/cpriest/php/quick2.php on line 9
Good catch on that one.
On 1/2/2013 11:52 PM, Steve Clay wrote:
On Jan 2, 2013, at 10:24 PM, Clint Priest wrote:
I've updated the Shadowing section of the RFC which I hope clears this up, it
also includes a slightly modified version of your example at the bottom with
comments.
Updated RFC really helps. The notion of $this->prop access semantics depending
on which accessor you're in seems important for the RFC as I think it will seem
foreign to a lot of devs.
When I make traditional PHP "accessor" methods, I have complete control; if I
want getFoo() to set private $foo without calling setFoo(), I can. Not so with real
accessors. Probably a good thing :)
One more concern, sorry if it was covered already: will case-insensitivity of
methods mean you can't define getters for both $foo and $Foo?
Steve
--
-Clint
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
All great questions Steve, doesn't quite work the way you have here.
Specifically each get/set/isset/unset have their own guards (just like
__get(), __set(), __isset() and __unset()) which means that:
Within get: $this->Hours can read the underlying property but not write
to it, if it attempts to write, that write would go through the setter.
Within set: $this->Hours = 1 can write to the underlying property but a
read of the property would go through the getter.
Within isset/unset: the same rules apply, a read goes through the getter
and a write goes through the setter.
I've updated the Shadowing section of the RFC which I hope clears this
up, it also includes a slightly modified version of your example at the
bottom with comments.
More comments below:
On 1/2/2013 6:28 PM, Steve Clay wrote:
On 1/2/13 6:08 PM, Clint Priest wrote:
Sorry, there was a typo in that RFC there, this line:
isset { return $this->Hours != NULL; }
Should have been with !==:
isset { return $this->Hours !== NULL; }
I've already updated the 1.2 doc to reflect the correct way.
Given what I mentioned above, I'm assuming you did not test this with
the fork, right?
Just based your comments on how it should logically work (with the
incorrect != vs !==?)
I haven't tested the fork. I just borrowed your logic with the typo :)
One last thing about that, the isset/unset with $this->Hours calls
the getter to retrieve
the $this->Hours value, so it behaves as your example below indicates.
The RFC says, "only the accessors themselves may directly access the
shadowed property." I read that as:
Within get, $this->Hours is the raw shadowed property.
Within set, $this->Hours is the raw shadowed property.
Within isset, $this->Hours is the raw shadowed property.
Within unset, $this->Hours is the raw shadowed property.
But you seem to imply:
Within get, $this->Hours is the raw shadowed property.
Within set, $this->Hours is the raw shadowed property.
Within isset, $this->Hours is accessed via __getHours()/__setHours().
Within unset, $this->Hours is accessed via __getHours()/__setHours().
So really the default implementations behave like this:
isset { return $this->__getHours() !== NULL; }
unset { $this->__setHours(NULL); }
Technically this is an accurate translation of what happens with the RFC
example, but this would work as well.
I think the RFC should be much clearer about what property access
actually means within each accessor method, as I expect users to be
very surprised by this behavior.
This is also looks like it could lead to surprises:
Within get, $this->Hours is the raw shadowed property.
Within get, parent::$Hours is accessed via
parent::__getHours()/parent::__setHours().
I'm not sure I understand what you mean here... within get the parent
accessor is accessed via parent::$Hours, internally that is translated
to what you have above but none of this parent::__getHours() needs to be
typed out, parent::$Hours will suffice.
Also, is there no way to access the shadow property within
isset/unset? If not, is there a good reason to not allow it?
Yes, it would bypass the getter and setter which may be dynamic and
never set the underlying property.
Also, do/should multiple property accessors interact? Consider:
class Foo {
public $a {
get { $this->a = 1; return 2; }
}
public $b {
get { return $this->a; }
}
}
$foo = new Foo;
$foo->a; // 2 (but shadowed property is 1)
$foo->b; // 1 or 2?
This would cause a "Warning, unable to set property Foo::$a, no setter
defined." Both of your $foo->a and $foo->b lines would return the return
value of the Foo::$a getter which is always 2.
The reason it would produce that warning is because you do not have a
setter for $a defined and therefore it is read only, even to its-self.
Only the setter may set the underlying value.
Steve Clay
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/2013 4:18 PM, Steve Clay wrote:
On 1/2/13 4:18 PM, Clint Priest wrote:
Omitting isset/unset has the same effect as declaring it without a
body. This is
described in the RFC under Automatic Implementations with this line:
Note that isset/unset implementations will always be provided if they
are not defined or
if they are explicitly auto-defined (as above).
I think the RFC could make this clearer: "isset & unset are always
provided with the default implementations unless the author provides
his/her own."
I can do that, no problem.
Looking closer at the default implementations of isset/unset, I'm
worried these could lead to confusion. Consider this code:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this->Seconds / 3600; }
set { $this->Seconds = $value; }
}
}
The RFC's default implementation is always bound to the shadow
property, so here's what you really get:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this->Seconds / 3600; }
set { $this->Seconds = $value; }
// auto-generated
isset { return $this->Hours != NULL; }
unset { $this->Hours = NULL; }
}
}
Note the resulting behavior:
$t = new TimePeriod;
$t->Hours; // 1
isset($t->Hours); // false !?
unset($t->Hours);
$t->Hours; // still 1
Effectively, authors who don't base their getters/setters on the
shadowed property must be urged to create their own isset/unset
because the default ones would be useless. I'm not crazy about this.
Sorry, there was a typo in that RFC there, this line:
isset { return $this->Hours != NULL; }
Should have been with !==:
isset { return $this->Hours !== NULL; }
I've already updated the 1.2 doc to reflect the correct way.
Given what I mentioned above, I'm assuming you did not test this with
the fork, right? Just based your comments on how it should logically
work (with the incorrect != vs !==?)
One last thing about that, the isset/unset with $this->Hours calls the
getter to retrieve the $this->Hours value, so it behaves as your example
below indicates.
I'd prefer these default implementations:
isset { return $this->__getHours() != NULL; }
unset { $this->__setHours(NULL); }
$t = new TimePeriod;
$t->Hours; // 1
isset($t->Hours); // true
unset($t->Hours);
$t->Hours; // null
isset($t->Hours); // false
Note these also work as expected when using the default get/set
implementations. Of, course, my implementations don't actually *work*
because you can't call an accessor from an accessor...
Steve, are you testing these w/ the fork? Sounds like you are... But
your above sentence is not accurate, you can call an accessor from an
accessor. isset { return $this->Hours !== NULL; } calls the getter for
the value and compares it with NULL.
Steve Clay
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/2013 12:44 PM, Philip Graham wrote:
I am confused by one thing about the RFC. There is a section for default
accessor implementations where you specify an accessor without a body,
however many of the examples omit the isset and unset accessors. I would
assuming that omitting an accessor would provide the automagic
implementation. If this is the case what is the need for the special
syntax? If this is not the case then what is the effect of omitting an
accessor?
Omitting get/set declaration (and body) makes the property read only or
write only.
Omitting isset/unset has the same effect as declaring it without a
body. This is described in the RFC under Automatic Implementations with
this line:
Note that isset/unset implementations will always be provided if they
are not defined or if they are explicitly auto-defined (as above).
I do see that omitting the setter creates a read-only property, however I
think the syntax would be less ambiguous and easier to use by introducing a
`readonly` keyword:
class MyClass
{
public readonly $myProp {
// ...
}
}
This would also eliminate the need for additional syntax for default
accessors. There is one problem I see with this however, what happens when
a setter is provided for a readonly property?
If this has already been discussed, please accept my apologies and maybe
provide a link to the discussion.
This point of contention was discussed ad nauseam and nobody wanted the
read-only/write-only keywords, they were removed from 1.1 -> 1.2
Please see this document:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Which documents all points of contention from 1.1 and what their
resolution was.
Regards,
Philip
On Wed, Jan 2, 2013 at 6:36 AM, Clint Priest wrote:
Here is the updated RFC incorporating the feedback from previous rounds of
discussion.
https://wiki.php.net/rfc/**propertynot
getsetsyntax-v1.2<https://wiki.php.net/rfc/propertygetsetsyntax-v1.2>
I'm posting it for final review so I can move to voting on Jan 7th.
Please note that the current fork is not quite up-to-date with the RFC but
will be within a few more days.
-Clint
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/2013 11:08 AM, Steve Clay wrote: A few remaining questions. The RFC makes it clear that ReflectionClass::getMethods() does not return internal method names like __setSeconds. 1. Are these names visible via get_class_methods() / method_exists() / is_callable()? This is the only remaining point of contention but I would expect however it is resolved, all methods of reflection would match. 2. Inside an accessor, what do __FUNCTION__ and __METHOD__ evaluate as? I would have to test them but they are methods so they should evaluate as you would expect, I'll test. 3. What happens if a class/subclass contains a regular method __setSeconds? Same thing as a duplicate function declaration error, since that's what it is, remember that the prefix __ is reserved for php internal use, if I recall correctly userland code should not be using a double underscore. Steve Clay On 1/2/2013 11:41 AM, Steve Clay wrote: The RFC does not specify whether it's a fatal error to define a class (directly or via extends/traits) which has both a traditional property and accessor with the same name, but I think this should be prohibited to avoid confusion. One might expect this to work if the traditional property is private in a parent class, but I think even if the patch allowed that special case (I've not tried it), it should not. As of the current fork there is no difference between a property and a property with accessors except that a property with accessors will always route through the accessor methods. In other words a property_info structure is created for either type. Ergo, the same rules apply, a second declaration of a property with the same name will cause a compilation error. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
Here is the updated RFC incorporating the feedback from previous rounds of discussion. https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 I'm posting it for final review so I can move to voting on Jan 7th. Please note that the current fork is not quite up-to-date with the RFC but will be within a few more days. -Clint -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Property Accessors v1.2 Consensus Changes
Can anyone who has an interest in this project please review over the "Current Consensus Changes" section of this document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests Lets hear if there are any other concerns, otherwise in the next couple of days I will integrate these changes into the main RFC document and begin work on the changes from 1.1 -> 1.2. Still left open (undecided) is internal accessor method visibility and callability. Primarily this is between Stas and Nikita, I prefer not visible (makes more sense to me) but callable (less difficult to implement, simpler for the code). I would appreciate some more input on this topic from anyone interested. How long is it before 5.5 is in feature-freeze? I'm guessing at this point that this will not make the 5.5 release, but depends on the powers that be. -Clint -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
Yeah, pretty much. I would not say they are "hidden" from the user, they are simply not revealed purposely. (see example below for reason) It's an irrelevant engine implementation detail. They would simply be callable only because they are actually methods. They are not magic methods because their simple existence does not make them accessors. Fatal error: Call to private method a::__setb() from context ''... Or... Fatal error: Cannot set private property a::$b. A user seeing the first error after having defined a property would be like WTF? What is __setb() and why does the engine think I'm trying to call it? As the code is currently written, nearly all errors that would have produced confusing errors such as the former, they produce errors such as the latter, one that makes sense given that they are trying to set a property. Nikita, you and Stas are the two most diametrically opposed on this issue, would you please hash it out and let me know? You all know my position on what I think it should do and I'd just like this to get resolved. -Clint On 11/14/2012 9:35 AM, Nikita Popov wrote: On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest <mailto:cpri...@zerocue.com>> wrote: Been AWOL for a while and getting back to this, doesn't seem like any resolution has occurred, just the conversation has died down. I got the feeling that in the last few mails we actually made some progress and some people agreed with me that __magic accessor methods and a dedicated syntax for them are not combinable semantically. Maybe I got that wrong :/ I would propose that: 1) Internal accessor methods that are defined are callable directly. 2) Said methods are not reflected or revealed by the engine (stack traces, reflection, etc would hide the engines implementation details) I think that with the above, #1 makes it easy as no further changes are required to make that happen, they're already directly callable The current implementation just uses the __ methods internally, but they are not actually magic accessor methods. That's not what Stas wants (as far as I understood). So you would still have to change the implementation to make them true magic methods which can be used independently from the special accessor syntax. and #2 jives with what *most userland programmers* would expect. So with your current plan we would end up with this: a) A dedicated accessors syntax b) which internally stores the accessors as methods with special names c) but those methods are not magic methods, so you can't get the same behavior by defining them directly d) and the methods are hidden from the user e) but he can still call them (even though they don't exist if he asks for them in reflection). All this sounds very odd to me. Nikita :) -- -Clint
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
*sigh*
Which error would make more sense to you Stas...
Given this code:
class a {
public $b {
get() { return 5; }
private set($x) { /* do something */ }
}
}
$o = new a();
echo $o->b;
$o->b = 42;
There are two possibilities at this point. The code base, without all
the work I have done to make the errors make sense will show:
Fatal error: Call to private method a::__setb() from context ''...
Or...
Fatal error: Cannot set private property a::$b.
Which makes more sense to the most people?
On 11/14/2012 10:24 AM, Stas Malyshev wrote:
Hi!
Been AWOL for a while and getting back to this, doesn't seem like any
resolution has occurred, just the conversation has died down.
I would propose that:
1) Internal accessor methods that are defined are callable directly.
2) Said methods are not reflected or revealed by the engine (stack
traces, reflection, etc would hide the engines implementation details)
I think that with the above, #1 makes it easy as no further changes are
required to make that happen, they're already directly callable and #2
jives with what *most userland programmers* would expect.
Anyone disagree?
Yes. I strongly disagree with adding any magic to the engine that messes
with reflection and backtraces and removes methods existing and being
called from it. I think no "userland" programmer would have any problem
understanding that these methods exist and how they work, just as nobody
has problem understanding how __get works. I think adding this magic
complicates both engine code (which will have to be supported for years
to come) and the language, without absolutely any benefit to anybody
except for imaginary people being scared to death by methods that they
themselves defined showing up in the backtrace.
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
Been AWOL for a while and getting back to this, doesn't seem like any resolution has occurred, just the conversation has died down. I would propose that: 1) Internal accessor methods that are defined are callable directly. 2) Said methods are not reflected or revealed by the engine (stack traces, reflection, etc would hide the engines implementation details) I think that with the above, #1 makes it easy as no further changes are required to make that happen, they're already directly callable and #2 jives with what *most userland programmers* would expect. Anyone disagree? On 10/26/2012 5:37 AM, Clint Priest wrote: I'm opening up several new threads to get discussion going on the remaining "being debated" categories referenced in this 1.1 -> 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests Some people are in favor of the internal functions being generated by an accessor declaration should be invisible and non-callable directly. Others are in favor of leaving them visible and callable. *Type 1 ( Userland Programmer )** * As a userland programmer, someone who cares nothing for "how" php works, only how their own code works. If they define an accessor they expect to see an accessor, reflection should reflect that there are accessors and no other "methods" they did not explicitly define. If they were to reflect on all of the methods of their class and see a number of __getHours() they may be confused as to why or where this function came from. From their perspective, they have defined an accessor and "how" that accessor works on the inside is of no importance to them and only seeks to complicate or confuse matters when they are exposed to these "implementation details" of the php language its-self. If you tried to set a value such as $obj?abc = 1 through an accessor which could not be set, you would probably want to see an error like: Warning, cannot set Class?abc, no setter defined. *Type 2 ( Internals Programmer )** * As an internals programmer, you want nothing hidden from you. If an accessor implements special __getHours() methods to work its magic, then you want to see them, you want to call them directly if you so choose. In effect you want nothing hidden from you. In this case you probably don't even want Reflection to reflect accessors as anything different than specially formatted and called methods on the class. This can be understandable because you want all information available to you. You would probably not be confused if you wrote $obj?abc = 1 and got back an error like "Fatal Error: Class->__setAbc() function does not exist. *Unfortunately 80 to 95% of all people who use PHP are of the first type.** * Revealing these internal matters to them would only leave them confused, possibly frustrated and likely asking about it to the internals mailing list to answer (repeatedly). Thoughts? -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
Would you say the same of unset? Always benign?
On 10/29/2012 2:14 PM, Stas Malyshev wrote:
Hi!
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this->b = $x; }
}
}
$o = new a();
if(!isset($o->b)) {
/* delete files */
}
echo (int)isset($o->b); /* This should return false and not emit any
sort of warning/notice? */
isset should return false, since $b is not set value. It should not
produce any warning. Of course (int) would produce 0 then ;)
I mean specifically, there is no getter defined, therefore the result
if isset is indeterminate and while I can see it not causing execution
No, the result is determinate - it's false. That's the point of isset()
in PHP and that's how it is used in existing code.
to stop I don't see it being a good idea to not warn the developer that
what they've attempted is not correct. Without a getter, isset() is
not a legal call (since the value cannot be retrieved).
isset() should always be legal. This is the way to check if $o->b is legal.
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
That's pretty fair, that last statement... As far as an application is
concerned $o->b doesn't exist because it can't be read.
Seems as though some developers are going to want to know when they've
tried to violate it though... I dunno. Personally I would consider it
error or warning worthy because if I made that mistake I would want to
know about it, rather than never been notified of it.
Is there another class of error that would make more sense? Don't most
people turn off E_NOTICE errors? Perhaps emit an E_STRICT?
On 10/28/2012 8:57 PM, David Muir wrote:
On 29/10/12 03:02, Clint Priest wrote:
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this->b = $x; }
}
}
$o = new a();
if(!isset($o->b)) {
/* delete files */
}
echo (int)isset($o->b); /* This should return false and not emit any
sort of warning/notice? */
I mean specifically, there is no getter defined, therefore the result
if isset is indeterminate and while I can see it not causing
execution to stop I don't see it being a good idea to not warn the
developer that what they've attempted is not correct. Without a
getter, isset() is not a legal call (since the value cannot be
retrieved).
I agree with Pierre, isset() should never throw a warning/notice. The
primary use of isset (that I've seen in various code-bases) is to
avoid warnings/notices. Only rarely do I see it used in an expression
to control application logic. The above example should not give a
warning, and should return false. As far as an application is
concerned, $o->b doesn't exist because it can't be read.
David
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
Well I guess this and many of the other issues from other threads are the reasons I had it written the way that it is currently (basically an extension of __get()) but numerous other proposals have muddied the situation. On Sunday, October 28, 2012 2:17:47 AM, Stas Malyshev wrote: Hi! Sorry I guess I should have been more clear. The recursion would prevent the accessor from being called which would allow the ordinary property code to execute, thus accessing the property directly. I This could lead to weird scenarios where the same $foo->bar in random function could call or not call an accessor depending on the stack trace (provided that accessors call out to other functions - which is not frequent but can definitely happen). In case of __get it's harmless since we know $foo->bar doesn't exist anyway, but if we do allow $bar to exist in $foo it might get weird. I'd certainly appreciate some notice/E_STRICT if this happens. Maybe I'd go even as far as issuing E_STRICT on having both $bar and any of the accessors for $bar in the same class - but this of course would scream on the scenario of augmenting existing $bar with accessors - which is legit, unless it gets weird as described above. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this->b = $x; }
}
}
$o = new a();
if(!isset($o->b)) {
/* delete files */
}
echo (int)isset($o->b); /* This should return false and not emit any
sort of warning/notice? */
I mean specifically, there is no getter defined, therefore the result
if isset is indeterminate and while I can see it not causing execution
to stop I don't see it being a good idea to not warn the developer that
what they've attempted is not correct. Without a getter, isset() is
not a legal call (since the value cannot be retrieved).
On Sunday, October 28, 2012 4:02:23 AM, Pierre Joye wrote:
hi Clint,
On Sat, Oct 27, 2012 at 7:39 PM, Clint Priest wrote:
That's basically what #2 is getting at, my only question is, emit a warning
or notice or not?
Technically returning false on an invalid isset() call could be misleading
without emitting some kind of notice or warning about it.
isset is used for this exact purpose, avoid noisy scripts while
testing the existence (instance, init'ed, etc.) of a variable or
property. Raising a notice here sounds wrong, no matter in which
context.
Cheers,
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
On 10/28/2012 2:04 AM, Stas Malyshev wrote: Hi! Stas, you should probably do some research before posting such non-sense: Which part is "non-sense"? I've brought you examples of Python and Ruby not doing exactly what you claim all languages are doing. By your definition, they don't have accessors - as you define accessors as hidden methods that are uncallable and unavailable and not defined as regular methods. In both Ruby and Python they are callable and defined as regular (or regular with some special attributes) method. I've brought you examples of popular languages that don't have this feature at all - Java and standard C++ don't have it. I was wrong on Javascript - though in Javascript, functions work differently from PHP so there's no real relation to the current discussion. By accessors I am simply referring to getters, setters (and in the case of php, issetter and unsetter). I wish it was so, but it was mentioned many times in this discussion that "accessors should be accessors" and that only the situation where accessors are special functions that are not defined as regular methods, are not callable and are hidden from reflection, etc. is the situation where "accessors are accessors". This is not the case in Python, Ruby, MS C++, D and Delphi by your own link - in all these cases, the properties are defined as regular methods (possibly with some special salt added) and no special effort is taken to hide them from any of the language facilities and make them not callable. Of course, there are also examples of languages going the other way - namely, C#, F# and VB - but by no means the claim that I would be hard pressed to find example of the languages which do not implement your notion of "accessors being accessors" is true. For most dynamic languages, the concept of "accessors being accessors" - hidden, non-callable pseudo-methods - is a foreign concept. I see what you're talking about, I felt like you were saying these other languages did not support accessors (getters, setters, etc). Those other languages do not "hide" them, no. This was Nikita's suggestion, I will let her fight for it. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
Hey Larry, Glad you chimed in here on this. I my opinion (author of thingy), they are separate and distinct from data members. More specifically they are getter and setter code that is called when the property is accessed. Using your example: echo $obj->baz; // executes the code "return $this->baz;" and $obj->baz = 4; // executes the code "$this->baz = $value;" So from the perspective of the user of the class, they are just "properties" but internal to the class they are implemented with methods and code. I think everyone would agree that your #1 is definitely not right, however I believe there is not consensus on whether or not these *are* different from properties. To the consumer of the class, they are no different than properties, to the author of the class they are very different. On Saturday, October 27, 2012 9:48:12 PM, Larry Garfield wrote: On 10/27/2012 09:38 PM, Larry Garfield wrote: On 10/26/2012 05:37 AM, Clint Priest wrote: I'm opening up several new threads to get discussion going on the remaining "being debated" categories referenced in this 1.1 -> 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests Some people are in favor of the internal functions being generated by an accessor declaration should be invisible and non-callable directly. Others are in favor of leaving them visible and callable. *Type 1 ( Userland Programmer )** * As a userland programmer, someone who cares nothing for "how" php works, only how their own code works. If they define an accessor they expect to see an accessor, reflection should reflect that there are accessors and no other "methods" they did not explicitly define. If they were to reflect on all of the methods of their class and see a number of __getHours() they may be confused as to why or where this function came from. From their perspective, they have defined an accessor and "how" that accessor works on the inside is of no importance to them and only seeks to complicate or confuse matters when they are exposed to these "implementation details" of the php language its-self. If you tried to set a value such as $obj?abc = 1 through an accessor which could not be set, you would probably want to see an error like: Warning, cannot set Class?abc, no setter defined. *Type 2 ( Internals Programmer )** * As an internals programmer, you want nothing hidden from you. If an accessor implements special __getHours() methods to work its magic, then you want to see them, you want to call them directly if you so choose. In effect you want nothing hidden from you. In this case you probably don't even want Reflection to reflect accessors as anything different than specially formatted and called methods on the class. This can be understandable because you want all information available to you. You would probably not be confused if you wrote $obj?abc = 1 and got back an error like "Fatal Error: Class->__setAbc() function does not exist. *Unfortunately 80 to 95% of all people who use PHP are of the first type.** * Revealing these internal matters to them would only leave them confused, possibly frustrated and likely asking about it to the internals mailing list to answer (repeatedly). Thoughts? Speaking as a user-land programmer that's been following this thread, but hasn't been able to jump in yet due to the high volume of comments... What's unclear to me is what my mental model should be for this new syntax. That's important for informing how it should be exposed to me. 1) Should I have a mental model of this being some syntax candy on top of existing properties? Vis, this is just a short-hand for bean-style classes? By Bean style, I mean Properties that would be public but aren't because Public Is Bad(tm), so instead we have getX()/setX() for every property, so that we can still use the object like a struct rather than an object but still say we're using methods even though we've just reimplemented public properties with more verbose syntax. (Note: Yes, I know that's a rather harsh and judgmental description. I happen to firmly dislike Bean-style objects.) 2) Should I have a mental model that these fancy-pants properties are some different third thingie on objects, distinct from traditional data members and methods? Right now I'm not sure which mental model I'm supposed to use, and I get the sense that there's no clear consensus on that question yet. That, I think, is the key question, and will inform how things like Reflection should expose data about this new syntax. For instance, if model 2 is how I'm supposed to be thinking, then I'd expect I'd need a third reflecti
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
Stas, you should probably do some research before posting such non-sense: http://en.wikipedia.org/wiki/Property_%28programming%29 Every language you mentioned has them. Perhaps the confusion is that I am calling them accessors since other languages refer to accessors as "properties" while PHP refers to "properties" the way that other languages refer to them as "fields" or "data members." By accessors I am simply referring to getters, setters (and in the case of php, issetter and unsetter). On 10/27/2012 3:28 PM, Stas Malyshev wrote: Hi! What is "reflection hiding patches" referring to? Reflection is changed to reflect what the user has defined, that's what reflection is supposed to be.. no? No. Reflection is supposed to show which methods exist on a class, which can be called from certain context, etc. This has nothing to do with where they were defined. Lastly, this idea that accessors is such a foreign concept is a bit ridiculous. You'd be hard pressed to find a modern/popular language these days that doesn't have them, so if someone is confused about what PHP doesn't have them. Also, by your definition, Python doesn't have them - in Python, __ methods are regular methods. Also, by your definition, Ruby doesn't have them either - in Ruby, you define them as regular methods, and you very well can call them too: http://stackoverflow.com/questions/621176/how-to-dynamically-call-accessor-methods-in-ruby#621193. Javascript doesn't have them either. Java doesn't have them either. So I'm not that hard pressed to find languages that don't follow your model, as you can see. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
Sounds like you're implying that the mere existence of a properly named function such as __prop_get_hours() would cause it to be called instead of returning the property. There are several problems with this approach: 1) Currently __get() is only checked/invoked if there is not a property already defined; ie properties shadow __get() (no performance penalty) 2) It would dramatically reduce performance because every property access would have to create the function string, get it's hash value and do a hash look up against the function table, just to see if there is a properly named accessor function. Failing that it would then check for the existence of a property and failing that move on to looking up __get -Clint On 10/27/2012 2:14 PM, Patrick Schaaf wrote: On Saturday 27 October 2012 13:05:27 Clint Priest wrote: That's why I think they shouldn't even be visible to users, they aren't relevant to them and in fact it could mis-lead them into thinking that they could simply define __getHours() and expect $foo->Hours to call it, which it wouldn't. I would expect / want it to do so. I see it this way: Defining semantics for magic methods named __prop_get_XXX, __prop_set_XXX etc as a specialization of __get/__set used whenever they exist for a given $XXX, is in my eyes a complete, proper accessor enhancement, saving me from doing a switch dance in __get/__set. The implementation should be absolutely straightforward, in the place where a missing property now tests for existence of __get/__set, a first, additional test for the specifically named __prop_get_XXX method would be added. Your proposed accessor _syntax_ is purely syntactic sugar, implementable on top of the functionality of the previous paragraph and implemented in terms of automatic code generation for it. This syntactic sugar could be separately implemented, discussed in a separate RFC,etc. The added complexity that I see, and I think Stas has meant to mention a lot of times, is everything - all code and documentation and explanation - that stems from NOT making it that two-step process. And in my opinion that would be completely superfluous, as it brings neither functionality nor syntax, just random additional issues. best regards Patrick -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
Sorry I guess I should have been more clear. The recursion would prevent the accessor from being called which would allow the ordinary property code to execute, thus accessing the property directly. I suppose if it were in a setter and the property were not defined by the accessor then it would automagically create a public property, not that it would matter if accessors always shadowed properties because the access control of the accessor would still prevail. But it could be written such that an accessor would define a private property upon set from within the setter. Recursion guarding in this case simply means that the get/set is guarded from being called more than once. It's the same mechanism that __get and __set use. On Saturday, October 27, 2012 3:20:38 PM, Stas Malyshev wrote: Hi! Recursion is guarded by the same mechanism __get uses to avoid recursion. __get on recursion returns undefined, __set on recursion does nothing. However you're saying "No direct access to the property would be allowed except from within the accessor" - but what this not allowing means? Just returning undefined if __getHours was previously called? -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
On 10/26/2012 6:37 PM, Stas Malyshev wrote: Hi! Stas, if you define an accessor, how do you define it? Do you say Either way, doesn't matter. According to the current proposal at least you can write the first code *and the first code only*. If you write the second code then you That's where I think it is wrong. It would be much simpler and consistent with existing PHP if it were a natural extension of __get instead of a completely new and foreign concept. special behavior for properties. You probably won't start off with telling them that this declaration is automatically converted to a set of __getFoo methods which are registered as handlers for the accessor. I really don't see how going into details like __getFoo makes anything easier. Depending on your purpose and background. If you know how __get works, extrapolating to __getFoo is trivial. Getting special syntax that produces __getFoo from this is also trivial. Getting the concept of methods that are not quite methods and get called only through special intercept mechanism and have special backtrace rewriting engine and reflection hiding patches so you can be inside the method that officially does not exist - not so trivial. The only thing that does back patching is for static accessors and you've already pointed out that what I was doing to make that happen is just going to break and fail in so many ways. What is "reflection hiding patches" referring to? Reflection is changed to reflect what the user has defined, that's what reflection is supposed to be.. no? Lastly, this idea that accessors is such a foreign concept is a bit ridiculous. You'd be hard pressed to find a modern/popular language these days that doesn't have them, so if someone is confused about what an accessor is then they probably have their head in the sand, god forbid they'd have to read the manual. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
That's why I think they shouldn't even be visible to users, they aren't relevant to them and in fact it could mis-lead them into thinking that they could simply define __getHours() and expect $foo->Hours to call it, which it wouldn't. To me, the bottom line is, the fact that there are methods defined by accessors is an engine detail and not something that should be exposed to the user. As for the __set_state() issue, I can see the need to change the pattern of method naming, I'd be amenable to anything. Everyone okay with __get_prop_hours() naming convention then? On Saturday, October 27, 2012 3:01:39 AM, Patrick Schaaf wrote: - i.e. name them __prop_get_xxx, __prop_set_xxx, and so on. I think it'd more natural to make it __set__PROPNAME. Though __set_state is a static method, so maybe we can live with it - except that you won't be able to declare property named $_state. Needing an "except" is inelegant, if it can be avoided up front. Also, having __prop_get_XXX etc. is a bit more descriptive to somebody later "wondering" what these methods are - prop alludes to properties, which is what the methods are about. I can already see the stack overflow subject, "what are these __prop methods in new PHP" :) best regards Patrick -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration
On 10/26/2012 9:39 AM, Stas Malyshev wrote:
Hi!
/* Would be equivalent to this */
class TimePeriod {
public $date {
get() { return $this->date; }
set(DateTime $value) { $this->date = $value;}
}
}
I don't think this has a use case and this encourages mixing variables
with properties (which I'm not sure is a very good idea) and writing
slower and more complicated code which doesn't actually do any
additional work. I'd rather not encourage it. If you want it - fine,
implement it, but I don't think supporting it is good.
I would agree that it should not be in here, AFAIK only Nikita was
pushing for this... anyone else want to fight to have this functionality?
Also, "get() { return $this->date; }" implies there is a thing called
"$this->date" which is not the property itself. So what is it? Should
there be additional "public $date;" declaration in your code? Is it
implied that property definition also creates a variable inside class
automatically - I was under expression this does not happen, and nothing
in the RFC implies it. Should it be $this->__date maybe like in
"automatic accessors" part of the RFC?
This is related to accessors shadowing properties, if that's the case
then $this->date would retrieve an actual property named date (and since
it's shadowed by the accessor it could never be accessed from outside
the accessor. See the shadowing thread.
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
That's basically what #2 is getting at, my only question is, emit a warning or notice or not? Technically returning false on an invalid isset() call could be misleading without emitting some kind of notice or warning about it. On 10/26/2012 9:56 AM, Stas Malyshev wrote: Hi! 1. If all cases can be tested for during compilation, prefer compile failures. Not likely. isset($foo->$bar) is completely opaque since we don't know what $foo or $bar is. 2. Let the compilation occur and at runtime when a disallowed action is attempted, emit a warning and move on. 3. As is currently, either at compilation or at runtime we issue a fatal error and stop execution (probably least preferable if at runtime) Actually, I think the right way is: 4. On isset(), if the value can be retrieved, return true. Otherwise, return false (including the case when the value can not be retrieved because of missing getter). Same holds for empty() but in reverse - if isset() would return false, it'd return true and vice versa. On unset($foo->bar), act exactly as if the code were $foo->bar = NULL; Of course, this applies only for automatic definition of isset/unset. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
Recursion is guarded by the same mechanism __get uses to avoid recursion. On 10/26/2012 9:33 AM, Stas Malyshev wrote: Hi! v1.2 Proposes that this be inverted such that if there is an accessor defined for a given property name, the accessor will always be used. The accessor would be able to get/set/isset/unset the property with the same name as the accessor. No direct access to the property would be allowed except from within the accessor. One of the deficiencies frequently mentioned for __get was "what if I want to override access for existing variable?" Given that, I think accessor priority is a good thing. Now, with direct access from within the accessor it may get a bit tricky, especially considering loops, etc. What would happen in the scenario of __getHours calling foo() which does "return $this->Hours"? Is __getHours called again? Is it a fatal error? Does it return "undefined" like __get does? v1.2 proposal seems to make the most sense however it would incur a slight (possibly *very* slight) performance penalty. It may be an extra hash lookup, but if we could probably add the existence of accessor (or maybe even pointer) into zend_property_info then we wouldn't need the second hash lookup probably. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration
I'm opening up several new threads to get discussion going on the
remaining "being debated" categories referenced in this 1.1 -> 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
*Extra shorthand declaration*
Allow extra short declaration of an accessor:
class TimePeriod {
public DateTime $date;
}
/* Would be equivalent to this */
class TimePeriod {
public $date {
get() { return $this->date; }
set(DateTime $value) { $this->date = $value;}
}
}
Thoughts?
--
-Clint
[PHP-DEV] [RFC] Property Accessors v1.2 : Interfaces
I'm opening up several new threads to get discussion going on the remaining "being debated" categories referenced in this 1.1 -> 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests v1.1 fully allows accessors to be defined in interfaces and requires that those accessors be defined in implementing classes. Some people have suggested that a property defined by the class should also satisfy the requirement. *Arguments For* * From the outside observer of an interface, a class which defines a property has satisfied the requirement, because an interface only defines what must be allowed, not what cannot be done. *Arguments Against* * Additional overhead on interface checking, would only be allowed for a non-asymmetrical accessor * Would give userland developers the ability to write poor code as properties are non-observable (object would not know its property was changed) Thoughts? -- -Clint
[PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
I'm opening up several new threads to get discussion going on the remaining "being debated" categories referenced in this 1.1 -> 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests *isset / unset / attempted writes when no setter / attempted reads when no getter** * Stas suggested that since there is presently no cases where these can fail that with accessors these should never "fail." Three possible ways to go (maybe others): 1. If all cases can be tested for during compilation, prefer compile failures. 2. Let the compilation occur and at runtime when a disallowed action is attempted, emit a warning and move on. 3. As is currently, either at compilation or at runtime we issue a fatal error and stop execution (probably least preferable if at runtime) If "no failures" should be the way we want to go, then #2 or some derivative makes the most sense. Thoughts? -- -Clint
[PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
I'm opening up several new threads to get discussion going on the remaining "being debated" categories referenced in this 1.1 -> 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests Some people are in favor of the internal functions being generated by an accessor declaration should be invisible and non-callable directly. Others are in favor of leaving them visible and callable. *Type 1 ( Userland Programmer )** * As a userland programmer, someone who cares nothing for "how" php works, only how their own code works. If they define an accessor they expect to see an accessor, reflection should reflect that there are accessors and no other "methods" they did not explicitly define. If they were to reflect on all of the methods of their class and see a number of __getHours() they may be confused as to why or where this function came from. From their perspective, they have defined an accessor and "how" that accessor works on the inside is of no importance to them and only seeks to complicate or confuse matters when they are exposed to these "implementation details" of the php language its-self. If you tried to set a value such as $obj?abc = 1 through an accessor which could not be set, you would probably want to see an error like: Warning, cannot set Class?abc, no setter defined. *Type 2 ( Internals Programmer )** * As an internals programmer, you want nothing hidden from you. If an accessor implements special __getHours() methods to work its magic, then you want to see them, you want to call them directly if you so choose. In effect you want nothing hidden from you. In this case you probably don't even want Reflection to reflect accessors as anything different than specially formatted and called methods on the class. This can be understandable because you want all information available to you. You would probably not be confused if you wrote $obj?abc = 1 and got back an error like "Fatal Error: Class->__setAbc() function does not exist. *Unfortunately 80 to 95% of all people who use PHP are of the first type.** * Revealing these internal matters to them would only leave them confused, possibly frustrated and likely asking about it to the internals mailing list to answer (repeatedly). Thoughts? -- -Clint
