Re: [PHP-DEV] SplClassLoader
I suppose what he means is a classloader *implementation*.
Something along the lines of:
function($class) {
return str_replace('\\', DIRECTORY_SEPARATOR, $class) . '.php';
}
2011/6/27 Hannes Magnusson hannes.magnus...@gmail.com
On Mon, Jun 27, 2011 at 12:19, rod r...@pu-gh.com wrote:
Quick question: is there any planned inclusion in PHP for an
SplClassLoader?
What would that class do that the spl_autoload*() functions don't?
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Enum
One thing I would really like to see in 5.4 is enums. There is already an RFC for that: https://wiki.php.net/rfc/enum This was discussed in february this year, but no consensus was reached. IIRC, the most notable problems were: - What is the 'value' of enum constant: string or int, user defined scalar, defaults - Ability to make enums more 'class like', some people wanted to be able to add methods. Another thing which was discussed (and I think most people agreed on that), but is not in the RFC: type hinting in method signatures. I think we should keep this simple proposal simple, let it be an enum in all its simplicity. The toughest part would be to decide what would be the default value. Some proposed to use the name of the constant, which is imho best for debuggability (i like this one the best), or an auto incrementing int, saying that it is better performance wise and which is more analog with mysql's enum type. So, to sum up: - Do we really need enum level methods? - Need to reach consensus on default values (strings vs auto inc. ints) - RFC needs to be updated, explaining the type hinting of enums in method signatures Regards, Dennis Haarbrink
Re: [PHP-DEV] RFC: Enum
As soon as I have my requested write permission in the rfc namespace i will update it. -- Dennis Haarbrink 2011/6/3 Pierrick Charron pierr...@webstart.fr Hi, The RFC was supposed to be a draft (i didn't really added it in the good section) and was written more to introduce the idea and make people think about it. Feel free to update it with any idea, concern you may have. Pierrick On 3 June 2011 03:26, Dennis Haarbrink dhaarbr...@gmail.com wrote: One thing I would really like to see in 5.4 is enums. There is already an RFC for that: https://wiki.php.net/rfc/enum This was discussed in february this year, but no consensus was reached. IIRC, the most notable problems were: - What is the 'value' of enum constant: string or int, user defined scalar, defaults - Ability to make enums more 'class like', some people wanted to be able to add methods. Another thing which was discussed (and I think most people agreed on that), but is not in the RFC: type hinting in method signatures. I think we should keep this simple proposal simple, let it be an enum in all its simplicity. The toughest part would be to decide what would be the default value. Some proposed to use the name of the constant, which is imho best for debuggability (i like this one the best), or an auto incrementing int, saying that it is better performance wise and which is more analog with mysql's enum type. So, to sum up: - Do we really need enum level methods? - Need to reach consensus on default values (strings vs auto inc. ints) - RFC needs to be updated, explaining the type hinting of enums in method signatures Regards, Dennis Haarbrink
Re: [PHP-DEV] RFC: Enum
2011/6/3 Marcel Esser marcel.es...@croscon.com On 6/3/2011 8:27 AM, Dennis Haarbrink wrote: As soon as I have my requested write permission in the rfc namespace i will update it. -- Dennis Haarbrink 2011/6/3 Pierrick Charronpierr...@webstart.fr Hi, The RFC was supposed to be a draft (i didn't really added it in the good section) and was written more to introduce the idea and make people think about it. Feel free to update it with any idea, concern you may have. Pierrick On 3 June 2011 03:26, Dennis Haarbrinkdhaarbr...@gmail.com wrote: One thing I would really like to see in 5.4 is enums. There is already an RFC for that: https://wiki.php.net/rfc/enum This was discussed in february this year, but no consensus was reached. IIRC, the most notable problems were: - What is the 'value' of enum constant: string or int, user defined scalar, defaults - Ability to make enums more 'class like', some people wanted to be able to add methods. Another thing which was discussed (and I think most people agreed on that), but is not in the RFC: type hinting in method signatures. I think we should keep this simple proposal simple, let it be an enum in all its simplicity. The toughest part would be to decide what would be the default value. Some proposed to use the name of the constant, which is imho best for debuggability (i like this one the best), or an auto incrementing int, saying that it is better performance wise and which is more analog with mysql's enum type. So, to sum up: - Do we really need enum level methods? - Need to reach consensus on default values (strings vs auto inc. ints) - RFC needs to be updated, explaining the type hinting of enums in method signatures Regards, Dennis Haarbrink If I might raise the question, I am also really interested in how enums could respond across namespace. Personally, I am not entirely sure about the ability to add methods to enums. That sounds like a class, to me. However, the second example on the RFC of use-case, wherein the developer uses a class to contain constants, sounds to me like a namespacing issue. Would enums be objects that are within the scope of the namespace, like classes, or would they be global? I would personally favor they remain in the scope of the namespace. That removes the need to prefix them with any sort of pseudo-namespace (like a class, for example), and it prevents collisions, of course. - M. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I'm also not so sure about inlining an enum in a class. I think they should always be first class citizens. And as such they adhere to the same namespace rules as classes. Maybe Pierrick can clarify his intentions. -- Dennis Haarbrink
Re: [PHP-DEV] RFC: Enum
2011/6/3 John Crenshaw johncrens...@priacta.com As much as I used enums in C++, I'm not sure that this is really the right tool here, and it often introduces more problems than it solves. Specific concerns that come to mind: 1. In C++ this often led to nasty needs such as a LOG_LEVEL_COUNT entry at the end of the list of enums. 2. Sometimes devs want to add items in the middle of the list for code organization purposes. This silently changes the values of the other constants and it isn't clear when that will or won't break stuff. 3. Better than half the time, enums seem to be a series of bit flags, not sequential numbers (in this case enum offers NO value over the current const lists). 4. The greatest value of enums in C++ is actually related to typesafety. Admittedly, this was sometimes more of a frustration than a help, but that was really just an implementation issue, not an inherent problem with enums and typesafety. 5. There is no clear path for extending the enums through inheritance. Allowing enums to be (optionally) named would open a clear path to address counts and hinting, but still doesn't address the problems inherent in automatic numbering, and would complicate the inheritance question. IMHO this should wait until we can address some of these items. Otherwise the feature is just a halfbaked not-so-short shorthand for constants. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 1. I'm not so sure what you mean with that statement 2. A very strong argument for using the name of the constant as the default value 3 and 4: The way I see it, type safety is the *only* valid argument for proposing enums 5: I have never felt the need for inheritance in enums. Do you have a use case for that? I also think that enums should always be named. -- Dennis Haarbrink
[PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
-Oorspronkelijk bericht- Van: Stan Vass [mailto:sv_for...@fmethod.com] Verzonden: maandag 1 november 2010 10:19 Aan: internals@lists.php.net Onderwerp: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON Urgentie: Laag It's amazing to me this has become such a long discussion. The facts are simple: 1) People don't ask for the other parse errors even half as often as they as for T_PAAMAYIM_NEKUDOTAYIM 2) They do so because it looks like gibberish to them, so it looks unlikely to be a common thing you can Google, nor it gives something recignizable to start with 3) Yes, to all who are not sure, more people know English than Hebrew. 4) Yes, we all acknowledge it's an easter egg joke that refers to the creators of PHP. But that particular joke has outworn its welcome in the community after repeatedly causing support issues. T_DOUBLE_COLON already exists as a constant in userland, so the jump to it won't be an epic change. Let's do it as a proof that we're not a nerd gridlock bound to argue forever about even the most minor and obviously positive changes PHP can implement. Stan Vass -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Come on people, what exactly is the problem with a once-in-a-lifetime investment of 5 seconds of your time to google some stupid error message. Something you, as a developer, spend your life doing. Please, stop complaining about a minor (yes, it is minor, use the fricking search engine!) annoyance and accept php's heritage. And please understand, I do get where all the opponents are coming from, it is an unnecessary complicated error message (I agree that the language argument is a moot point, in the world of internet and programming in particular, English is the standard), but you google it once in your life and then you 'forget' about it. And if you can't remember the meaning of something like that, I hardly doubt you'd be a decent programmer anyway. Regards, Dennis Haarbrink
RE: [PHP-DEV] [RFC] Array Dereferencing
-Oorspronkelijk bericht- Van: Lars Schultz [mailto:lars.schu...@toolpark.com] Verzonden: dinsdag 8 juni 2010 16:04 Aan: internals@lists.php.net Onderwerp: Re: [PHP-DEV] [RFC] Array Dereferencing $result = new ResultMaker()-getIt(); I know that this is not much of an argument, but it works the same way in Javascript too, which is very convenient. The intended behaviour is obvious...even though it could be (mis-)interpreted by php. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I agree, this is obviously the intended behaviour. As long as the door is still open to do: $result = new (ResultMaker()-getIt()); To create an object of the class returned by the getIt() method. -Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Obscure token name
-Oorspronkelijk bericht- Van: Martin Jansen [mailto:mar...@divbyzero.net] Verzonden: donderdag 29 april 2010 14:07 Aan: mathieu.suen CC: PHP internals Onderwerp: Re: [PHP-DEV] Obscure token name On 29.4.2010 13:13, mathieu.suen wrote: Johannes Schlüter wrote: On Mon, 2010-04-26 at 16:32 +0200, mathieu.suen wrote: I am wondering why is the token name so incomprehensible ? Like T_PAAMAYIM_NEKUDOTAYIM... I don't mind if we change the name in the error message. Seems to be an issue for some ... but I think you have to look it (quickly) up the The question is that I want to understand error messages. I can google it but that is not a good way of doing things. Folks, can't you just accept that T_PAAMAYIM_NEKUDOTAYIM is intended to make you smile? There's nothing to see here, please move along. - Martin +1 I remember 'back in the days' when I first saw this error. I googled it, learned what it meant and never forgot it since. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
of its big powers and that should remain unchanged. But the way I see it is that it can be implemented without *requiring* you to use it, if you want to use type hinting/casting go ahead, if you don't want it, well, leave that bit alone. If it comes with a minor performance hit, OK, i can live with that, I agree with Lukas in that aspect, you don't spend lots of time checking/casting anyway. As for hinting/casting would not be 'php-ish', i don't see it that way, i look at php as a language of possibilities, not restrictions. As I said, i'm a framework developer and it would greatly improve readability, usability and quality when you can use type hinting/casting. Consider a pretty common architecture where you have a service layer which does validation and stuff and then passes control to 'deeper' parts in the framework. Your service layer could have a casting hint, while the more inner components could have a strict hint. There you can trust the data is of the type you wanted, otherwise there is something wrong anyway. The most important thing is that it is _optional_, you have the _choice_ to use it. Regarding syntax, to me it is totally intuitive that foo((int) $bar) tries to do a cast and foo(int $bar) is strict, it's also easy to explain to students, put parenthesis around your type name and it's a cast, whether it is in an assignment or a method declaration it doesn't matter. Seeing the discussion I think there is consensus it shouldn't be in 5.3. I think it shouldn't be in 5.x total, the 5.x branch is already _loaded_ with lots of new cool stuff and in my opinion all focus should be on getting a 6.0 release asap. I know, i'm 'just' a php user but maybe I can inspire someone in taking the 'right' course. Regards, Dennis Haarbrink -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
Hi Paul, -Oorspronkelijk bericht- Van: Paul Biggar [mailto:paul.big...@gmail.com] Verzonden: donderdag 9 juli 2009 13:03 Aan: Dennis Haarbrink CC: internals@lists.php.net Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion Although the proposed checks are optional, nobody has a _choice_ to use a new language feature. Though you may choose not to use a feature in your code for whatever reason, it will appear in code from your colleagues, clients, or upstream libraries. Every feature in PHP will at some point be put in front of every PHP developer. I don't think this is a really valid argument. I mean, libraries may have all kinds of quirks, you may not be satisfied with the supplied API or maybe even the entire philosophy behind it, but that shouldn't stop you from using it or is it? Regards, Dennis Haarbrink -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
Lukas, -Oorspronkelijk bericht- Van: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] Verzonden: donderdag 9 juli 2009 14:01 Aan: Dennis Haarbrink CC: internals@lists.php.net Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion I think you misunderstood Zeev. He wasn't saying that this feature is not PHP-ish, he was specifically talking about strict type checking. regards, Lukas Kahwe Smith m...@pooteeweet.org Although I replied to Zeev's message it was more of a general observation than directly aimed at him. Regards, Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Type hinting - Request for Discussion
-Oorspronkelijk bericht- Van: Paul Biggar [mailto:paul.big...@gmail.com] Verzonden: donderdag 9 juli 2009 14:40 Aan: Dennis Haarbrink CC: internals@lists.php.net Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion You must learn what these quirks are. Likewise, every developer must learn the quirks of the type hinting as they will almost certainly be required to interact with code that uses it. In an extreme case, suppose that we completely balls-ed up the semantics of type checks to be really really hard to use, but people used them anyway. That would lead to a sharp learning curve. The people who are against this proposal, or any other, know they will be required to use it when it comes in, and have an interest in making sure it is clean (whatever that means in each case). We shouldn't dismiss their objections on the argument that they arent required to use it. If its in the language, they are required to learn it. Paul -- Paul Biggar paul.big...@gmail.com Thanks for this elaboration, I totally see your point. Regards, Dennis Haarbrink -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
