Re: [PHP-DEV] back to 5.4 alpha
On 12.08.2010, at 00:39, Pierre Joye wrote: On Thu, Aug 12, 2010 at 12:27 AM, Ilia Alshanetsky i...@prohost.org wrote: Pierre, With all due respect, there are plenty of things already in trunk to make it a worth while effort to start planning the 5.4 release. Just because you disagree, an opinion you are entitled to (like everyone else), does not mean it is a no go, last I checked no one had veto powers on the future release process. Right, and no one can decide alone when we have to begin a release. Please understand my point: I'm not saying we won't need to begin soon, but I do not accept the way it is done, the total lack of respect of the other core developers and the total lack of roadap, consensus or general agreement about what will be php-next. +1 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
Hi, why are we discussing this again? get the RFC's fixed up (though I would assume by now they are already) and do a vote and of story without a vote the status quo from the last release should be maintained for such a controversial feature, aka if there is no consensus then the strict type check changes should be moved to a feature branch. just committing, and then try to wait for a moment when nobody complains (guess it didnt work this time) to release the commit has been done before i guess, but its not the way to go .. for obvious reasons. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
On 11.08.2010, at 10:53, Pierre Joye wrote: On Wed, Aug 11, 2010 at 8:03 AM, Zeev Suraski z...@zend.com wrote: Facts: There are two facts that matter right now, imo: - There is no 5.4 or whatever other version as of now. - There is no RM either. I don't know why nobody cares (well I do ;), but this is totally insane. Do we ever learn? PHP6, the last 5.4 horrible episode, etc. And as we clearly see today, we are not ready. +1 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
On 11.08.2010, at 14:14, Richard Quadling wrote: So, the trunk keeps strict typing. no .. a controversial patch like this should never have gotten into trunk without a vote. the only place for this patch in the svn.php.net repo would be a feature branch. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
On 11.08.2010, at 16:13, Zeev Suraski wrote: Maybe I'm old school, but in my opinion, trunk should only contain agreed-upon features. It should also always build and pass tests successfully. It's not the wild-west version of PHP, it's PHP's next version, in progress. Want to work on something experimental or controversial? Do that in a branch, merge it if when it gets accepted to the language. +1 actually this is in a lot of ways new school, since even though we do not yet use one of those fancy DVCS, with svn we have a much better work flow already to handle feature branches. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On 11.08.2010, at 16:55, Ryan Panning wrote: Now, changing the current implementation to weak type hinting would be more confusing. Because the current syntax used for type hinting classes/arrays is strict. If changed, you would need to specify that scaler types are weak but classnames are strict and now you have a WTH moment. actually for objects its fairly along the lines of what is being proposed with weak typing, since the type hints for objects do consider inheritance. so you do not need to pass in exactly the object that is type hinted, but instead you can also pass in any subclass (an integer is a float). anyway .. for the love of god, could be please stop arguing in circles, nothing .. really nothing that people brought forth pro/con any approach in regards to type checking/hinting whatever hasn't been mentioned on this list multiple times. please please please please .. read the RFC's on the wiki .. if there is something not mentioned there .. ask the author of the RFC why that is and see if they are willing to add it there and notify the list once. If the author in question is unwilling to add it .. then .. and only then bring it back to this list. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
On 10.08.2010, at 10:45, Johannes Schlüter wrote: On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote: Yes. Release early, release often is a good thing. What I'd also like is to have a Ubuntu-like support model. Where we have one LTS (long term supported) version (now for instance 5.3) which will get bug fixes for quite some time and an early access version (5.4) which will receive updates until the next early access (5.5) is there. Reasons: * Give people early access to features * Motivate developers as their additions are in a reachable future * Give users the chance to stay on the LTS version without having to do the full update on every release * Reduce the number of changes in bugfix releases Is LTS really something we need to provide? Seems to me like this is something the linux vendors take care of for the most part. Of course this leaves windows, OSX (and maybe some others). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Version management
On 10.08.2010, at 17:20, Sebastian Bergmann wrote: Am 10.08.2010 17:14, schrieb Derick Rethans: I think our current way work pretty well. There is 5.2 which is security-fix supported, 5.3 that is supported and trunk/5.4 that's on the way to alpha. This only works if manage to keep the time between new code is committed to trunk and new code is released under a year. Otherwise developers get frustrated. If we manage to release a PHP 5.X.0 release every year, we are a lot more predictable. Which is good for downstream as well. +1 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Karoly Negyesi: What do you really want?
On 25.07.2010, at 18:05, Karoly Negyesi wrote: So this sounds like bc does not interest me as long it affects me personally You have this backwards. BC surely interests me but there is no BC, there is only a pretense of BC so why not break it as we see fit? And because of this pretense I have asked not to stop supporting PHP 5.2. Arguing the same thing in circles is just wasting resources. Could stop your posts until you have something novel to post (and have thought it over and maybe spend a second to not look like a whiney user, but actually as someone who wants to contribute to improve the situation)? I read you are interested in QAing, so I suggest you check out http://qa.php.net/. Get setup to run at least the RC's (better yet also the alpha/beta releases, heck even the nightly snapshots) report your findings and assist the doc team in writing the migration guides. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] closures and $this
On 23.07.2010, at 11:35, Harald Lapp wrote: Am 23.07.10 06:05, schrieb Adam Harvey: On 23 July 2010 03:05, Harald Lappharald.l...@gmail.com wrote: i would like to ask what's the state of $this (and 'self') in closures. there seems to be no news on this topic for several month now. php 5.3.3 was just released and still nothing has changed regarding this. so i would like to ask, for which php release a solution is planned. $this support in closures isn't intended to be included in the 5.3 series — the result of the vote late last year was the modified proposal A documented at http://wiki.php.net/rfc/closures/object-extension, and that has been implemented on trunk since April, so will be in the next major version of PHP, whatever that's actually numbered as. i understand -- i hoped for a more early release, but this are good news for me anyway. is there a good place for end-users to stay up-to-date on such topics? i'm looking at the php RFCs every ones in a while, but there was no update regarding closures/$this ... subscribe to the RSS feed on the wiki. also .. the time is now to discuss the future and get changes into trunk regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dangerous handling of security bugs
On 13.07.2010, at 13:18, Reindl Harald wrote: In the case of php it seems every user input it thrown away like i have seen in no other project before You have suggested that someone do something for you, yet you have chosen to ignore suggestions how you could do the same thing yourself. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 21.06.2010, at 05:32, Stas Malyshev wrote: Hi! This is an unfixed PHP bug. There have been a number of threads about the object destruction order on internals. It isn't just APC that is affected by this. Other extensions are affected as well. I understand that this effect is caused by the fact that APC destroys PHP classes earlier than PHP engine otherwise would. You can claim it's a bug but then until it's fixed enabling APC would still cause BC break, and no amount of renaming this fact would change it. If we can fix it and make it work properly - fine, then this ojection ceases to exist as soon as it's done, if there's no more cases when APC behaves differently. I am still undecided if to enable by default, but originally the idea was to bundle with PHP 6, and I think this type of BC break in an edge feature (or rather edge bug) would be ok in a major update to the language. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 21.06.2010, at 13:07, jvlad wrote: Competition between opcode caches for php will definitely be reduced by adding APC into the core, so the market will shrink, of course. i think this is a likely outcome indeed. it might also be phrased in a more positive tone in that likely efforts will be joined. for example maybe zend will decide to contribute some of their code to APC. so the key question might be more is there something in APC that makes it fundamentally the right or wrong approach. furthermore does adding any byte code cache to core also enable new kinds of optimizations because its now possible to more tightly integrate with core? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On 20.06.2010, at 12:01, Ulf Wendel wrote: Johannes Schlüter schrieb: On Sat, 2010-06-19 at 12:45 +0200, Sebastian Bergmann wrote: Am 19.06.2010 11:33, schrieb Patrick ALLAERT: What are the possible actions/alternatives? I think this was already mentioned: add a BC layer to ext/mysqli so that the new extension supports the old mysql_* functions. This would rid us off the old ext/mysql code without breaking code that relies on it. ... while such a wrapper has about the same amount of code as the classic mysql extension (... which is in most parts a simple wrapper over library functions...) Or in other words: Such a wrapper doesn't have real benefits. And any wrapper which is there by default won't change anything. People will continue to use the old API. You need to move the masses or create facts by removing ext/mysql. The latter is quite crazy considering how popular ext/mysql is. Its popularity is somewhat understandable: its old and the API is very phpish in a classical non PJAVA sense. One of the few things that could be done is adding a note to each and every ext/mysql docs page stating that one shall use ext/mysqli instead and give examples how to do it. well couldnt the compat layer be written in PHP? i think this will send a fairly clear message. finally IIRC there was a mysql-mysqli conversion script that could be prominently placed in the docs. and of course we can add deprecation notices. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 20.06.2010, at 22:21, Lester Caine wrote: ( Foregot to change address again :( ) Ilia Alshanetsky wrote: What are your views on including APC in the core, or reasons not to? Dictatorship? Optional module which have well used alternatives should not be proced on by default! Probably more people use alternatives and have for years? probably not actually .. my guess is that the vast majority of users do not use any byte code cache today. this could be our effort to reduce co2 emissions world wide. +1 on adding apc to trunk +0 about enabling apc by default .. or rather undecided at this point. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. isnt this what interfaces are for? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 18.06.2010, at 18:13, Christian Kaps wrote: On Fri, 18 Jun 2010 16:28:31 +0200, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. isnt this what interfaces are for? regards, Lukas Kahwe Smith m...@pooteeweet.org Sure, you can create an empty interface for this scenario but only for self defined classes. All PHP classes can't used with this interface. and you seriously need type hints for this use case? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
On 13.06.2010, at 21:09, Stanley Sufficool wrote: On Sat, Jun 12, 2010 at 4:54 AM, Ilia Alshanetsky i...@prohost.org wrote: The concerns you raised about custom methods specific to database drivers were not reflective of the PDO's intent as was clarified by Wez and myself. yeah .. Wez became the ruler of PDO by ignoring others .. one of the reasons why development died when he left .. so in that way its consistent to continue the development in a lone wolf manner. The code that was introduced was specific to PostgreSQL, the common functionality was introduced in a way that allows each driver to implement. Yet the rest of the copyFrom, copyTo, etc.. could have ben generic as well. I specifically stated that this could be done at the driver level for FreeTDS using the BCP extensions and/or using BULK INSERT . Yet now this is a specific pgsql*** interface that cannot be abstracted for other drivers OR implemented at the driver level. Now if I want a MSSQL / Sybase dump/load method, I need to preface it with dblibCopyFrom, dblibCopyTo. right .. Ilia just chose to ignore the rest of the developers. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 09.06.2010, at 12:01, André Rømcke wrote: Example: function fetchById( int $id, bool $asObject = true ) If weak type hints are accepted, type hints would be useless in this case as consumer can do something strange as fetchById( true, 'foo' ) (Obviously I'm not saying anyone would do this intentionally, but in a large application you might not have full oversight and can unintentionally pass variables of wrong type or in wrong order causing issues to surface much later as there are no strict type checks that would detect the mistake immediately while developing). please read RFC's you comment on (well the following was added to the RFC 2 or maybe even 3 weeks ago): in your above example there would be data loss in the type cast and therefore there would not be silent auto casting. again there is only silent automatic casting being proposed in the case of when there is no data loss: 1 = 1 but 1abc would not silently cast to 1 etc. anyway .. can we conclude this discussion? probably best if someone who is more or less impartial would handle the call fore vote and figure out some sensible way to let people vote on the various solutions that are proposed. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and static variables
On 05.06.2010, at 22:47, Stefan Marr wrote: Hi: Was just thinking about some details of the traits implementation. From my perspective, static variables in methods should work like the method would have been actually implemented in the class using the traits. Thus, static variables should be independent for the different traits usages. Any thoughts on that? i agree. the mantra is traits are engine level automated copypaste. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 04.06.2010, at 03:18, Daniel Convissor wrote: On Thu, Jun 03, 2010 at 10:29:30AM -0400, Daniel Convissor wrote: Hi Folks: On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote: IMHO we shouldn't be getting to any kind of fatal error/exception situation, which is why I like the idea of auto-conversion plus E_STRICT in the 'weird conversion' scenarios E_STRICT doesn't cut it. And another reason E_STRICT won't serve this situation well: how are userland error handlers supposed to pick out the type hinting conversion problems from all of the other bazillion E_STRICT errors that come up? Not very efficient. Same deal as E_NOTICE. Either you care about them or you dont. Anyway, in my weak typing proposal I also made an optional variant to get an E_FATAL instead of E_STRICT, though I personally do not see the need for it. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 03.06.2010, at 18:25, Josh Davis wrote: On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote: It is very frequent that you want number and get 1 instead - almost all incoming data for PHP are strings. I'd like to point out that filter_input() does cast user input to the right PHP type. And if memory serves, ext/filter is meant to be PHP's standard way of handling user input. So in terms of incoming data, I'd consider user input being covered already. The only other big source of data is the database. Unfortunately, it seems that mysqlnd experiments in using MySQL's binary protocol for all queries and not just prepared statements [1] didn't materialize. But again, the same way filter was one of PHP 5.2's highlights, mysqlnd is one of PHP 5.3's highlights and the recommended way to communicate with MySQL, which means that if mysqlnd gained that ability somewhere down the road then most of incoming data would be correctly typed already. Emphasis on would. Thats all fine and dandy if the ultimate goal is to turn PHP into a strictly typed language and of course if 90% of the API's you talk to require strict typing, then the question becomes why even use a dynamic language to begin with? Why not clean all of that magic out, get better memory management, less overhead in plenty of places, less chances for typos to result in hard to debug issues. Sure sounds good and I guess there probably is a market, maybe even an urgent need for a strictly typed scripting language for the web space. But really is PHP the best basis for this? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 03.06.2010, at 18:57, Ferenc Kovacs wrote: On Thu, Jun 3, 2010 at 6:32 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 03.06.2010, at 18:25, Josh Davis wrote: On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote: It is very frequent that you want number and get 1 instead - almost all incoming data for PHP are strings. I'd like to point out that filter_input() does cast user input to the right PHP type. And if memory serves, ext/filter is meant to be PHP's standard way of handling user input. So in terms of incoming data, I'd consider user input being covered already. The only other big source of data is the database. Unfortunately, it seems that mysqlnd experiments in using MySQL's binary protocol for all queries and not just prepared statements [1] didn't materialize. But again, the same way filter was one of PHP 5.2's highlights, mysqlnd is one of PHP 5.3's highlights and the recommended way to communicate with MySQL, which means that if mysqlnd gained that ability somewhere down the road then most of incoming data would be correctly typed already. Emphasis on would. Thats all fine and dandy if the ultimate goal is to turn PHP into a strictly typed language and of course if 90% of the API's you talk to require strict typing, then the question becomes why even use a dynamic language to begin with? Why not clean all of that magic out, get better memory management, less overhead in plenty of places, less chances for typos to result in hard to debug issues. Sure sounds good and I guess there probably is a market, maybe even an urgent need for a strictly typed scripting language for the web space. But really is PHP the best basis for this? regards, Lukas Kahwe Smith m...@pooteeweet.org Sorry, I missed the point when Josh was suggesting to turn PHP into a strictly typed language. I think that you should have noted, that what suggestion/idea are you against it. Converting the variable type to the appropriate one? Or the strict type hinting? Tyrael ps: http://en.wikipedia.org/wiki/Straw_man Straw man arguments often arise in public debates such as a (hypothetical) prohibition debate: Person A: We should liberalise the laws on beer. Person B: No, any society with unrestricted access to intoxicants loses its work ethic and goes only for immediate gratification. The proposal was to relax laws on beer. Person B has exaggerated this to a position harder to defend, i.e., unrestricted access to intoxicants.[1] You didnt read my email: I was saying that focusing PHP API's on consuming and returning strict types _would_ make sense if the language would be strictly typed. I did not suggest that Josh was implying that, which is part of why I have an issue with his post. Or in other words I was saying he isnt going _far_ enough, though if he did go far enough to make things worthwhile, then this is not the right place, because PHP is not the right basis. Or in yet other words, I think a strict typed dynamic web oriented programming language has merit, just that PHP is not the right language to start from if that is what you want to design. I could probably find some wikipedia article to reference in order to misrepresent your reply, but I will hold off on that. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote: On 28.05.2010, at 11:22, Etienne Kneuss wrote: so, it would be nice to update the RFC(s), so that we have a solid ground on which we can discuss/vote. i agree. i currently see 5 fundamental different options on the table: 1) current trunk 2) current trunk but only with scalar/numeric type support 3) weak typing with current PHP conversion rules that raise an E_STRICT on data loss 4) weak typing with new conversion rules 5) some syntax to allow both one of 1)/2) and 3)/4)/5) i can take care of 3), 4) and 5) over the weekend, though for 4b) (see below) i would like to get some feedback from others other than that i agree that we have beat this horse long enough that we can then pretty quickly move to a vote. that being said, i think we should do the vote by allowing people to then sort the RFC's in order of preference with the option of leaving options out that they want to veto. of course if 6) gets voted for we would then have to decide on which of the permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second vote. ok .. i adjusted the weak type hinting RFC to cover 3) and 4). so i guess it would be nice if someone could create and RFC for 2) (as I guess the strict typing RFC covers 1)?) and if someone believes in a combined approach (Derick?) create an RFC for 5). if someone wants to do an SPL based exception approach, feel free to create a new RFC. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 28.05.2010, at 10:57, Arvids Godjuks wrote: I'd say that I agree on this, I would like to see the conversion rules cleaned up and made more clear. The idea of emitting e_warning or e_strict on conversions with data loss throughout the language is very appealing. Maybe we really need to do that so conversion rules and type hinting rules to work the same? Which conversion rules? the one in PHP today or the one in the weak type hinting RFC? In the weak type hinting RFC the conversion rules are pretty clear to me, anything that converts without data loss goes through, anything else does not convert silently (or even fails if we want to be so strict, depending on which approach we prefer). I personally prefer the cleaned up conversion rules from the RFC (and would love if we could figure out some way to do something similar for the entire type juggeling in PHP). However I can also accept if we simply stick with the same rules as PHP has atm (albeit still with the addition that a cast that causes data loss would not happen silently regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 27.05.2010, at 10:45, Daniel Egeberg wrote: If you don't know whether the user/database provided information you have is correct before you pass it along to something else, I would say that the code indeed is bad. Unless you regard 123abc as a valid value from your user, don't allow the user to give you that value. If you regard it as a valid value, then it's not an int thus you wouldn't want to type cast it in the first place. as Arvids already pointed out most database extensions for PHP atm return strings even for integers/floats. furthermore the 123abc example was mentioned more for data coming from external sources, with strict typing you are encouraging stuff like (int)123abc. Of course a good programmer would first check with is_numeric() before casting. Seems like a lot of work. With the proposal of weak typing with error/notice on data loss none of that would be needed. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 27.05.2010, at 11:05, 魏世江 wrote: But I think it's the icing on the cake if we give the PHP programmer the choice of whether use explicit types. For examlpe, we may add a switch in php.ini, let's say, explict_types=On/Off. heh .. you are giving the question cake or death a new dimension :) seriously php.ini settings to manipulate how core syntax is interpreted are a no no. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 27.05.2010, at 12:59, Ilia Alshanetsky wrote: Zeev, Auto-conversion does not validate input to the function/method, it merely obfuscates the wrong input by converting it to desired type resulting in a potentially un-expected value. I must say I am completely against the auto-conversion hint idea. the current proposal is quote the opposite from obfuscation since it would alert the user if the conversion would imply data loss. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 27.05.2010, at 14:31, Richard Quadling wrote: In any decent course regarding defensive programming, we are told to filter input and escape output. One easy way of filtering input is to cast and verify. Once cast and verified we know we've got the right type and acceptable values. In databases, you can't usefully have a column containing multiple types. Everything would end up as a char/text column to allow you to put a date AND a string AND a number AND a boolean value in the column. Now think about how often you write a new API and how often you consume existing API's. Now think about how much code you need to validate, cast etc. Now think about where you want that code to be, in your API consuming code or in the API. I think the choice is obvious: You dont want to have to replicate this validation/cast code all over the place, when it could be in one single location for that API call. Now lets take your lazy devs are lazy argument. I think there is a saying that only lazy dev's are good devs. But even so, PHP is not successful because it required highly skilled and disciplined developers. This has gotten PHP a bad rep with a fair number of people because of security issues that are in popular applications. Now of course we know you can write secure PHP apps, but isnt it in the best interest if the language to encourage that API's and API consuming code is written with as little effort as possible to be as functional and secure as possible? Again, API developers are likely to be more competent than those consuming the API's that just how the food chain goes. Furthermore every API method will be called multiple times and so moving the validation/cast logic there is simply efficient. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 27.05.2010, at 17:40, Derick Rethans wrote:
On Thu, 27 May 2010, Arvids Godjuks wrote:
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that integer or float - no matter. I don't want to make my code look
like this:
function doSomeStuffWithDbData(int $id, string $name, int $someFlag) {
}
$sql = 'SELECT id, name, some_flag, FROM table WHERE .';
$res = mysqli_query($db, $sql);
$row = $res-fetch_assoc();
doSomeStuffWithDbData((int)$row['id'], $row['name'], (int)$row['some_flag']);
PDO's bind values already provide the correct type if you specify so. So
this is moot point.
well most people do not use that since its just as tedious to use as having to
cast your results. of course if we did have strict typing it would probably
become more widely used, not that having to add those lines of code are
something i would like to see in my code (the speed gains are
microoptimizations for most use cases of PHP).
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 23.05.2010, at 14:44, Sebastian Bergmann wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/2010 01:08 AM, Ilia Alshanetsky wrote: any mistmatch results in an error An error that is recoverable. So not only is the strict typing optional, but type mismatches can be caught and handled. again .. are you saying that a recoverable error is more than a way to display a nice error message instead of a white screen? anyway, the fundamental question at hand is where the burden of correct typing should be placed, on the API consumer or on the API provider. this also ties in with the question if API consumers are likely to have properly typed (aka typed in the way the _various_ API he consumes expect) by default or not. i think this is the key question to answer when deciding to go with enabling type hinting or full out strict typing. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 22.05.2010, at 18:30, Josh Davis wrote: As you wrote, you worked on PHP's _type system_ which is dynamic, really cool, juggles strings with ints and what not. However, the topic here is the _type hinting system_. As far as I know, there's no weak type hinting; if a method signature hints for an array and is given an integer, it throws a catchable fatal error. Therefore, as a user, what I am familiar to is a strict _type hinting system_. Anything else would feel inconsistent to me. can we please just stop calling a something a type hinting system, which leads to a catchable fatal error when the type does not strictly match? thats a very misleading euphemism. its simply strict typing, it has nothing to do with hinting. anyway, yes there is a proposal for an actual hinting system as Zeev has pointed out just a few mails early in the thread than yours: http://wiki.php.net/rfc/typecheckingstrictandweak regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 23.05.2010, at 00:01, Hannes Magnusson wrote:
can we please just stop calling a something a type hinting system, which
leads to a catchable fatal error when the type does not strictly match?
thats a very misleading euphemism. its simply strict typing, it has nothing
to do with hinting.
It definitely isn't strict either:
$ php -r 'function errh() {} set_error_handler(errh,
E_RECOVERABLE_ERROR); function bar(foo $x) {echo hello world\n;}
bar(1);'
hello world
heh ... you are selling recoverable errors as anything but a solution to
display something else than a white screen?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 31.03.2010, at 07:22, Rasmus Lerdorf wrote: On 03/30/2010 08:41 PM, Philip Olson wrote: It's awesome that PHP has so many great options for the next Release Manager because all of the proposed people would do great. However, I'd like to see Rasmus become RM. Not sure about the co-RM topic but Chris Jones comes to mind. I love the way these two guys handle things, and it feels like a nice balance. And while Rasmus may [or may not] deny his BDFL status, I'd love to see it in high gear especially now that he's funemployed. I didn't actually volunteer. I think someone misunderstood that at some point. I'll do it if nobody else will, but both Derick and David seem keen, and I think they should work it out between them. The whole concept of a non-technical co-rm person, is kind of a moot point I think. We all know that person is Lukas and he will do his thing regardless. That's not a knock, by the way, we need a process guy to offset my anti-process approach so that we can meet somewhere in the middle. Just FYI: I will no longer serve as the process guy, nor anything else really. Feel free to remove my karma. I may write the occasional post here still of course as I will continue to be a PHP end user. Context: I just feel that with the things I feel are right, I will just end up being tied up in a perpetual battle. Over the years I got a few things to go the way I wanted (wiki, a todo list, RFCs) but there are simply some fundamental things where I am no longer motivated to work with the status quo, but where I do not see a realistic chance if this ever changing. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On 05.05.2010, at 08:44, Patrick ALLAERT wrote: 2010/5/4 Adam Harvey ahar...@php.net: On 19 April 2010 11:58, Adam Harvey ahar...@php.net wrote: As at least some of you would already be aware, there's a long-standing issue with using PHP in a Turkish or Azeri locale, namely that case-insensitive lookups within the Zend engine (method names, for example) fail on lookups involving upper-case I characters, since lower-case I in those languages is ı instead of i (note the lack of a dot). Well, I'm going to assume that people have had whatever say they were going to. It seems that we have three options, so let's put it to a vote. (To be completely clear, this is purely for trunk. This certainly isn't a candidate for backporting to 5.3.) The options are: 1. Apply Tomas's patch to make case-insensitive lookups locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for case-insensitive function/method name lookups for high-bit characters in single-byte encodings. (Not that we've ever advertised or documented that.) 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: fixes problem; brings PHP into line with most other languages; extra consistency with variables; possible performance improvement. Cons: BC break from current documented behaviour. Once and for all: +1 for #2 (BTW that kind of BC will not be that hard to fix!) we have had the topic of making PHP case sensitive before. I do not find the above reason all that compelling to make this change. However there are several other reasons that imho are more relevant for making this change. RMs: should this really be part of PHP 5.4 if it gets approved? no way. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using default_charset for htmlspecialchars() and others
On 03.05.2010, at 00:53, Brian Moon wrote: I am not sure if this has been discussed or not. I will gladly make an RFC if not. I think it would be very intuitive if htmlspecialchars used the ini value default_charset as its default. And any function that takes an optional character set. A) Has this been discussed? B) If not, do others think it is worth of a proper RFC? There would be some BC breakage for sure as the default behavior would be changing. Due to this BC and the fact that I do not see this as a super pressing issue, I would hold off with doing this change until we have our unicode plans more concrete, because this might result in yet another change in this area. regards, Lukas Kahwe Smith m...@pooteeweet.org PS: Then again .. the entire unicode discussion seems to have died on this list and I am not aware of any documentation having been made or any other tangible progress. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 29.04.2010, at 08:38, Jérôme Loyet wrote: 2010/4/29 Andi Gutmans a...@zend.com: -Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Tuesday, April 27, 2010 9:40 AM To: Pierre Joye Cc: Gwynne Raskind; Ilia Alshanetsky; Kalle Sommer Nielsen; Lukas Kahwe Smith; Andi Gutmans; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] trunk is alive and open On Tue, 2010-04-27 at 17:46 +0200, Pierre Joye wrote: Before even thinking about a planning, we have to define what we want in and how we go further. ACK, I think it makes sense to define some key features we want for the next release (traits seem to be one). An issue with 5.3 was that whenever really defined that but only said let's backport from 6 and add all stuff coming in. I think it makes sense to define a set of key features (traits, what else?) and once these are implemented in an accepted way (not meaning stable but having an accepted design) make a release branch (either by branching of or locking trunk for bigger features or whatever) where stability of this is improved else we end up adding feature after feature and introducing problem after problem. As I've mentioned in the past I think we are better off with shorter release cycles and less features per cycle. Reduces risk and enables us to push out value faster. For example, we have made (and are still making) significant performance enhancements to the runtime. It'd be a shame if that waited until Q4 for alpha. I think with traits, performance enhancements and a few additional changes we already have a pretty substantial version. +1 +1 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A critique of PHP 6
On 21.04.2010, at 15:24, Ryan Panning wrote: 2. TYPE HINTING. This topic was discussed to death on the list, please read the archives. If after that you still do not understand what it is about, or have some comments, please ask then. Sure, it has been discussed over and over but the fact that it keeps coming up here should show you that PHP developers want this feature. check out the RFC's on the topic. See if you want to champion one of them, or add another one if you have different ideas. 4. PARAMETER ORDER. Two letters: BC. Changing variable order in an existing function is a big fat BC break. And if we put such a bomb into a new version, what would be the incentive for people to use it? So that apps would have to be shipped in 2 versions, for the old php and the new php? Is this something that could be fixed if it's moved to a namespace? The new alias can have the correct order but original function can have the old order. Right, if we ever namespace internal stuff (obviously there would be a need for some out of the box BC extension), than this would be the moment to fix stuff like this. Anyways, if anyone cares about any of the above proposals write up an RFC (or champion an existing one). Lets not end up in a situation where we have to refer people to the archives to understand a previous decision ever again. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named Parameters
On 13.04.2010, at 23:39, GM wrote:
Personally, I would strongly prefer the caller syntax my_func('a', 'b', 'c'
= 'd', $e = $f) just to because
1) it's consistent with array declaration syntax
2) it allows arbitrary names for parameters, which will become the
array keys ... and can include funny characters
3) naked identifiers in PHP are used only for functions, classes and
constants, so c = 'd' looks like a constant
4) it allows the flexibility of dynamically specifying parameter names,
although this will probably be rarely needed
My second favorite is my_func('a', 'b', c = 'd') ... which I consider worse
but at least not as bad as my_func('a', 'b', c: 'd') ... which seems to come
out of left field as it's not consistent with the rest of PHP syntax. Unless,
of course, c: 'd' is going to be a shorthand for 'c' = 'd' ... which makes
me ask ... if you guys are ever going to make a short array declaration
syntax, will it look something like this:{'a'='b', 'c'='d'} or will it
look like {a: 'b', c: 'd'} ?
Just stumbled over a post about SQL 2011 which also seems to get support for
named parameters for functions [1]:
Named arguments in function calls. PostgreSQL 9.0 supports that, but using the
syntax foo(3 AS a) instead of what ended up in the standard, foo(a = 3).
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
[1] http://petereisentraut.blogspot.com/2010/04/news-from-sql-standard.html
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits
On 12.04.2010, at 10:34, Derick Rethans wrote: Hi! Just had a look over the RFC, and from what I gathered was that only the issue of aliasing/renaming seems slightly controversional. Would it be possible to commit traits without this feature for now? Stefan recently got karma and told me he can commit his traits patch after the 15th. I do not really think we should leave out the aliasing, lets have as many people as possible play with it as is. We can always tweak/change/drop it later. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance improvements
On 25.03.2010, at 18:07, Zeev Suraski wrote: At 18:51 25/03/2010, Sebastian Bergmann wrote: Zeev Suraski wrote: What does it contain? It looks to me as if the patch would also reduce the memory footprint: That makes perfect sense... Thanks for sharing the results! So where do we stand here? Do we want to start rolling these changes into trunk? Could the changes and additional proposals be tracked inside a wiki RFC? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Reflection Exception Messages
On 28.03.2010, at 17:59, David Soria Parra wrote:
On 2010-03-28, Benjamin Eberlei kont...@beberlei.de wrote:
Index: ext/reflection/php_reflection.c
===
--- ext/reflection/php_reflection.c (revision 296963)
+++ ext/reflection/php_reflection.c (working copy)
@@ -3425,7 +3425,7 @@
} else {
efree(lc_name);
zend_throw_exception_ex(reflection_exception_ptr, 0 TSRMLS_CC,
-Method %s does not exist, name);
+Method %s::%s() does not exist, ce-name,
name);
return;
}
}
@@ -3602,7 +3602,7 @@
}
}
zend_throw_exception_ex(reflection_exception_ptr, 0 TSRMLS_CC,
-Property %s does not exist, name);
+Property %s::%s does not exist, ce-name, name);
}
/* }}} *
The patch is against SVN trunk.
looks good for me. if there are no objections from someone else I'll
commit it tomorrow.
@David: seems like you forgot to commit this?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Supplying nothing at all for default parameters
On 06.04.2010, at 12:16, Richard Quadling wrote:
Hello.
A suggestion I would like to make is to allow for nothing to be
supplied for defaulted parameters.
I suppose the easiest way of describing this issue is with the
following code ...
?php
function foo($bar, $baz = 9, $buzz = 10) {
return $bar $baz $buzz;
}
// Whatever is supplied for $baz will be used for $baz.
// User has to know the default value of $baz rather than just
allowing the default value.
echo foo(1, 9, 20);
I don't know the stylics on using default parameters, but for the user
to have to know the default value would sort of make the default
redundant.
// Passing nothing at all could be one option.
echo foo(1, , 20);
i dont think is really a nice syntax to support. either we add named parameters
are you just use the current work around for the absence of named parameters
(aka an array parameter and array_merge/array_replace_recursive)
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
On 07.04.2010, at 16:16, Christian Schneider wrote:
my gut feeling also says that we shouldnt allow positional arguments after
named parameters.
just picking out one of your examples ..
foreach (new T_User('firstname' = $firstname, ORDER BY age) as $user)
couldnt this also be written as:
foreach (new T_User('firstname' = $firstname, ORDERBY = age) as $user)
of course it would be a bit more work when constructing the final query, but
its tons clearer in terms of knowing how to use the API with just reading one
use of the API and not the actual implementation.
in the above code what is the purpose of the positional argument? can i just
append what I want? aka is the idea of the API to also support
foreach (new T_User('firstname' = $firstname, LIMIT 100) as $user)
and
foreach (new T_User('firstname' = $firstname, ORDER BY age LIMIT 100) as
$user)
in that case it would still be better to then do:
foreach (new T_User('firstname' = $firstname, 'append' = ORDER BY age) as
$user)
.. of course its a few more characters, but its definitely easier to grasp
whats going on, then having to parse what is named and what is positional.
i am trying to remember what killed the discussion last time around. i think it
was concerns over having to convert all internal functions, but i guess that
was before we unified the parameter parsing API. IIRC hartmut was quite
involved in the discussion back then .. maybe he remembers.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] User Input Callback as a new security feature
On 08.04.2010, at 12:48, daniel zulla wrote: Hi, Take a look at the code example [1]. Why not giving programmers the possibility to init their scripts with a call, that tells exactly what data should be taken - like GET userid INT and GET password MIXED, or just POST domainid INT, or something like that. If there's data transmitted, the scripts doesn't need, why should we go on with execution? In my example, request_init would check if there is $_POST['userid'], $_POST['pass'], $_GET['userid'] or $_GET['pass'] and if userid is an integer, and pass is mixed. If that's all right, the script just goes on working. If not, and that's the clue, the callback function will be called, telling the user what's wrong. A feature like that would highly improve security. Programmers wouldn't even think about stupid solutions like getting all the $_POST data into an Array() and trying to quote it anymore. It's an advantage for readability too: You take a look on the code, and you just know exactly what's going on. When magic_quotes and register_globals will, finally, be killed in PHP6, this could be, finally, a real security feature, couldn't it? Greets, Daniel Zulla [1] Code Example: ?php request_init(Array(POST, GET), Array(userid = INT, pass = mixed), $callback-crap_transmitted, 1); ? html are you aware of the filter extension: http://php.net/filter regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: gron
On 30.03.2010, at 22:08, Stefan Marr wrote: I would like to contribute my Traits implementation to PHP. BTW, there is no Grafts implementation at the moment, and as long as there is not any vote from the community that you want Grafts but not Traits, I would like to commit my work. From the vibe I have gotten on list as well as from feedback talking to people via my blog and IRC, it seems like traits is already well understood by many people. Plus there is an implementation and it seems like the plan for the next release is to commit to trunk, play and then cherry pick. So yeah, lets get it into trunk. +1 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
On 02.04.2010, at 23:17, GM wrote: Once again I'd love to create an RFC for this, but I don't think I have permissions on the wiki to do that. What do I do to get those privileges granted to my wiki account? Hmm thought I already mailed you about this .. anyways the link is here (can be found by clicking on login on the lower right navi bar): http://wiki.php.net/start?do=register regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 25.03.2010, at 22:58, Christopher Jones wrote: After considering what is needed by PHP, I believe the vote should primarily be thought of as a choice between Derick and David. If either wants to bring in a co-RM to share the load, then I suggest Lukas be first choice. I'd be happy with either Derick or David as RM. When voting, I'd give my +1 to David this time. We might enter a quick release cycle so the RM would change over quickly. Disclaimer: David works at Sun which was recently bought by Oracle. Personally I think its a good idea to switch RM after every release. Plus I am pretty certain that there are other people (like you Chris) in the php.net community that could take on the role I had for 5.3 (aka less technical more organizational). Aside from this while there is no need to ever rush anything, I would think that it would help a lot to get the RM's sorted out quickly, so I would really ask all people to quickly chime in with their preference, nominations or whatever else might matter to get this decision finalized. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] horizontal reuse: traits vs. grafts
On 25.03.2010, at 14:48, David Soria Parra wrote:
Just as a general idea (which is certainly something after traits are
implemented once)
Scala offers stackable traits so that you can mixin traits during object
creation.
An example:
trait Philosophical {
public function think () {
echo Cogito ergo sum;
}
}
trait Drink {
public function drink () {
echo gluck gluck
}
}
$obj = new Person();
$obj-think(); // will fail
$obj = new Person() with Philosophical;
$obj-think(); // works
$obj = new Person() with Philsophical, Drink;
$obj-drink(); // works
$obj-think(); // works
This approach is taken in scala and works pretty fine there for composing
classes
during runtime and should be douable in PHP too. For sure aliasing is not
possible in this example.
But as said just a general idea that I might try to work on once traits are
comittet.
Stefan what do you think about stackable traits ?
Woha .. that code really scares me.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] horizontal reuse: traits vs. grafts
Hi, this was just brought up on IRC. my understanding is that traits have no concept of properties, but grafts do (all hidden internally). correct? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] horizontal reuse: traits vs. grafts
On 25.03.2010, at 21:13, Stefan Marr wrote: On 24 Mar 2010, at 11:50, Lukas Kahwe Smith wrote: In case of the above definition of Talker, PHP will show a warning that there have been conflicts and name the methods smallTalk() and bigTalk() as the reason of this conflict. Therefore, neither of the given implementations will be available in the class. I think this is a fundamental decision, should it be a warning or a fatal error? Generally I prefer PHP to keep on going whenever it can. I guess in most cases if we stick to a warning the user will end up with a fatal error anyway, but it might not be so clear why the given method is unavailable. But there should still be a warning, which I guess cannot be suppressed all that easily. Well, I do not like a fatal errors. This problem does not leave the engine in an undefined state, and personally, I think, fatals should only be caused by something which really cannot be handled. Since we have __call, there might even be something executable. Yeah, I agree, just wanted to bring this point up. I am right that this warning cannot be suppressed via some @ magic and so if at all would need to be suppressed by a custom error handler? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] horizontal reuse: traits vs. grafts
On 25.03.2010, at 21:23, Stefan Marr wrote: Hi: On 24 Mar 2010, at 17:58, Jonathan Bond-Caron wrote: One thing I feel is missing from the RFC is how is_a() and instanceof are affected with traits or grafts. Well, my personal (I admit very academic) position is: - Traits are not classes - Traits are not interfaces - Traits are not types - Traits cannot be instantiated Thus, there is no meaning of a is_a and instanceof, and it would not provide any meaningful information since you can exclude methods from a Trait in a composition. Thus, you should resort to interfaces for use-case where you need to ensure that an object provides a certain set of methods. Traits are purely for behavior, the class hierarchy or interface should provide the type-information/relations. It's seem to me that a defining a 'trait' should be advertised strictly as an 'advanced multiple inheritance technique' to reuse pieces of code and it shouldn't be considered as an object (grafts proposal). It is not an object, right. You can not instantiate traits. But, I would not speak of multiple inheritance. I would prefer something along the lines of 'sustainable copy'n'past reuse'. I think Stefan used the right metaphor in the RFC: its language level copy paste. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] horizontal reuse: traits vs. grafts
On 25.03.2010, at 22:59, Stefan Marr wrote:
On 25 Mar 2010, at 21:30, Stefan Marr wrote:
On 25 Mar 2010, at 16:37, Lukas Kahwe Smith wrote:
Hi,
this was just brought up on IRC. my understanding is that traits have no
concept of properties, but grafts do (all hidden internally). correct?
Right, the Traits proposal as it is at the moment, avoids the explicit
discussion of state.
This is not a restriction per se, but could limit the composability of
traits.
To ensure composibility, you would have to resort to abstract methods which
are implemented by the composing class.
Maybe I should clarify that.
Currently the semantics is implicitly the following:
class Base{
var $a;
}
trait T1 {
var $a;
var $b;
}
trait T2 {
var $a;
var $c;
}
class Composite extends Base {
use T1, T2;
}
and Composite would have the instance variables $a, $b, $c.
The problem would be of course that Base, T1, and T2 could use $a for
completely different things.
Simple, but at the cost of composability/safety.
But for most practical cases that should be 'good enough'. As already
mentioned, if you want stronger guarantees, state accessor methods can be
used.
However, I think this implication is not discussed in the RFC, and works just
because PHP can create the fields dynamically. Thus, I used 'var' here in the
example, instead of defining a semantics and handling for public, private,
protected.
Right, but the issue doesnt go away if I would define a private property in the
trait. Its still just stupid copy paste and so its the job of the trait user
to ensure that there is no overlap. As such updating the trait code can easily
break your code, its not encapsulated automatically, contrary to grafts. All in
all I do see appeal for traits, but I think grafts just offer less wtf!?!
surprises when code around you changes and so I favor grafts and I do not think
we need both approaches.
So without having tested the patch, I am currently +1 on the grafts proposal as
its in the wiki.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 23.03.2010, at 23:04, Andi Gutmans wrote: What about defining a release manager for the next release? I think that is an important aspect of moving things forward. I also thought the dual RM in PHP 5.3 worked quite well although it is not necessarily a must. Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] horizontal reuse: traits vs. grafts
Ahoi,
Thought it would be better to open up a new thread and also using the term
horizontal reuse in the subject so that we make it clearer that there are
actually two approaches. Here is the URL for Stefan's proposal:
http://wiki.php.net/rfc/horizontalreuse
In case of the above definition of Talker, PHP will show a waring that there
have been conflicts and name the methods smallTalk() and bigTalk() as the
reason of this conflict. Therefore, neither of the given implementations will
be available in the class.
I think this is a fundamental decision, should it be a warning or a fatal
error? Generally I prefer PHP to keep on going whenever it can. I guess in most
cases if we stick to a warning the user will end up with a fatal error anyway,
but it might not be so clear why the given method is unavailable. But there
should still be a warning, which I guess cannot be suppressed all that easily.
(@Stefan: didnt want to start editing minor typo's in the RFC ..
s/waring/warning .. that typo can be found in other places too)
Since the new name is recognized as an additional method, the bigTalk method
still has to be excluded. Otherwise, PHP would print a warning that two methods
from Traits have a conflict and are excluded. The introduction of a new name is
not renaming and references in methods to a given method name aren't changed
either. On the first look this may sound strange, but it provides the
opportunity to build Traits and even hierarchies of Traits which fit together
very well.
The third sentence is not so clear to me, but if I guess it its also just a
typo as it makes more sense to me when replacing renaming to result in
renaming. But maybe you could tweak that paragraph to be a bit clearer. For
example its still not totally clear to me why aliasing doesn't imply inclusion,
I guess its definitely more flexible. How will things work when traits have
overlapping method names when other methods of the given traits call these
overlapping methods?
trait A {
public function smallTalk() {
$this-bigTalk();
}
public function bigTalk() {
echo 'A';
}
}
trait B {
public function smallTalk() {
$this-bigTalk();
}
public function bigTalk() {
echo 'B';
}
}
class Talker {
use A, B {
B::smallTalk instead A;
A::bigTalk instead B;
B::smallTalk as talk;
}
}
What is there anyway to ensure that when Talker::talk() is called that
B::bigTalk() is still called and not A::bigTalk() because I want to maintain
the integrity of each trait? Is that what you mean with its not renaming and
references in methods to a given method name aren't changed either as in it
will indeed call B::bigTalk()? Reading further long I however see that This
leads to missing features like recursion for methods introduced by aliases.
Also I guess exactly this is the key difference to Grafts.
Reading further about Grafts, I must say I really like that approach. I mean we
have talked about traits for quite a bit already, but I feel like I got how
Grafts work the first time reading. I also like the fact that since Grafts are
just classes, people can integrate them as they see fit, like they can use
delegation if they are still on an older version of PHP or use Grafts. I also
envision that there will be less surprises when using Grafts and this fits well
with the approach to keeping the barrier to entry low for PHP development.
regards
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Output buffering patch
Hey, Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 24.03.2010, at 11:08, Pierre Joye wrote: skills. You suggested Chris and I think he could do a great job. My Just to clarify as I mentioned this on IRC and not on here. I think it would be great to have Chris Jones do the organizational co-RM. For one I have great trust in him keeping a good overview of the priorities, plus he can also give some technical input, where I for example couldn't. Furthermore I was co-RM in the last release, we all know power corrupts so its good to rotate :) For those who might be concerned that he is to embedded at Oracle, I actually think its quite the opposite. I think it would be great for PHP to have him take an official role. I have full trust in his integrity and so it might be also a good signal after the entire PDO2 CLA debacle that we do have trust in working with people from big corps. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Output buffering patch
On 24.03.2010, at 21:10, Hannes Magnusson wrote: On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith m...@pooteeweet.org wrote: Hey, Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation. I really do not see why this even needs a discussion. Its been in trunk for years already. People have had plenty of time to give feedback. Is there really anyone who doesn't want this committed? For what reason? This isnt about getting a reason not to commit this. As you can see in the above quoted mail from me, I was asking for this RFC for various other reasons. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Output buffering patch
On 24.03.2010, at 21:26, Hannes Magnusson wrote: On Wed, Mar 24, 2010 at 21:12, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 24.03.2010, at 21:10, Hannes Magnusson wrote: On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith m...@pooteeweet.org wrote: Hey, Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation. I really do not see why this even needs a discussion. Its been in trunk for years already. People have had plenty of time to give feedback. Is there really anyone who doesn't want this committed? For what reason? This isnt about getting a reason not to commit this. As you can see in the above quoted mail from me, I was asking for this RFC for various other reasons. Search the archives. Do your homework. 3 years and 9 months ago the patch was posted to internals for review. It included README files, TODO list, tests, tests, tests and explanations. Few weeks later it got committed. The commit got reviewed by various parties and some enhancements were made. Every single procedure was followed to the letter. People were happy. You cannot seriously be expecting more then that, nearly 4years later? All I am asking is a single document in the central location we have dedicated for this (aka the rfc namespace on the wiki), that pulls together all relevant documentation. If all that is needed is a copy paste of a bunch of URL's all the better. But it makes no sense to ask each and every developer to do his homework. Thats a waste of time and a sure way to have misunderstandings. Seems like you know all there is to know about this, so how about just throwing together an RFC, shouldnt take more than 10 minutes if all of this is already perfectly documented. Some links to get you started: http://php.markmail.org/message/ujx2htvdzerrxgfe?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward http://php.markmail.org/message/n22c6ye5boe2rtjk?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forwardpage=1 http://php.markmail.org/message/jgsd2umnm5lk37b6?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forwardpage=1 These links just highlight that there are questions, not that there are answers. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 23.03.2010, at 17:21, Rasmus Lerdorf wrote: On 03/23/2010 09:11 AM, Pierre Joye wrote: hi, I would rather have some kind of rules defined before opening trunk again (or the pandora box). That's what we are discussing right now. May I know why you choosed that now is the right time to do it and declare it open? We have rules. Large features, write an RFC and we discuss it. Small and obvious improvements follow commit-then-review as before. We don't need more complicated rules than that. Yeah, but I still think it would be a good idea to figure out lets say 3-5 big time features that we focus on for the next release and a rough timeline for the next release. For example next major release Q2/Q3 2011: - traits - bundling APC - large file and big number support - ob patch - unicode improvements (*) (*) lets see what ideas we come up with, might turn out to be the big thing or maybe just a small incremental tweak here and there regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 23.03.2010, at 18:15, Rasmus Lerdorf wrote: My point is that your eventual list should come from things that have been committed to trunk and survived review and tests. Sure, its only that many patches and todo items have been lingering (hello frustration?) because of the trunk situation, because we decided to then focus on 5.3 etc. Stuff like traits, the OB fixes have been flying around for a long time and just didnt get the last attention. LFS and big ints have also been on the roadmap for ages and it seems like at least for big numbers there is even a patch. If we now spend a few months to work on fun stuff (which is what we have trunk for) instead of focusing on getting this stuff finalized we are just delaying these patches. We all know that when we get towards crunch time we finalize patches way more quickly, than when we say oh lets hack on stuff for a while and see where we get. Again, for fun development there is trunk or feature branches. But we have enough stuff for a new major release right at our finger tips to start thinking about what our next release should look like instead of waiting for another 3-6 months which would obviously also imply a delay of at least 6-9 months (because big new features we come up with in the next 3-6 months will need their time to make it into trunk as well). So sure lets take until the end of April to think about a set of patches we want, but please lets not spend the next 3-6 months coming up with entirely new ideas to put into the next major update. Then again this might just be a misunderstanding and you are also just talking about giving some key features a few weeks to make it into trunk and in a state where we feel fairly certain that we can fix any issues should there still be any. In conclusion: There should of course be fun in just hacking out cool stuff, but I think for most developers a big part of the fun is actually seeing your ideas in a stable release. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On 18.03.2010, at 06:55, Andi Gutmans wrote: -Original Message- From: Olivier Hill [mailto:olivier.h...@gmail.com] Sent: Saturday, March 13, 2010 10:15 AM To: Derick Rethans Cc: PHP Developers Mailing List Subject: Re: [PHP-DEV] PHP 6 We need to focus on Unicode more than what some says, whether this means descoping the Unicode release or not. However, this means that the development focus needs to be towards new features AND Unicode, not having the new feature branch, and the siberia branch with Unicode support. I think the key to rebuilding momentum in PHP development is to not try and boil the ocean but to focus on smaller major releases. This would enable us to manage a more predictable release cycle, lower the risk for each release incl. better manage compatibility and increase motivation for contributors as they know they can have an impact and if they can't make one release they know the next isn't that far off (the latter also eliminates pressure to push pre-mature functionality into a release). Yeah, I wouldnt mind if we would aim for regular releases in late spring early summer every year. This ensures that developers scratching their own itch have a clear timeline by when their hard work can make it into a stable release. In that spirit I would not necessarily couple Unicode support and the next smaller major version. First I would suggest to build a well-defined, reasonably scoped list of functionality for the next drop. I think we should make only a few features must-haves and the rest should-haves so that only high-priority pieces of functionality can potentially hold up a release. It also helps with quality as high risk functionality that feels unstable could be pushed out if needed. This encourages pushing out functionality to our users sooner rather than later (in the realm of reason). +1 Then as far as Unicode support is concerned I think we need to work in parallel on various RFCs that can provide alternative ways of approaching the Unicode problem. Given the performance hit, memory overhead and complexity of the current implementation (which I also supported) I think we should try and look for a solution that is more pragmatic and is more explicit - giving the average PHP user the same experience, compatibility and performance characteristics of PHP 5.x while giving the more sophisticated users who need Unicode the tools to build global applications. +1 .. this all aligns perfectly with my suggestion to establish a unicode working group that I made in the PHP 5.4 branch and trunk thread. so just like you i agree that we shouldnt put the next release under the pressure of delivering the unicode answer .. if the working group gets done in time we can move it into the release plan, if not .. so it goes .. with regular releases the next chance to get unicode in isnt too far off. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug # 50755
On 18.03.2010, at 03:47, Stanley Sufficool wrote: On Mon, Mar 15, 2010 at 8:45 AM, Christopher Jones christopher.jo...@oracle.com wrote: Stanley Sufficool wrote: I have attached patches for bug # 50755 on bugs.php.net. These also cleanup to PDO DBLIB code to have less of a memory footprint and to prepare for other feature additions such as multiple rowset support. I have compiled and tested on x86. Can someone review and provide feedback. Thank you. Hi Stanley, Persistence is good, but you might need to use another way to find someone who has the skills, interest and time to review it. Maybe ask around on IRC - #php-dev-win on Freenode? Tried IRC, no response. BTW, this is a Linux Windows extension. IMO, PDO should be a big focus to get stabilized. People are jumping ship for poorer performing abstractions in PHP (ADO, MDB2, DBA, etc...) Hell, even the PHP bug tracker uses MDB2. That's a bit of a disgrace to a blessed and built in database abstraction extension. I really want to contribute and have no problem with getting reigned in with patch karma, but that will never happen if nobody cares to review. Yeah its a horrible chicken and egg situation we have with PDO. Too few people around, actually it seems too few to even review your patch when it comes to SQL server. Maybe Matteo has some time to take a peek. Especially in the beginning its very helpful to get some feedback on patches before getting direct commit access. Then again for PDO we might be at the stage where we might not even have the resources to do that :( regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
I propose that sort of a unicode working group forms but much less formal than what I make it sound like. I think the discussions can remain on internals@ and hopefully alternative approaches will be documented as RFCs. But what I mean with working group is a list of a handful of names who feel responsible to keep this topic moving until a solution is found and who people know they can contact if they want to chat or whatever. So how would that group differ from just internals@ ? hmm i think i specifically addressed this in my previous email: But what I mean with working group is a list of a handful of names who feel responsible to keep this topic moving until a solution is found and who people know they can contact if they want to chat or whatever. so i want to make sure that a handful of people feel responsible to drive this thimg forward as its a topic that requires a fair bit of research. of course anyone can contribute at anytime as well and with thid group they also have people they can contact to be brought up to speed quickly via a chat or phone call. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 18.03.2010, at 18:48, David Soria Parra d...@php.net wrote: On 2010-03-18, Pierre Joye pierre@gmail.com wrote: On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans der...@php.net wrote: I do agree that we need to do major releases more often, but just setting a time already feels wrong. It's still open source, so it's ready when it is ready. That of course should not mean that we should keep on adding features endlessly. for releases, avoid commits rushes right before the freeze, etc. As I've been said before already, I'm all for a fixed release cycle, it is then much easier to define clear priorities and roadmaps. +1. i think having a fixed release cycle has nothing to do with being opensource or not but with being more predictable for people depending on release dates. right. and again i think i was quite explict in my original mail that common sense still applies. if we have a buggy release we will obviously not release it just because. as for having enough to actually warrant a release i do not ever remember a time where there werent atleast a handful feasible proposals in varying size on the table. regard Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
Hi, I do not claim to be able to add anything to the discussion content-wise, but organizational-wise (just invented this word for no good reason), it seems that while the brainstorming is useful, I urge people to start structuring their ideas and proposals so that they can reference it later and so that the ideas do not get lost in the archives. Again the wiki is the perfect place for this. Also this will help others to collaborate in moving the idea to a full fledged proposal .. ideally with some numbers to backup any performance claims. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 16.03.2010, at 19:23, Hannes Magnusson wrote: On Tue, Mar 16, 2010 at 16:58, Derick Rethans der...@derickrethans.nl wrote: Before we add features, they need to be discussed whether we want to have them. Does that mean you want to take up a - strict RFC-and-after-3months-discussion-before-commit policy (i.e. killing the scratching-an-itch spirit of PHP) - I'm going to commit this patch tomorrow mail to internals@ (i.e. killing I need this functionality, maybe others do to spirit of PHP) Its all a question about the scope of the change obviously. There is some tipping point where it makes sense for an RFC. Remember an RFC not only serves decision making, but also provides some level of documentation (on which the final documentation can be build) for past generations (this is why I for example wrote the ifsetor RFC after we decided that we cannot currently implement it). So like Stas said .. common sense still rules. I would much rather have a development branch which everything goes (like it used to) and then make it up to the release manager to merge the features he wants in his branch (DVCS style) I dont think we ever had an everything goes HEAD .. lets say in the past we had a small very active core dev team with really short turn around times for decisions because everybody was answering on IRC or mailinglists within minutes. As a result decisions (not always for the better) were made in a much shorter timeframe than the current availability of core developers affords us. - Ilia's scalar type hint patch. And which of Ilias patches are you referring to? The original one (which is identical to the patch I sent in November 2006) or the fucking eyh, I need to please everyone so this can be in 5.3 - but still got rejected patch? I think he clearly pointed to the wiki page which lists 3 proposals. He is just suggesting we should finalize which one we want and get it in. You didn't even list the mbstring patch.. that was discussed and as far as I remember everyone thought it was great idea, just not in a stable branch. Is this tone really necessary? One you are argueing for more flexibility and then you are shooting the messenger because in a long list he forgot one thing (there are probably a few others .. we might want to go through the todo wiki pages for more)? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 16.03.2010, at 16:58, Derick Rethans wrote: Before we add features, they need to be discussed whether we want to have them. As version name for it I would like to use trunk-dev (and not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving. Right now, there are the following features that I can see we should think about: Since we do not know the name of the next version yet, maybe its best to base the name on what version it will have as a predecessor and add support for this in version_compare()? Something like 5.3post. Ok this isnt a good suggestion, but I hope you get what I am suggesting. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 16.03.2010, at 16:58, Derick Rethans wrote: I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved Eventually it should be deleted, if it helps at all in merging the OB change then it should be kept until that happens, otherwise it can be deleted now imho. The new 5.3 based trunk will emerge soon I am sure, but until then lets not bother with having to merge those changes. trunk to the branch FIRST_UNICODE_IMPLEMENTATION. +1 The next things to do is to re-create trunk from PHP 5.3; I've hold off that for now, but I'd like to do the following soon: - Declare 5.2 security fixes only (Something for Ilia to declare). - Declare 5.3 bug fixes only (and ini-mini features if so desired) (Something for Johannes to declare). +1 - the new output buffering mechanism (I can not really see why we would not want this) +1 - traits, there are also RFCs: http://wiki.php.net/rfc/horizontalreuse http://wiki.php.net/rfc/nonbreakabletraits +1 other stuff: http://wiki.php.net/todo/php60 http://wiki.php.net/todo/backlog That being said I think until we know if the next version will be a new major version, we should hold off on BC breaking cleanup stuff likes dropping register globals and friends. But we still might bundle APC with the next release for example, even if its not 6.0 .. -- As for unicode, I would like the next release to be planned independently of finding a solution for unicode, but with the clear option that it will be included if we find a good solution in time (like I said I think it would be good to shoot for a final release summer 2011, so beta phase in early 2011). I propose that sort of a unicode working group forms but much less formal than what I make it sound like. I think the discussions can remain on internals@ and hopefully alternative approaches will be documented as RFCs. But what I mean with working group is a list of a handful of names who feel responsible to keep this topic moving until a solution is found and who people know they can contact if they want to chat or whatever. Again if these guys find a workable solution that can be implemented this year and I am all for putting it into the next release. If not so be it, because I think the lesson learned in all of the PHP6/PHP5.3 release nightmare is that we should have regular releases. So I say we shoot for the release following the next one to come out in the summer of 2012. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] moving forward
Hi, I would like to ask everyone that wants to see some new feature in the next bigger PHP update to create an RFC on the wiki. I have to check why the register link [1] disappeared from the login page (anyone with a php.net svn account can just login without registering). Ideally we will simply cherry pick the features for the next release from the old todo list [2] as well as mature RFC's. Personally I also think that we should make sure that we do not spend months in this planning stage. If we do not yet feel ready to do the big leap to a new major version number, since we cannot play the lets drop some BC card in every release, then we can of course just bump the minor version number for the next release. Even if we do not solve unicode with the next release we already have plenty of good proposals on the table. But focusing development again on a single branch and the willingness to review our approach to unicode I think we can move forward again either way. So I am suggesting that we should aim to have a solid release plan (schedule and feature set) done no later than end of April. Personally I would like us to be able to look towards the first alpha for this new version in Q4 2010 or Q1 2011, but that is of course something that is up for debate. Obviously if we give ourselves a more or less specific timeframe it also limits the number of features we can deliver. But I think we should really become a bit more disciplined in this regard and maybe even work towards a semi regular cycle for new releases. I really like how PostgreSQL is doing things in this regard. Of course they still slip the dates at times, but so it goes (but they do not slip a few years .. just a couple of months). The important bit is that with regular releases contributors feel more like they will actually see the solution to their itch scratching released before they move on to other itched to scratch. It also means that if a feature doesnt make it into the release plan for the next release, developers will at least have a rough idea for the timeframe when they will have another chance to get a given feature into PHP. Plus it will make it easier for others (like distributions and app developers) to work with us. Most importantly it will spare us running into the situation we had with PHP 6 and 5.3 in the future where because we had time finishing up something we just end up piling features up for years making the release process a nightmare. I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence. But again, I really do hope that we can however wrap up the debate up by end of April. regards, Lukas Kahwe Smith m...@pooteeweet.org [1] http://wiki.php.net/rfc?do=register [2] http://wiki.php.net/todo/php60 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: moving forward
On 14.03.2010, at 20:42, Ferenc Kovacs wrote: (g)it would be better for cherrypicking and handling multiple development branches, but it the developers cant use it propery, the its PITA. Tyrael On Sun, Mar 14, 2010 at 8:09 PM, Gwynne Raskind gwy...@darkrainfall.org wrote: On Mar 14, 2010, at 12:58 PM, David Soria Parra wrote: I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence. Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/name/branch for this purpuse to not clutter branches/ with a million names. I'd actually like to bring up the question of going to DVCS for PHP. I know I was a vocal advocate against it before, but I've learned a bit since then. Anyone care to discuss? Oh no .. another dangerous topic. Again we have been there even before the switch. The idea is to keep the centralized repo on svn, because the masses know how it works, the tools are widely available and we have plenty of experience among us in how to keep svn running. I see little incentive to move the _central_ repo to a DVCS. Are the bridges to git, mercurial, bzaar etc really so bad that this topic is worth discussing (no sarcasm, honest question)? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On 13.03.2010, at 17:57, Derick Rethans wrote: I do however think that most of the current approaches of adding Unicode support into PHP 6 (current trunk) have the proper ideas behind that, but I do think that in some cases we went slightly overboard of supporting Unicode everywhere with the new unicode type. For example, we don't really need to have this for variable or function names or support every encoding for writing scripts in. (We do need to *support* Unicode there, but not with the unicode string type.) Another example is that we perhaps don't have to support every encoding out there. Right, dropping the current trunk doesnt mean that we should forget about unicode. However we need to find a balance between ease of use, performance (especially for those who do not need better unicode support) and release timeframe. So I would suggest the following things to do: - get rid of Jani's play branch - move trunk to branches/FIRST_UNICODE_IDEA - put 5.2 in security fix only mode - pht 5.3 in bug fix only mode - start adding new features (traits, Ilia's scalar typehint patch, output buffering things) to the new trunk cloned from 5.3. +1 As for the exact features to merge, lets first start with formulating a plan about what we want to see in the next release. I also think it makes sense to base the number and scope if the features on a rough idea of when we want to see this next release. In order to put together that release plan i guess we should have an RM defined first. I think Andi said the same thing on IRC yesterday. I can certainly see you as RM, but i would like to propose another newer guy for the job: David Soria Parra That being said, I also think that the model of a co-RM that focuses on the less technical aspects as proven itself with 5.3. not only does it mean the work load is spread over two shoulders, it also means that developers can get answers quicker (especially as we are all sometimes swamped with work or god forbid go on vacation). I am willing to take the co-RM role again. I can also see Philip in this role. But I think the more important question is to find the technical RM and if the technical RM feels like he can use the support he can just appoint a co-RM. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)
On 13.03.2010, at 22:52, Stefan Marr wrote: On 13 Mar 2010, at 22:43, Sebastian Bergmann wrote: Rasmus Lerdorf wrote: No, not ok. We will call the next release whatever we like. People who have written books or articles about PHP 6 inferring they knew what the final state of PHP 6 would be were misguided. We never got to the point of a final feature set much less a release date. +1 Authors that wrote, publishers that published and readers that bought books on PHP 6 need to be ... punished ;-) Is that wise and well-considered or something the community might regret in the long run? Nobody needs to be punished and I think Rasmus stayed clear of such words for a reason. The name of the next version is not really all that relevant more if the next version will be a minor bump (aka x.y+1) or a major (aka x+1.y). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ README.NEW-OUTPUT-API Zend/zend_highlight.c Zend/zend_indent.c ext/iconv/iconv.c ext/session/session.c ext/soap/soap.c ext/standard/basic_function
On 11.03.2010, at 13:27, Sebastian Bergmann wrote: Johannes Schlüter wrote: Merging such major changes in a released branch like 5.3 is no option. +1 +1 .. and not getting the agreement before committing it is also pretty low. but i guess you knew that. at the same time i know that it hurts and php6 not moving forward is the root cause there. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ README.NEW-OUTPUT-API Zend/zend_highlight.c Zend/zend_indent.c ext/iconv/iconv.c ext/session/session.c ext/soap/soap.c ext/standard/basic_functi
On 11.03.2010, at 15:21, Pierre Joye wrote: hi, 5.3/6.0/next is not the question here. This change has nothing to do in a stable branch and must be reverted as soon as possible (I will do it tonight if nothing happens until then). I also understand the need to valid this new API and my suggestion could be the best way to do it at this stage: - create a PHP_5_3_NEW_OB branch - maintain it there - merge when it is ready/stable Thanks for your understanding and work. yeah .. @jani: committing to a stable branch because you are getting a new laptop is not really a convincing argument. :) regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ README.NEW-OUTPUT-API Zend/zend_highlight.c Zend/zend_indent.c ext/iconv/iconv.c ext/session/session.c ext/soap/soap.c ext/standard/basic_functi
On 11.03.2010, at 17:26, Jani Taskinen wrote: On 03/11/2010 06:21 PM, Scott MacVicar wrote: On Mar 11, 2010, at 10:22 AM, Jani Taskinen wrote: On 03/11/2010 04:41 PM, Lukas Kahwe Smith wrote: @jani: committing to a stable branch because you are getting a new laptop is not really a convincing argument. :) Losing the one with the changes in it is. Doing patches will only cause endless headaches. Please move on, nothing to see here, it's all for GOOD anyway, fixing bugs USED to be okay in any branch. Besides, this is not end-of-world. If it is for someone, I suggest changing profession. I'd like to have branch for PHP_5_4, I'll also volunteer for RM on it. Perhaps it makes people wanting to get movement in HEAD to actually do something about it. +1 I'm all for 5.4, I have a bunch of patches against PHP_5_3 that I want to commit such a large integer support, I couldn't develop against HEAD since it's just not usable. I think we can officially call PHP6 stalled and should move forward with 5.4 and revisit unicode support in the future. PHP_5_4 is now there. Feel free. Merging the PHP_5_3_FPM might be a good idea too. could you maybe use your own svn server if you want your own private php project? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On 11.03.2010, at 18:22, Rasmus Lerdorf wrote: Ah, Jani went a little crazy today in his typical style to force a decision. The real decision is not whether to have a version 5.4 or not, it is all about solving the Unicode problem. The current effort has obviously stalled. We need to figure out how to get development back on track in a way that people can get on board. We knew the Unicode effort was hugely ambitious the way we approached it. There are other ways. So I think Lukas and others are right, let's move the PHP 6 trunk to a branch since we are still going to need a bunch of code from it and move development to trunk and start exploring lighter and more approachable ways to attack Unicode. We have a few already. Enhanced mbstring and ext/intl. Let's see some good ideas around that and work on those in trunk. Other features necessarily need to play along with these in the same branch. I refuse to go down the path of a 5.4 branch and a separate Unicode branch again. The main focus here needs to be to get everyone working in the same branch. +1 for moving trunk to a branch and moving 5.3 to trunk. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On 11.03.2010, at 18:54, Johannes Schlüter wrote: On Thu, 2010-03-11 at 18:46 +0100, Lukas Kahwe Smith wrote: +1 for moving trunk to a branch and moving 5.3 to trunk. not moving 5.3 to trunk but a 5.3 copy (branched of), 5.3 should be stable stuff (fixes) only. Guess you meant to say that, but better to be clear. err exactly. thx for clarifying :) regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On 11.03.2010, at 21:20, Jani Taskinen wrote: The main focus should be that we actually start working. And not wait for someone to do something miraculous on their own. I'm just sick and tired of the cloak and dagger style and secret meetings and committees. So please, do the talking openly on the mailing list, not some IRC channels. And no more wikis. :) i hope you mean internals and not the svn commit mailinglist. so much for dagger style .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: grossolini
On 03.02.2010, at 00:24, Guillaume Rossolini wrote: Upgrade wiki.php.net (as per lsmith's and pierre's request) indeed thats correct. thx Guillaume regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function call chaining
On 19.01.2010, at 18:03, Chris Stockton wrote: Hello, On Mon, Jan 18, 2010 at 5:27 PM, Stanislav Malyshev s...@zend.com wrote: I wrote a small patch that enables this kind of syntax in PHP: foo()(); ... I think language enhancements with no BC breaks that offer a wider toolset to programmers is a good thing. I would also like to see the other ideas in this thread implemented such as array access object creation. enhancements in the sense that they enable things that were not possible before, sure. syntax sugar that hurts readability, not really. if you are worried about key strokes switch to an IDE. if you are worried about performance use a byte code cache. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function call chaining
On 19.01.2010, at 18:39, Rasmus Lerdorf wrote: I don't mind the foo()() syntax, especially now that we have closures. But people are right, we have a longstanding feature request for $foo()[0] as well, so if we start down this path of adding chaining, we should do that one as well and see if any others make sense. I do think the syntax is a bit ugly, but I also think it is clear what it does and doesn't obscure/mislead the semantics of the call the way the (new foo)-bar() suggestion does. +1 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 29.12.2009, at 00:25, Ralph Schindler wrote:
Bump.
I really think we need to think about this problem that Lukas has brought up.
Now that the magic words have come up ('counting stat calls'), can we get
someone to weight in on the possibility of both having some kind of
include_path resolver in the 5.3 branch, and it's impact of stat calls in PHP
both without an optimizer and with an optimizer?
It seems like enough interest is here, as well as code, and those willing to
contribute the functionality.. What about on the policy front?
As you can tell, I am itching to see where this goes ;)
just FYI:
a tweaked stream_resolve_include_path() is scheduled for inclusion in PHP 5.3.3
do note that the next PHP 5.3 release will be 5.3.2, so it will be a few months
until we will see this feature in a stable release.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this
On 15.12.2009, at 20:01, Christian Seiler wrote: Hello again, Discuss away! I'm a little disappointed by the non-outcome of this debate. Very few people have responded and most of them seem to agree proposal (A) should be implemented, perhaps with the additional bind/bindTo as in my proposal and perhaps not. The problem here is: (A) was exactly the thing that was implemented and that people started to have a problem with as soon as the first or second beta of PHP 5.3 was released. And because the feedback came in so late, Lukas Johannes decided to remove $this support from closures for PHP 5.3 in order to be able to decide that later on. So basically we're at the same point where we were a little more year ago: There's an RFC for this (the semantics of $this support were discussed in the original closures RFC!) and the people who read it on internals@ support it. However, I predict that if we implement exactly the semantics that the RFC proposes, we will get into the same discussion we had with PHP 5.3 just before the release of PHP 6... (or 5.4 should there be one). So: What now? Call for a vote. This time around people cannot claim to not have had time to review the issue. Also back then we tried to play it safe because of the short time before we were to release. This time there is more time for this to mature if needed inside svn. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 22.11.2009, at 18:01, Lukas Kahwe Smith wrote: I have updated the current RFC accordingly: http://wiki.php.net/rfc/autoload_include So there are three approaches listed in the RFC: 1) http://wiki.php.net/rfc/autoload_include#proposal add a new alternative to include, which works the same except that for missing files it returns null and on success it returns the file location (unless the file already returns something else explicitly) 2) http://wiki.php.net/rfc/autoload_include#add_stream_support_to_includerequire add stream support to include/require 3) http://wiki.php.net/rfc/autoload_include#add_function_to_resolve_the_include_path fix up stream_resolve_include_path() to support streams. I would like to call for a vote on the above. For 1) and 3) I invite everybody to optionally also submit a proposal for a name. Finally optionally include in your vote if would like to see this feature added to 5.3.2 or if it should wait for the next minor/major version update instead. I would like to raise this point once more. I am a bit surprised that nobody voted, but I got a lot of feedback from people about this proposal offlist when I first brought this to the list. Then again a lot of those people were not core developers. The fact remains however that a large number of frameworks rely on the @fopen() hack and so offering a better solution sooner rather than later seems like a very good idea. Then again, no vote essentially means sticking with the status quo aka stream_resolve_include_path() (which needs some additional love as the RFC states to really serve for what it was originally intended) when PHP6 comes out. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 07.12.2009, at 14:41, Ilia Alshanetsky wrote: While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. I remember that when I was RM that the need for code freezes was one of the most painful things to manage. So not having to deal with that seems like a very appealing target for all involved. As for risk of missed patches and confusion. I think Pierre did the best he could to improve the transparency of the process with the wiki page. However we still have plenty of ways to make this even clearer and more obvious to follow. Especially integration into the bug tracker (aka milestone support) would go a long way here. Making sure that every commit has a bug id attached (or if necessary gets a bug ticket created on the fly and the id injected into the commit) could also help. Obviously such infrastructure will not materialize over night, but I would urge everything to not drop the idea entirely. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 07.12.2009, at 14:54, Pierre Joye wrote: As far as the wiki goes, most people don't even know it exists If a PHP core developer does not know about it, then we have a serious problem. I think it was mentioned on this list sufficiently often, but then again it came along fairly ad hoc. However I do agree that the wiki is not the right place for this in the long run. Like I said, I believe the bug tracker is the place for this by adding milestone support. This would also be the natural place to note why a patch is not merged for example. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 07.12.2009, at 15:13, Ilia Alshanetsky wrote: As far as the wiki goes, most people don't even know it exists If a PHP core developer does not know about it, then we have a serious problem. There are at least 4 people I spoke with that didn't know about it, I would say there are probably more. Well that only means we need to make sure that developers know about stuff like this. Do we need an (irregular) newsletter to inform people? I mean we have had this problem as well with commit freezes, but there it was actually a bigger problem. If we do stick with the wiki for now .. then all that needs to happen is to inform relevant developers once .. and nothing breaks if they do not know about it at a fixed date .. like with a commit freeze. In other words, the problem might exist, but its solvable and is unrelated to using a branch or not. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 07.12.2009, at 20:46, Stanislav Malyshev wrote: Hi! With one tweak: 2a) Committing to 5_3 and 5_3_2 in one go is bad bad. The 5_3_2 commits should be explicitly merged in separate commit. Right, I agree (I implied that but it's good to say this explicitly). As for wiki, I don't care if it's wiki, shmiki or anything - only thing important is that we have a list of things which is public so RM has it and anybody can see what happens with it. I think the wiki can only be a temporary solution and this should be managed entirely inside the bug tracker (*dream*). A new bug tracker that addresses our needs as they are today would really help in so many ways. But its obviously a big task. However for 5.3.2 it would be ideal to at least parse out bug ticket id's from the commit messages and when a reason for not merging a ticket is added to the wiki it would be automatically submitted to the bug tracker as a comment. Not sure how easily this could be done though and I cannot commit time to checking this out myself :-/ regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] session_set_save_handler(class)
On 22.11.2009, at 06:12, Arpad Ray wrote: Attached is a patch (against HEAD, includes tests) which allows users to extend any session handler in an object oriented fashion. By extending the new internal class SessionHandler, users can wrap or override methods of whatever session handler is in use, or implement a complete custom handler. Usage notes: - Calling session_set_save_handler(class) after session_set_save_handler(a, b, c, d, e, f) wouldn't transparently extend the first sounds useful. i assume with this i could extend for example the session handler that comes with the Memcached extension? could you provide a code example of how that would look like? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] suggestion about ternary operator
On 22.11.2009, at 03:13, D. Dante Lorenso wrote: Lukas Kahwe Smith wrote: On 21.11.2009, at 22:29, Dante Lorenso wrote: I would love to restate my recommendation for the function filled. Which is the opposite of empty. Filled would accept a variable number of arguments and return the first where empty evaluates as false. Like empty, filled would not throw notices for undefined variables. This is not the same as the ifsetor debate because filled is opposite empty and cares not about isset. did you even read the RFC? Yes I did, and all I see is this in the References section: Suggestion to leave an empty() variant out of the picture since this feature can be implemented in userland, though this of course not provide the full functionality of empty() which does not trigger notices for missing variables I didn't see my proposal listed in it anywhere. See this recommendation from 3 1/2 years ago: - May 03, 2006 http://www.mail-archive.com/internals@lists.php.net/msg21617.html Maybe I am then misunderstanding your proposal, as to me it is clearly covered and deemed not possible: http://wiki.php.net/rfc/ifsetor#rejected_features $var = ifsetor($var, $var2, admin); However this is currently not possible to be implemented without major slowdowns to the engine. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 11.11.2009, at 14:50, Greg Beaver wrote:
stream_resolve_include_path() as currently constructed could not be
intercepted, and is actually unable to process an include_path that
contains streams. I'm guessing it was written long before PHP 5.3.
This could be easily fixed by having stream_resolve_include_path call
zend_resolve_path() instead of doing its own internal calculations.
With these changes, an opcode cache could easily cache the results.
ok. sounds like something that should be done.
As for your naming concerns, if we were to add an alias called
is_includable() to stream_resolve_include_path(), that would be much
clearer:
if (is_includable($file)) {
include $file;
}
The assumption here is that we are simply testing whether the file
exists and whether php can actually read the file, not whether the file
has syntax errors. A file with syntax errors is an exceptional
situation, and should be handled by a clear fatal error, imo.
Well for all I care it could remain with stream_resolve_include_path(), though
I am not sure if we really need that stream namespace, then again its a
function that will not be used a lot in daily coding, so I do not care either
way.
I have updated the current RFC accordingly:
http://wiki.php.net/rfc/autoload_include
So there are three approaches listed in the RFC:
1) http://wiki.php.net/rfc/autoload_include#proposal
add a new alternative to include, which works the same except that for missing
files it returns null and on success it returns the file location (unless the
file already returns something else explicitly)
2) http://wiki.php.net/rfc/autoload_include#add_stream_support_to_includerequire
add stream support to include/require
3)
http://wiki.php.net/rfc/autoload_include#add_function_to_resolve_the_include_path
fix up stream_resolve_include_path() to support streams.
I would like to call for a vote on the above. For 1) and 3) I invite everybody
to optionally also submit a proposal for a name. Finally optionally include in
your vote if would like to see this feature added to 5.3.2 or if it should wait
for the next minor/major version update instead.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 22.11.2009, at 18:01, Lukas Kahwe Smith wrote: So there are three approaches listed in the RFC: 1) http://wiki.php.net/rfc/autoload_include#proposal add a new alternative to include, which works the same except that for missing files it returns null and on success it returns the file location (unless the file already returns something else explicitly) -1 2) http://wiki.php.net/rfc/autoload_include#add_stream_support_to_includerequire add stream support to include/require +1 3) http://wiki.php.net/rfc/autoload_include#add_function_to_resolve_the_include_path fix up stream_resolve_include_path() to support streams. +1, resolve_include_path(), +1 for 5.3.2 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] suggestion about ternary operator
On 21.11.2009, at 06:12, Alban wrote:
This is not a big problem but if a solution exists, this would be so
cool ! Especialy when we have to check existance of twenty or more key in
array. Code would be be lighter and clear.
Since i use PHP, I always have in my 'common function file' a function
like that :
function getIssetVar($var, $default) { return ((isset($var)) ? $var :
$default); }
So is it possible to make a little improvement on this operator or
introduce a new operator or a core function which do that ? What's your
feeling about it ?
this feature request has already been discussed and declined:
http://wiki.php.net/rfc/ifsetor
please review this rfc before continuing this thread.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP6's future
On 18.11.2009, at 02:24, Greg Beaver wrote: What needs to happen is for developers to focus on finding problems highlighted by failing .phpt tests. The most complex extension that needs some loving is the SPL extension. I would hazard a guess that if these .phpt tests are fixed, a large number of roadblocks will disappear. AFAIK PDO is also in a very broken state, though independently of PHP6 I am currently hoping to revitalize PDO development, which might also lead to building up the necessary resources/skills to get HEAD fixed up too. Anyways, to me it boils down to 2-3 people really putting in lots of time to move things forward and to build up momentum again. We all know how it feels to add stuff onto something that is fairly broken and who's future is not yet certain. We all hate wasting time, so those 2-3 people will mostly reassure that time spend on HEAD is not wasted. In this light when I last brought up this topic. Not sure if on IRC or the mailinglist it turned out that 3 different approaches were seen by people. Again who ever takes the helm on this will hopefully realign the community behind just one: 1) similar to Kalle's suggestion, clean up HEAD 2) make HEAD a proof of concept branch, turn 5_3 into HEAD, reimplement just the features we in the end found useful from HEAD 3) make HEAD a proof of concept branch, turn 5_3 into HEAD, implement a string class (both a unicode and a non unicode version) along the lines of the intl extension to bring unicode functionality to PHP but in a way that lets people easily switch between unicode aware strings. I think I remember that 2) got the least support. Ilia was the main one argueing in favor of 3) and Derick was very much pro 1). I am putting this out there not because I am looking forward to a lengthy discussion on this, but more because I feel that who ever takes on this task should know that there are different opinions on how to best proceed. In the end however I think that who ever does the work will probably get the biggest say in how things play out .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The inconsistencies/flaws of PHP5's object model
On 18.11.2009, at 09:23, Jingcheng Zhang wrote:
Hello internals,
I've just occured a syntax problem in the following script:
?php
class C {
public $n = 1;
}
$o = new C();
$o-f = function () use ($o) {
echo $o-n;
};
$o-f();
?
The result of this script is Fatal Error: Call to undefined method C::f().
I don't know this is the expected result. After trying more tests of
adding/removing properties on the fly, I concluded these
inconsistencies/flaws:
1. There is no way to add/remove instance-level members (both properties and
methods) to class dynamically, but a way to add them to instance itself,
which is a little buggy as above codes turns out;
2. There is no way to add/remove static members dynamically either;
3. There are __get(), __set(), __call() for instance-level members, and
__callStatic() for static methods, but lacks __getStatic() and __setStatic()
for static properties;
4. While using static class as object (general concept of object, not
instance here), it's extremly complex to simulate prototype object, as
static members simply do'not duplicate themselves at all while inheriting,
therefore all of the child classes share a single static member of the
parent class;
5. The inheritance rule of static member is not well documented, developers
has to try it out themselves;
6. Static methods are allowed in interfaces, but not allowed in abstract
class, which breaks the rule of abstraction;
7. An interface which has only static methods cannot ensure static methods
in a class which implements it.
Sorry to raise so many complaint, but these inconsistencies bring me a big
headache when developing. I would like to hear the design rules of PHP5's
object model, at least, the explanations of the above inconsistencies.
Thanks very much!
It feels like a lot of these points have been raised before (especially in the
thread where the addition of closures where discussed). It would be nice if you
could turn this into an RFC, maybe digg a bit in the recent archives as well.
This would help to make it easier to find out why something wasnt done etc.
This helps in avoiding redundant discussions, but also helps people if after
all certain changes do become possible/feasible eventually.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] suggestion about ternary operator
On 21.11.2009, at 22:29, Dante Lorenso wrote: I would love to restate my recommendation for the function filled. Which is the opposite of empty. Filled would accept a variable number of arguments and return the first where empty evaluates as false. Like empty, filled would not throw notices for undefined variables. This is not the same as the ifsetor debate because filled is opposite empty and cares not about isset. did you even read the RFC? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
On 12.11.2009, at 15:27, Ralph Schindler wrote: There is one key piece of information to keep in mind about this proposal. This is based on the assumption that all autoloaders need to do this type of include_path check. I (now) feel this is questionable concerning that particular use case. The best practice should be to only have autoloaders for a specific namespace, this would mostly solve the is it there? type of fopen/ include_path check. If NamespaceA registers an autoloader for itself, it should not try to resolve and load files from other Namespaces, for example NamespaceB. This idea is partially taken care of in the proposed SplClassLoader .. http://gist.github.com/221634 .. assuming the above best practice, a namespcae should know whether or not to try to include something inside it's own namespace, and if something is not there, an E_FATAL (or potentially an exception) is the best option when include does not work. I also have a question as to how the argument: throw=true comes into play in the current spl_autoload_register (does it affect this proposal too?) http://github.com/php/php-src/blob/PHP_5_3_1/ext/spl/php_spl.c#L422 ON THE OTHER HAND, I think it is important that we should be able to check for the existence of a relative to include_path location regardless of autoloading consequences, and that is what sara attempted with stream_resolve_include_path, even though I'm not fond of the name. your argument has some merit, however i think that the use case should still be supported. well even inside your own namespace it can be tricky to know the file name. for example in MDB2 i allowed the creation of modules. these could either be generic or rdbms dependent. since i did not want to have to maintain some registry that knows all modules (especially since modules can be added by users), i had to search for the right class name by seeing which file was available (either a directory with the module name and rdbms drivers as the php files .. or a generic php file). there might be other similar use cases, like having to deal with legacy code. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 11.11.2009, at 10:47, Richard Quadling wrote: 2009/11/11 Lukas Kahwe Smith m...@pooteeweet.org: [snip] Would using a userland-based set_error_handler() be of use here? If, under normal circumstances, blind include() is what is used, then trapping the error when it fails would be when you could test for whatever it is you want to test for? Well this makes it impossible to handle the issue locally, which creates all sorts of issues when you just want to drop in a frameworks autoloader. It also means that you now globally handle such failures, where you do not know if in case the file is missing there will be additional logic locally to handle the failure. Furthermore unless you use track errors you would not be able to determine if the load failed because of a missing file or a syntax error. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 11.11.2009, at 01:50, Greg Beaver wrote:
if (can_include($file)) {
include $file;
}
I am sure you focused on the technical aspects. Just wanted to say
that for a name can is not ideal, because there is no gurantee that
the file will not have syntax errors. As such something with exists
is better (for example include_file_exists(), though also not
ideal) .. Stas proposal of a file_find() is also good, but I think
it would be nice to have include in the name.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
