Re: [PHP-DEV] PDO statement execute enhancement
Marian Kostadinov wrote: Yes, that's my idea - to ignore keys that are not defined as placeholder. And not only for objects but for arrays also. I do not know the implementation in PDO, but the implementation I made in MDB2 only tries to parse the placeholders if it has to emulate or detects that a placeholder type is used that needs to be rewritten for the given RDBMS. If PDO has a similar implementation it would mean now that PDO always has to parse the entire query to determine which keys to ignore. I feel this is suboptimal and therefore I would be opposed to this change. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO statement execute enhancement
Michael Wallner wrote: Derick Rethans wrote: On Wed, 9 Aug 2006, Marian Kostadinov wrote: But that is not executed because we have some additional key/value pairs. So the idea is to allow this. Also I suggest we allow using object along with an array. This is a common situation also. Actually, it is dependent on the driver what happens here, which is not at all documented either. However, it would be nice if this indeed would work. I second this. Being able to use Objects probably only makes sense if we ignore additional keys that have not been defined as placeholders. I do not think that this change makes sense though. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Jeff Moore wrote:
On Aug 4, 2006, at 3:23 AM, Derick Rethans wrote:
- Add a new flag to methods (at the implementation level) that will
allow to flag them as 'strict'
Hello,
Would exposing this flag to the user at method level get a bit verbose
for those who want to use it? Perhaps a class level flag for all
methods? Wasn't that proposed earlier? Its a long thread to follow,
forgive me if I've missed something.
Yeah if we do allow a flag for methods, then we should also have one for
the entire class. But if we reuse the "interface" keyword things will
get tricky. I doubt the strict camp wants to allow people to add method
bodies in interfaces and "class interface foo {}" looks odd too.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Zeev Suraski wrote: It's my list actually, so I'm definitely +1 on that :) Sorry, did not want to take away credit from you Zeev :) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Derick Rethans wrote: - Add a new flag to methods (at the implementation level) that will allow to flag them as 'strict' - In case such a strict method is improperly overridden - error out (E_ERROR) - In case a non-strict method is improperly overridden - emit E_STRICT i am fine with that proposal .. if we do split up E_STRICT into E_STRICT (feature is not clean "proper" code) and E_DEPRECATED (feature will be dropped in the next major release) also note that the first two points in Derick's list only apply to classes on the C level .. userland classes will only trigger E_STRICT if they are improperly overwritten. will it be possible to get the information about the strictness of internal classes via the reflection API? or will we leave this to documentation only? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Derick Rethans wrote: On Thu, 3 Aug 2006, Lukas Smith wrote: I still think that a flag on a per class basis would be the better solution, but I guess I can accept this change. I don't think it is better as it would require somebody (in one of the teams) to modify their source files. Err? Code that already works, still works if we make the loose mode the default. Anyone who writes new classes can make use of a new strict flag however. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Hi, well it seems that the initial vision of E_STRICT to denote future deprecation is no longer valid. Then again it might have been a misunderstanding from the beginning as E_DEPRECATED would have been the more obvious name in that case. I still think that a flag on a per class basis would be the better solution, but I guess I can accept this change. This reminds me again about my question of how E_STRICT warnings are added and how things are then handled (E_STRICT becomes E_ERROR or the feature is removed entirely) with the future releases. I think a clear, written down policy is needed (and as always may be overwritten via common sense on a case by case basis). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Rasmus Lerdorf wrote: Sure, and I agree that we should find a comfortable middleground, I'd just like to see a little less criticism of Marcus and some more civilized discussion. As far as I am concerned, Marcus' approach of Nobody has criticized Marcus work. I have not heard anyone claim that the additions are not useful. There was just questions if we should not preserve the old way and what should be the default. The only thing I criticize Marcus for is to call everybody stupid that thinks the old way had its uses. But that is unrelated to his awesome work on PHP OOP. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Jared Williams wrote: PS: An real-life example from those wo prefer the old behavior would be nice ;-) -soenke Yes, I having a hard time imaging one, other than some quick fix. I'd much rather have some decent refactoring tools. The fact of the matter is you do not need the old behaviour (just like you do not need to new behaviour either) to wrote code. "Proper" planning would enable anyone to steer clear of having to rewrite the signature of a method in such a way that it becomes incompatible with the parent. However glue script languages are about rapid prototyping and less about planning. Obviously planning is good and important, however it requires a lot of effort to do it in a clean OOP way. Especially since I am quite certain that for a lot of situations clean OOP (as in maintaining the is instance of relationship for every method) is not necessary or even relevant. So here is a real world example. Of course it will probably get a lot of PEAR sucks anyways flack, but so it goes. The base PEAR class implements an incredibly flexible raiseError() method that is overkill for most classes. In proper OOP you have to make the parent implementation the lowest common denominator and add flexibility (as in additional parameters) inside children. For whatever reason this was not done. Changing the signature later on was effectively not feasible as that would have broken BC. So in PEAR::DB (as well as MDB and MDB2) this method was overwritten with a simpler signature. Of course like I mentioned in a post before, an alternative that will be proper OOP would have been to add a simpleRaiseError() or whatever method that simply calls parent::raiseError(). However this meant cluttering the API with the parent method and this new method. So the "clean" solution would have resulted in clutter. In all the years of PEAR::DB etc useage I have not seen a single issue that resulted over this, or even anyone report and issue over this until it was disallowed in PHP CVS and someone told me that MDB2 doesnt work with HEAD. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Derick Rethans wrote: On Wed, 2 Aug 2006, Lukas Smith wrote: again i feel that people who want to use PHP as a "proper" OO language will definately benefit from a strict mode if they are willing to put in the extra planning. however alienating the userbase for this by making it impossible to keep the old low planning OO style would be a bad idea. So then the only option is to introduce a "i-dont-want-to-care-about-oo-in-my-classes-mode" for the people who simply don't care. yes .. it should be possible to set this on a per class basis. and children should be able to change the mode. classes in lax mode might also return false unless the classes match exactly. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Derick Rethans wrote: On Tue, 1 Aug 2006, Robert Cummings wrote: On Tue, 2006-08-01 at 23:41 +0200, Marcus Boerger wrote: Hello Michael, nobody forces you to use OO if you don't like it but it is as it is. And It is as it is, but not as it was. PHP4 allowed signature mismatching. Yeah, but PHP 4 didn't have OO support, so that argument doesn't count. Whatever .. then call it PHPOO .. either way it is obvious that: 1) proper OO code requires more planning. in the current context it means that you need to put more time into planning your inheritance structure. making sure that your parent has actually the most simple signature you will ever need, and expand on this interface in your children. 2) it is simply often not feasible to change the parent inside a large code base if you decide that its necessary to change the signature. obviously this breaks the "is instance of" relation for that method. a possible solution is to simply add a new method in this case. this is a way out of the dilemma. however it means that you may end up adding several methods and leaving in several that are likely to never be used. and more importantly i have seen plenty of OO code that does not require the "is instance of" relation for any or atleast all methods. remember PHP is a glue language .. to me this means it should stress freedom above all. that being said i think it is also a good idea that PHP is becoming a first grade language in its own right. however dropping its ability to function as a rapid glue language is a bad idea. and i personally have made good use of the PHP4 OO model and so just telling me to go back to procedural is not acceptable. again i feel that people who want to use PHP as a "proper" OO language will definately benefit from a strict mode if they are willing to put in the extra planning. however alienating the userbase for this by making it impossible to keep the old low planning OO style would be a bad idea. regards, Lukas regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Rasmus Lerdorf wrote: Relax people. There are certain paradigms and expectations people have. The original PHP design met the expectations and paradigms of a loosely typed procedural language. Now, some 12 years later we are trying to meet a new class of expectations. We have kids coming out of universities today who barely know what procedural programming is. All they know is OOP and we want to give them something that meets their expectations. We have to be careful that we don't ignore too many OOP rules or we would fail to meet these expectations. The PHP way is not to make everything look like the procedural approach. The PHP way is to cater to peoples' existing knowledge and build a language that does what people expect it to. That doesn't mean we shouldn't loosen up some OOP rules where it makes sense, but it also doesn't mean we should ignore them completely. sure .. and all the old users that have become used to how OOP in PHP works are to be ignored? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Richard Lynch wrote: So what exactly is the purpose of enforcing the same args here? Does it make the C code under the hood simpler? Does it make PHP an order of magnitude faster? I'm honestly just sitting here asking myself WHY anybody wants this, and not finding any benefit at all. I think this was stated before in this thread. The academic idea of OOP is that children are essentially expanded variants of their parents, but for all intends and purposes their interface is just like the parent with some additions. So in other words a child is an instance of all of its parent. If you remove arguments from the signature of methods this no longer applies and you have violated this OOP rule. It should be possible to implement your inheritance in such a way that this will not bite you, but I do not think its PHP job to police this by default. I want to bring up again the idea of an optional strict mode (alternatively we can talk about a lax mode, but I think it makes more sense to maintain BC and stay lax by default) that does it all according to academic OOP (check signature of children, disallow on the fly static properties etc.). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory_get_usage with new Memory Manager
Dmitry Stogov wrote: Right now memory_get[peak_]usage() show the amount of REAL memory that PHP (Zend Memory Manager) takes from system. Previous memory manager showed size of emalloc()-ed memory without malloc() overhead. Also it didn't consider internal caches. Shouldn't we make the old behavior the default here? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding pecl/zip to 5.2
Hi, so it seems to me like several core developers think its a worthwhile addition to core if the class is renamed to ZipArchive (if I understood Pierre correctly in a private IRC exchange he is ok with renaming the class). The idea of a PDO for archives does not seem to generate much support among core developers. Now as for marking it EXPERIMENTAL. This seems to be the process we have chosen in the past for extensions that are added to core from PECL, including the other extensions who are added in 5.2. The future relation of PECL and core should be discussed however. Anyways I guess Ilia has gotten sufficient feedback on the list to make a decision now? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /main rfc1867.crfc1867.h
Hi Stefan, I will put rfc1867 updating on my PHP6 todo list so in case it somehow is forgotten I can try to remind you. As for PHP 5.2 the key question is if you deem this production ready and also if Ilia thinks its still in time to add this. From the words you used I think it sounded a lot to people (including myself) like this code is still rather untested and since 5.2 will soon go into RC1 they were concerned if the time was sufficient to make it stable. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding pecl/zip to 5.2
Andrei Zmievski wrote: FWIW, I'm fine with moving it into core if EXPERIMENTAL is removed and it's renamed to ZipArchive. Is that a new (double) standard? It used to be common practice to add new extensions as EXPERIMENTAL to core. IIRC all the last PECL extensions that got moved to core were added like this. Maybe its my fault, but on the todo list that Ilia also posted to this list both json and filter were listed as being added as experimental (although Rasmus just told me on IRC that he does not see json as experimental). For that matter are the new datetime/datetimezone classes experimental? EXPERIMENTAL is just a way to cover our asses against not being able to break BC if we find out we screwed something up in a new extension. Bringing something into core obviously gives us a larger testbed and so new situations are likely to popup. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: E_STRICT
Lukas Smith wrote: Lukas Smith wrote: Ok I see 2 options: 1) Obviously one solution would be to disallow making anything an E_STRICT notice that is not available since the first release of the given major version. Pierre and Anthony seem to favor this solution. So it sounds like Derick is in this camp too. 2) Adding such a filter API into PHP internals however seems like a considerably effort. Therefore my proposal would be to simply add a defined "header" to all E_STRICT messages that contains the PHP version in which this E_STRICT message was added. This way PEAR could provide its developer with a simple filter method that would take an error message inside a customer error handler and determine if it should be filtered out or not. From IRC discussions and the PEAR ML I think Michael and Marcus favor this solution. I also prefer this solution. Any more opinions on this? I guess there is also option 3) aka "I dont care, lets not worry about it" regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding pecl/zip to 5.2
Edin Kadribasic wrote: Richard Quadling wrote: So where does this leave adding pecl/zip to 5.2? PDO is not core for Windows so should zip? PDO is bundled in the core PHP distribution. Pierre was not asking for Zip to be enabled by default, just to be a part of the distro. Yes, exactly. As for the PDO for archive format argument: The main reason for a base PDO extension was the idea of providing a framework for database extensions. The question now is if such a thing is necessary for archive formats? I think it would be sufficient to ensure that there is a common API for all common aspects. Since we are talking about OO here, all you need to do then is to use the constructor of the given format and you are done. So note for example that while PDO has a common constructor for all RDBMS it does not provide a common DSN format either. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Derick Rethans wrote: On Fri, 21 Jul 2006, Lukas Smith wrote: Richard Quadling wrote: I agree with this point. The sub class is a valid entity in its own right. The methods (and the parameters) it has are part of that class. If they overwrite a parent class's method, then fine. Instance of either class would have different parameters for the same named method. Its not about being "right". Acedemically Marcus changes are correct. The question is just if we want to force this way of working onto PHP, or if it makes more sense to make it optional. I would say that if you want to use it in the "wrong" lenient way that you need to mark your classes as such and not the other way around. This might also have the effect that people see PHP as a better language (because of the OO stuff is "correct" by default. Or it will mean that the established user base gets ticked off and the other people see PHP as just playing catch up to Java. Now is probably the time to hire a consulting firm ;) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Richard Quadling wrote: I agree with this point. The sub class is a valid entity in its own right. The methods (and the parameters) it has are part of that class. If they overwrite a parent class's method, then fine. Instance of either class would have different parameters for the same named method. Its not about being "right". Acedemically Marcus changes are correct. The question is just if we want to force this way of working onto PHP, or if it makes more sense to make it optional. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RfC: rethink OO inheritance strictness
Michael Wallner wrote:
Hi (Marcus),
unfortunately I'm not very happy with the direction OO strictness takes
in PHP. I'm sure I'm not alone and many people second this feeling.
Precisely, let's have a look at the following:
[EMAIL PROTECTED]:~/build/php-5.2-debug$ cli -d"error_reporting=8191" -r
'class c{function f(){}} class d extends c{function f($a){}}'
Strict Standards: Declaration of d::f() should be compatible with that
of c::f() in Command line code on line 1
[EMAIL PROTECTED]:~/build/php-unicode-debug$ cli -d"error_reporting=8191"
-r 'class c{function f(){}} class d extends c{function f($a){}}'
Fatal error: Declaration of d::f() must be compatible with that of
c::f() in Command line code on line 1
I *really* think that this enforcements are no good idea and
I _beg_ you that we leave this "area" to interfaces.
Aternatively there has been the idea of a flag to mark classes that are
to follow stricter rules.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding pecl/zip to 5.2
Derick Rethans wrote: On Thu, 20 Jul 2006, Pierre wrote: Do you really ask me what Zip say? You miss the point. If you do "new Zip" ... then I've no idea what the object you get represents. However, doing "new ZipArchive" makes sense as then you know the object represents a ZipArchive for example. Just "Zip" doesn't say anything about the object so I consider it a bad classname. I am definately in the camp that wants zip handling in core, but I also think Derick's naming argument makes sense. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding pecl/zip to 5.2
Sean Coates wrote: From my experiences the problem with this is many shared hosts wont install non core modules, so the more modules moved from core to pecl the less flexible php will be and the less use it will be. I understand the need to keep the core code maintained and as clean and lean as possible, but we also need to look at what developers need to create applications that can be used with mass virtual hosting. This is a valid point, but it represents a chicken-and-egg problem. Shared hosts are used to deploying PHP Proper and ignoring PECL, because in the past, core was the only repository for everything. As PECL grows in popularity (and as users demand more PECL installations), we can hope this these hosts become more flexible. At least that's what _I_ think. I think we should make this a PHP6 todo item. A new major version is a better opportunity to get a change of minds, than a creeping slow change, which is about creating sufficient pain in our users so that shared hosters finally get the clue. Until then we should add extensions that we think are reasonably frequently required and move out the ones that we deem obscure. I think zip is quite reasonable to get added. As for the coordination of PECL packages that are symlinked to internals, it sounds like this really needs some thinking before PHP6, because there are already a number of extensions affected and it does sound like its a little bumpy. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Date flamewar summary
Ilia Alshanetsky wrote: Class names are not case sensitive, so it does not matter if it is FooBar or fooBar or even FoObAR. Ilia, since PHP5 we are case preserving. So it does matter, though only stylistically, not technically. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2)/ext/date php_date.c php_date.h)
Michael Wallner wrote: Andi Gutmans wrote: I agree completely. Can't we just call the damn thing DateTime stick it into RC1 of PHP 5.2, and move on? +1 for DateTime and DateTimezone; the flame was funny, but let's move on, please. +1 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
Steph Fox wrote: I already agreed with Pierre over this, and offered to support him in giving PEAR support for upgrading. So long as it goes in from the start of 5_3 branch, why not? (Like it should've done at the start of 5_2 already.) I think it's worth holding out for a few more months to get sane names in there - and the original names are the sanest, least confusing names. OK, Steph. This is the last time before I get pissed off. You have no idea how PEAR works. We actually have defined processes for things. Even if you do not agree with them, you are in no position to know what follows this standard. And you are also in no position to suggest here that you are willing to take over maintaince of anything in PEAR. This also goes for Marcus and his "PEAR must be punished" statement. The topic is the naming of the date class in light of a known issue for existing userland code. Stay on topic and stay with topics you actually have a clue about. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2)/ext/date php_date.c php_date.h)
Rasmus Lerdorf wrote: I can see Andrei's argument for the iterator stuff where you do actually have to type it often, but his identifiers are already unlikely to clash and we could probably make an exception there. Well then we need to document this! In my proposal I also noted: Iterators and Exceptions are however simply postfixed with "Iterator" and "Exception". Examples: * ArrayIterator * LogicException However I fear that the PHP community is instead adopting this as their userland naming standard to follow internals unless we quickly move and tell them not to. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
Marcus Boerger wrote: All that nonsense above said. I just would like to see that we agree on having an official todo thing like lukas' site. Actually we should do that on php.net somewhere and have a selected group get cvs access right to that and have changes mailed to internals@ so that people have a place to discuss any decisions +1 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
Steph Fox wrote: Yep, that's a fair point. But at the same time, PEAR should be namespacing their classes - and in fact the date class in PEAR is breaking PEAR's own coding standards in that respect. Why should classes Steph stay on topic. Date follows current PEAR naming standards just fine and its not even the topic anyways and taking shots at others is a lame attempt at giving your arguement more credit. The topic is what right we (PHP) want to claim for picking "obvious" identifiers? I tend to say that we should tell the world to prefix and keep internals free from a PHP prefix. We already prefix with the extension name (how does that tie in with the timezone functions in ext/date?). Is the only thing we are argueing about the naming btw? Or are there any technical issues in the new date extension beyond the naming issue? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2)/ext/date php_date.c php_date.h)
Rasmus Lerdorf wrote: I think we need to rename it. php_date or _date or something. I don't really care what the name is, but I think we are too late in the game to get the 'date' identifier. The other functions enabled are fine and quite necessary actually. Both timezone_abbreviations_list() and timezone_identifiers_list() are quite useful. This is a very key decision to make as we add new OO features, and other abstract types. Does PHP reserve a right to claim obvious identifiers or should PHP require from itself to namespace things like this with a prefix (php_)? Regardless what decision we make I think its high time that we document what approach we want to take. A while ago I proposed such a standard [1], but it obviously requires a decision from internals to be of any merit. In the proposed document I gave PHP the right to claim whatever identifiers it chooses, therefore pushing up the responsibility of prefixing identifiers to end users (including PEAR). regards, Lukas [1] http://oss.backendmedia.com/UserlandNamingGuide -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.2 Status Update
Ilia Alshanetsky wrote: It's been quite sometime since 5.2 was branched and looking over our "todo" majority of planned changes were made. Therefor I'd like to make an RC1 on Thursday next week and start the stabilization cycle of 5.2, so we can get a final in about 2 months. Once we start stabilization cycle, no new features will be accepted, so please use this week to commit any missing new features or major patches that have been agreed upon and not yet applied. I would also appreciate it if people could let me (or Ilia) know of any todo's already completed (or no longer planed) that are listed on the todo site: http://oss.backendmedia.com/PhP52 Open todo items on that page are "assigned" to the following people: Derick, Georg, Wez, Marcus, Pierre, Ilia, Dmitry, Rasmus, Gopal regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: E_STRICT
Lukas Smith wrote: Ok I see 2 options: 1) Obviously one solution would be to disallow making anything an E_STRICT notice that is not available since the first release of the given major version. Pierre and Anthony seem to favor this solution. 2) Adding such a filter API into PHP internals however seems like a considerably effort. Therefore my proposal would be to simply add a defined "header" to all E_STRICT messages that contains the PHP version in which this E_STRICT message was added. This way PEAR could provide its developer with a simple filter method that would take an error message inside a customer error handler and determine if it should be filtered out or not. From IRC discussions and the PEAR ML I think Michael and Marcus favor this solution. I also prefer this solution. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT
Pierre wrote: if foo-1.2.1 is E_STRICT compliant with 5.1.4 and foo-1.2.2 with 5.2.0, update to 1.2.2 must be the way. It is the safest way, the past shown us that some E_STRICT can be related to (sometimes critical) bugs and we should treat them as bugs. Also, I do not like the additions of pedantic E_STRICT, but that's another issue. I would hate to start to add such notice detections in any of my code, including pear. That requires that E_STRICT will not be added for any feature that is not available since the first release of a given major version. Otherwise you can't publish 1.2.2 without increasing the lowest compatible php version. Which in turn is impractical as the PHP world will never be fast enough to keep up with patch or even minor PHP releases. Hosters are always behind 1 or 2 minor versions, at best. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT
Antony Dovgal wrote: Well, that's what major versions are for, right? Bugfix releases are for bugfixes, while major versions may introduce new things and features. Err we add features in minor (and even patch level) versions all the time. Sorry, I still fail to see a reason to "filter" error messages.. The point of E_STRICT is to encourage forward compatible code. However as I pointed out for many developers it will not be feasible to always target the latest version of PHP. This means that they will be coding against some other, yet defined PHP version. So for example 5.2.1 is the latest version 5.1.2 is the target for development. Now there might be several new E_STRICT messages that cannot be worked around without increasing the target development version. This means that either: 1) I turn off E_STRICT on my development box to retain my sanity 2) I have some filter mechanism that ensures I only get E_STRICT messages that existed in 5.1.2 What I am proposing is a tiny weeny change in PHP to make it trivial to implement 2) in userland. This makes sense because as time progresses I might increase my target version. Maybe even port to a new major version. In which case I am much better off having code that is already E_STRICT compliant uptil 5.1.2. So there will be much less work for me to do. Code generally will be much easier to port to new major versions that drop deprecated features. Adoption rates of new major versions can go up. Everybody is happy. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT
Antony Dovgal wrote: Lukas, I thought we already discussed and agreed that the only acceptable solution is NOT to add any E_STRICT messages if the recommended way didn't exist in first release of the major version. This apparently requires versioning and its support in PEAR. And personally I think this is the only solution we can accept. That would work fine as I pointed out in the email, but would limit the scope of E_STRICT. The point of E_STRICT was to quickly let people know about things that are no longer recommended/have become deprecated. Waiting until the next major version for new features would diminish that. Adding some kind of hypercomplicated API for "filtering" E_STRICT is definitely huge overkill. Not sure if I explained things this badly. All I requested was that the error message contain some "header" with the php version that notice was added. This requires no changes in any infrastructure and the point was exactly to make it feasible to write such a filter function for custom error handler. The alternative would require keeping an array of the internal error messages with the version they were added. Which would obviously break apart if we do a simple language or other change to the given notice. So all I am asking is that E_STRICT notices look like the following (or something of that sort): Strict Standards since PHP 5.0.0: Declaration of Europe::get_countries() should be compatible with that of Scandinavia::get_countries() in - on line 14 Instead of: Strict Standards: Declaration of Europe::get_countries() should be compatible with that of Scandinavia::get_countries() in - on line 14 So I dont really see where its killing a fly with a tank either. All that people then need to do is write a simple regexp, that filters out the version number in the E_STRICT notice and pass it off to version_compare(). Very trivial to implement in userland, nothing more than changing a few strings in PHP core. End of story, problem solved. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] E_STRICT
Hi, PEAR is currently in the process of deciding from when on we want to mandate PHP5 as the target platform. Currently it looks like sometime in the next 3-6 months we will likely only accept PHP5 only packages. We are also pondering how to best approach E_STRICT. It is not feasible for us to try to provide multiple packages per major version in order to keep up with new E_STRICT notices that might require features not yet available in previous versions. Obviously one solution would be to disallow making anything an E_STRICT notice that is not available since the first release of the given major version. However I think that would defeat the purpose of E_STRICT. Another solution would be to provide an easy way to filter out E_STRICT messages based on the version they have been introduced. This would enable a package developer to say "I want to be E_STRICT compatible upto PHP 5.1.4". Which would mean that he could filter out any E_STRICT notices that may for example get introduced in PHP 5.2. Usually we slowly increase the lowest supported PHP version of packages in order to keep the code clean and fast, without pushing our users into a corner. So as the lowest supported PHP version increases, the filtering could be adapted. Adding such a filter API into PHP internals however seems like a considerably effort. Therefore my proposal would be to simply add a defined "header" to all E_STRICT messages that contains the PHP version in which this E_STRICT message was added. This way PEAR could provide its developer with a simple filter method that would take an error message inside a customer error handler and determine if it should be filtered out or not. What do you guys think? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: More valuable error message handling
Marcus Boerger wrote: Hello Michael, yep, here too. track_errors is an optimizations when you don't want to debug but simply use your app. thats why i said that i would like to atleast be able to get the last error without having to mess/check track_errors ini setting. i think this is an acceptable compromise to always store the last error, no? this covers 100% of all use cases i ever had where i would mess with the track_errors setting at runtime. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: More valuable error message handling
Michael Wallner wrote: - error_get_last() Get the last error message. my wish would be that this one should work even if track_errors is not enabled. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Array type hinting for internal functions..
Hannes Magnusson wrote: Hi all I am sure this was decided upon long time ago, but there seem to be few out there that do not want this... should I revert array type hinting for internal functions or continue adding them were appropriate while I add the argument info? Just to be clear; I'm introducing array type hinting for all internal functions expecting array and removing therefor useless array type checks inside the functions. These changes however introduce tiny backward compatibility break since it'll emit E_RECOVERABLE rather than E_WARNING... Is this a similar change as the array_merge() change? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: ifeghali
Igor Feghali wrote: I had my proposal about PEAR::MDB2_Schema accepted on SoC 2006. Lukas and Pierre told to request an account here to be able to commit what I already did in pear and peardoc. I also already introduced myself to the pear-dev list: http://www.beeblex.com/lists/index.php/php.pear.dev/42646 Yeah, Igor can get karma for pear/MDB2_Schema As for the changes to peardoc I think its better if you submit a patch via the bug tracking system. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SPL docs
Andi Gutmans wrote: Yeah API docs is useful, but still we should have the end-user docs in the PHP manual. I don't think once comes instead of the other. The end-user docs is especially useful as people in the community can give comments, etc... Err, you misunderstood what I was trying to say. All I was saying that we are generating API docs automatically from the phpdoc comments and providing end user docs separately (which gets translated) written in docbook that can of course link to the API docs. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SPL docs
Andi Gutmans wrote: Hey, I'm obviously not an expert on this stuff so I don't have much added value to add. However, I think from a high-level I think it's important that we have one PHP manual and that the manual covers both functional and oo extensions. I think the last thing we want is to have several PHP manuals. My $.02. Now I'll shut up :) Well PEAR is far from being able to claim that it has solved its documentation problems. However I generally think that its ok to have different tools for API documentation and end user "tutorial" style documentation. However I guess the main stumbling block is that the PEAR API documentation is currently generated directly from the source which does not really lend itself well for translations. It also means that we have documentation for every single version ever released. However at least I have not been good about noting when features have been added. Also doxygen produces much nicer inheritance graphs than what we currently have. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Fwd: fetch() returning false for empty datasets]
Forwarding here. Maybe it got lost inbetween the spam attacks, maybe its just not interesting but lets open up the topic to a larger audience :) Original Message Subject: fetch() returning false for empty datasets Date: Mon, 05 Jun 2006 11:41:12 +0200 From: [EMAIL PROTECTED] (Lukas Smith) To: [EMAIL PROTECTED] Newsgroups: php.pecl.dev Hi, the following script outputs "false" (at least on whatever pdo version is bundled with 5.1.4): $sql = 'SELECT 1 FROM dual WHERE 1=0'; $stmt = $dbh->query($sql); var_dump($stmt->fetch(PDO::FETCH_ASSOC)); all other RDBMS extension we have return null in this case, which seems to be the right thing too .. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: nrf
Nathan Fredrickson wrote: To assist Lukas Smith maintaining the PEAR MDB2 package. In particular, Lukas has asked me to maintain the MDB2_pgsql and MDB2_mssql drivers. Thank you. Yes he needs CVS karma for pear/MDB2 And he also needs developer rights for the MDB2_Driver_pgsql and MDB2_Driver_mssql packages. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recent PostgreSQL serious security hole
Marcus Boerger wrote: As a follow up I've attached my initial patch for this. Can people please review? Without having looked at the implementation: Does this implementation also deal with changes in the client encoding? http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html This might require hooking into pg_client_encoding() .. AFAIK this is what will happen in mysqli .. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ze1 compatibility mode
Zeev Suraski wrote: Marcus, For the sake of world peace, let's say you're absolutely right. Let's be done with this compat mode case study. The important point is for the future - announce compatibility breaking changes (removal of features, major changes to features) clearly on internals@, in a dedicated email inviting discussion. If you get no feedback - be persistent and ask for even those that support it to move forward and say so. Listing it in a shopping list of new features for the next version is important, but only after such a discussion takes place. I think such things should be listed and planned on a web page. Be that the wiki system I put up, or some file on phpweb CVS. It should be a place where developers (and users) can see what is under discussion, what is decided and when to expect the change as well links to related documentation. That way it is easy for people to get up to speed with things and see when what decisions were made. regards, Lukas PS: I think the wiki is really showing how useful it is. I have no problem managing ACL's for the site. However I think it would get used even more actively if the ACL's would be derived from cvs.php.net .. It also does not necessarily need to be a wiki, though I think its convinient for these kinds of documents. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Release Process Sucks
Phil Driscoll wrote: To move this process forward, is there any chance that you could make a few changes to http://oss.backendmedia.com/ReleaseChecklist? I have added a link to your post as a comment in the page. Since I am not an RM I will leave it to Ilia and Derick to incorporate these ideas into the document. Aside from that this document could probably be moved to php-qa website once its mature enough (and therefore less volatile). I feel the todo lists are so dynamic and have a tendency to require some simple markup that its better to leave them in a wiki. Obviously there is still history maintained there. The only drawback is that for people to get access I need to create a new local user instead of being able to reuse the cvs.php.net authentication scheme (which as an outsider I should of course not be allowed to interface with). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Release Process Sucks
Jasper Bryant-Greene wrote: I'm not necessarily suggesting that a release be delayed because *my* application doesn't work, I'm just offering to test RCs against it and report any bugs that it turns up. If the bug is found to be with PHP and is sufficiently serious, then perhaps the release will be delayed. That would be up to the devs. I would also suggest that our application is a good candidate for RC testing as uses most of PHP5's OO features, is E_ALL|E_STRICT clean (so it's easier to spot problems in the error log :), and has virtually 100% test-case coverage (so we can test quickly and efficiently). Maybe some background as to why this primary testers idea was brought up. As Marcus points out we still needs tons more tests. However even then we are probably never able to test every possible permutation of code and data flowing through it so thats where this primary testers thing came up. We actually went out and mailed tons of projects and got feedback from a few. These have already helped in a few cases, but not as often as we would have hoped in spotting show stopper bugs in a release. Here are the current lists: http://oss.backendmedia.com/PhP4yz http://oss.backendmedia.com/PhP5yz http://oss.backendmedia.com/PhP6yz This will now obviously be moved to the moderated read only primary testers mailing list which Wez just setup: [EMAIL PROTECTED] Note: someone still needs to figure out how to set the reply-to so it points to [EMAIL PROTECTED] So the conclusion: 1) Yes, it would be very important that as many of the big time projects try out the RC's and report back both success/failure. In the best case along with an analysis of what PHP feature broke. We do not want to food the RM with application specific bugs. 2) We still need to continuously expand the number of tests we have. You can see the numbers of on the gcov.php.net site. This might be an opportunity for bored students to step up. Along with that it would be nice to increase the number of hardware/OS platforms we test on. This might be an opportunity for some of the bigger corporate users to step up ;) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flamewar Summary
Ilia Alshanetsky wrote:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
I do not like the idea of changing the constants in a minor release. I
know "ALL" implies includes everything but I prefer to keep E_ALL like
it is and add an E_PEDANTIC (and default to that in the sample ini files) ..
So -1
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
We are dynamic everywhere. If you do not agree with this, than PHP is
probably not your language. That being said there are several ways to
work around this with defined static arrays or even $GLOBALS, which is
why I never really ran into this issue myself.
Still +1
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Release Process Sucks
Marcus Boerger wrote: To rephrase Andi "So people screw up. I prefer having the occasional screw up then less people helping out." We are a community [...] What we need is more helping hands and less comlaining notes. Actually we are constantly working on increasing or QA efforts. And from my point Ilia so far has done a very good job. A few minor mistakes so far maybe. That being said .. if there are any additions people have to give better guidelines for RM's please drop a comment at the following address: http://oss.backendmedia.com/ReleaseChecklist regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_ALL changes in 5.2/6.0
Ron Korving wrote: Wouldn't it be nice to start a PEAR2 (or 5) then, with PHP5-ready code, where PHP5 features will actually be used and backwards compatibility for PHP4 is lacking. The current PEAR could gradually be ported into this, and PHP4-users can continue to use PEAR (version 1, if you will). Maybe. But this is a topic for another list .. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_ALL changes in 5.2/6.0
Marcus Boerger wrote: Sorry i have to say that but PEAR is no argument here as still after years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing a PHP 5 version here. PEAR is PHP5 compatible. But you probably meant E_STRICT compatible. Yes, I agree that PEAR needs to become once again a place for features missing in PHP and not a place for legacy code. Anyways I brought up PEAR more as an example of what our current userbase looks like. Mostly doing PHP4 and where its PHP5 its often written to also be compatible with PHP4. By increasing the burden on keeping this "duality" we might get more people to make the jump which might put enough pressure on hosters to finally break the chicken and egg situation with PHP5. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_ALL changes in 5.2/6.0
Derick Rethans wrote: On Sun, 14 May 2006, Marcus Boerger wrote: That said i am about to not remove E_STRICT from E_ALL and MFH the php 6.0 to item just now. See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry)) Since this is for the benefit of the users to prevent issues with changes in behavior from my opinion it is best to do this behavior change as early as possible, which is in my opinion 5.2 anyway. That said i'll let it in and if there is no valid argument against, i will put it into the NEWS file and the newly started README.UPDATE_5_2. Yup, I agree on this. The key point is that with reading the upgrading guide people will know howto get the old behavior. I do not quite agree that this change is necessary, but I guess the "ALL" in "E_ALL" implies it includes everything, so its logical on that level. regards, Lukas PS: Obviously this will be quite painful for PEAR, but I guess that is partially the point here: create some pains to nudge people towards writing PHP5 only code. Or maybe its just about covering our asses against users who complain about us removing deprecated functionality after a few minor releases. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Stop Breaking Our Apps For the Sake of OO
Pierre wrote: On Thu, 11 May 2006 14:15:53 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: Hello! While I welcome new developments in either procedural or OO interfaces in PHP I do not agree with breaking BC (between 5.1 and 5.2 in this case) just for the sake of OO purity. In this example there is the following class: I forgot to mention how vicious such changes can be. Most of times the related tests are "updated" in the same commit (or right after) to follow the new behavior. Making nearly impossible to know about the breakages without duplicating core tests in our apps. Also commit messages or changelog entries are rarely explicit enough to mention them. Yeah, modifications that require changes to existing tests due to BC breakage should get a clear label in the NEWS file that makes it clear that its a BC break. Otherwise things slip through the radar unnoticed or the scope of the change is never put to discussion. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.2 Branched
Ilia Alshanetsky wrote: discontinued. Over the last week a list of planned changes for the 5.2 have been compiled on Lukas' wiki (http://oss.backendmedia.com/PhP52). I have updated the wiki page with Ilia's list. I added a few items that I still marked as todo in my email client into the "open for discussion" list. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Summer of Code
Hi, I would like to add two other project ideas: 1) Expand PEAR::MDB2_Schema to cover all aspects of schema evolution: http://pooteeweet.org/files/phptek06/database_schema_deployment.pdf 2) Create a new set of classes to create/read/modify OpenDocument files I would be interested in mentoring the first. I would rather not mentor the second but I would if necessary. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php 5.2.0
Hi, I updated my phptodo wiki for the next planned release. Ilia also send me a bunch of items that I threw on there: http://oss.backendmedia.com/PhP52 If you want me to be your personal secretary let me know what items you are missing from the list, what items should be assigned to specific people and finally what items are completed. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: SoC Mentor sign up ready
Rasmus Lerdorf wrote: Has someone been keeping a list of the ideas posted so far? If so, please give me a URL for that so I can add it to the profile. Nobody has added things to my wiki, but I can plow through the archive over the course of the day and make a list available on the wiki. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistency of empty() and isset() ?
Derick Rethans wrote: On Sat, 15 Apr 2006 [EMAIL PROTECTED] wrote: The following is a direct excerpt from the PHP manual on empty, and isset: bool *empty* ( mixed var ) bool *isset* ( mixed var [, mixed var [, ...]] ) Is there a reason empty does not allow multiple variables at a time, as isset? Was there thought behind it, or is it just an inconsistency? There is a thought about it, and that is that we could not decide whether it should be an AND or an OR test between the different parameters. well it seems to be AND for isset() .. which is probably its closest "sibiling" .. so the obvious call when going for consistency would be to AND in empty() as well .. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Summer of Code
Gabor Hojtsy wrote: Nuno Lopes wrote: Google is doing their Summer of Code thing again this year. You can read more about it here: http://code.google.com/summerofcode.html This year I might participate. I would like to do something in the core or even in the zend engine. I'll think in something.. (I'm also open to suggestions, of course). I would also like to propose a project related with the documentation team, which is very useful to us: * working on livedocs (rewriting the indexer, improving docbook compat, pear/gtk/smarty docs support, php 6 support, etc..) +1 for someone cleaning up livedocs to a ready-to-deploy state :) And maybe bring in lost children like peardoc back into things. Somewhat related: I am not sure if we really have the OO documentation solved optimally yet either. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Summer of Code
Lukas Smith wrote: A few days ago I started a wiki for PEAR to get organized for this. But BTW .. here is the URL http://oss.backendmedia.com/PEARSummerCode/ The wiki can be used for other php.net projects of course as well. Maybe just open a new page if needed. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] script upgrading program was Re: [PHP-DEV] Re: Summer of Code
Steph Fox wrote: Steph Fox wrote: I wasn't thinking of writing something in PHP... there'd be no way for userland code to 'see' half the stuff that needed changing. I was not implying it would have to. But I also do not see why it should not be possible to do it in PHP. If you wrote something like this in PHP you'd necessarily be searching for patterns in the code. In C you'd be working with tokens directly - coding style wouldn't be an issue. Isnt that what we have ext/tokenizer for? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] script upgrading program was Re: [PHP-DEV] Re: Summer of Code
Steph Fox wrote: I wasn't thinking of writing something in PHP... there'd be no way for userland code to 'see' half the stuff that needed changing. I was not implying it would have to. But I also do not see why it should not be possible to do it in PHP. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Summer of Code
Rasmus Lerdorf wrote: I think we can lump them all together under PHP. And while having suggestions is definitely good, we also need to stay open to interesting proposals. Ok, how do we get on that list? Do we have friends inside google? I poked some more and the stuff I first found seemed to indicate a foundation as a requirement: http://code.google.com/summfaq.html#what_is_a_mentoring_organ But poking some more I found this not to be the case: http://code.google.com/soc/mentorfaq.html#5 I guess we need to cover the following steps: http://code.google.com/soc/mentorfaq.html#3 Quoted here for lazy people: 3. How does the program work? 1. Organizations who would like to participate in Summer of Code 2006 should choose an organization administrator(s) to represent them 2. Organization administrators submit their organization's interest by emailing [EMAIL PROTECTED] 3. Google notifies of acceptance and creates the organization's account on the Summer of Code site 4. Organizations sign up mentors and publish their pool of project ideas 5. Students submit to Google proposals to work with particular mentoring organizations; Google routes to the mentor organization, and the proposals are ranked by mentors working with those organizations. 6. Accepted students start work based on their proposals; mentors give guidance throughout the duration of the program 7. Mentors provide mid-term evaluations of student progress 8. Mentors provide a final review of student work, and each student provides a single overall review of her/his mentor 9. Student uploads completed program to Google site regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] script upgrading program was Re: [PHP-DEV] Re: Summer of Code
Steph Fox wrote: Is it a really stupid idea to suggest a script upgrading program a la 'autoupdate' (for 4/5 -> 6)? It's something I hoped to tackle myself, but am unlikely to find the time for. Well if it works it could solve some issues. Like handling stupid BC breaks (array_merge, class_exists), exploit new features (parsing phpdoc to set PPP) and generally make the code a happy E_STRICT camper. The potential for breakage is huge though (take the PPP example ..) and also for code library it would mean that users will report all sorts of suprising bugs (unless you test the code in all its variations). So maybe as a one time migration tool it could make a nice addition to PHP_Compat (implements new functions/constants etc in userland) and PHP_CompatInfo (determines the minimal php version). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Summer of Code
Rasmus Lerdorf wrote: Google is doing their Summer of Code thing again this year. You can read more about it here: http://code.google.com/summerofcode.html A few days ago I started a wiki for PEAR to get organized for this. But not much content has been generated so far. Only some ideas have been kicked around (latest: adding an optional PHP4<->PHP5 E_STRICT converter to the PEAR installer ;) ). Anyways .. obviously we are missing a foundation, but maybe we can squeeze in somehow. Should we coordinate this, or should each subproject of php.net try to get in on its own? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PCRE error handling patch
Andrei Zmievski wrote: 5.1.4? I have the following items as future todos: 1. new functions: ext/date: date_sun_info (derick) 2. Switch for disabling/enabling materialized cursors in mysqli (georg) 3. fix __toString() (marcus) 4. add support for files >2GB (wez) 5. Add input filter extension via a symlink from pecl into core as experimental (derick) 6. Add json extension via a symlink from pecl into core as experimental 7. add PDO::defaultFetchMode attribute (pierre) 8. PCRE: make it possible to set runtime limits on backtracking and recursion and add preg_last_error() Especially for Nr. 3 I guess we would have to move to 5.2. That is why I would favor 5.2 over 5.1.4 and reserve 5.1.4 to a quick security fix release if one becomes necessary. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: pg_execute error
Yasuo Ohgaki wrote:
Wez Furlong wrote:
Regardless of whether it's a good idea or not, you should not just go
ahead and commit such a big behaviour change to the stable branch
during the release process.
Please revert your commit.
That's good point.
Any people should not depend on pg_execute's E_WARNING error
in transaction, but I'll revert patch against PHP_5_1.
Sorry but your comparison to file_exists() is wrong. pg_execute()
compares to something like include() if at all. Again I do want
something like pg_is_prepared() but I rather wait until pgsql 8.2 where
we get a proper native solution.
For your case you should simply do:
// this will trigger an error if the query plan is already prepared
// but we can ignore the error
@pg_prepare($dbconn, 'myplan', $sql);
for ($i = 0; $i < 1; $i++) {
pg_execute($dbconn, 'myplan', $values);
}
along with the necessary changes to your error handler you are all set.
you only have a single error silenced call.
so this change should be reverted in all branches ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: pg_execute error
Yasuo Ohgaki wrote: > @ operator is ok, but usually @ operator is not recommenned. > Don't you think so? I try not to use @ as much as possible. > > pg_execute() does not have to raise error just like file_exists(). > It may be good idea to raise error when connection is bad, etc. the problem is a limitation in pgsql and hiding this fact imho causes more problems than it solves, especially since pgsql will eventually solve this limitation (i hear 8.2 will solve this). another solution that does of course add a fixed amount of overhead is to simply prepare the statement again before you enter the loop. you will then only have to supress a single call to pg_prepare(). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: pg_execute error
Yasuo Ohgaki wrote:
> Lukas Smith wrote:
>> Just to make it clear: calling pg_execute() on a not yet prepared
>> statement will cause your transaction to be rolled back on the next
>> commit. Encouraging the use of pg_execute() to find out of the statement
>> has been prepared is therefore wrong.
>>
>> Moreover by your logic we would need to remove E_WARNING's from php
>> entirely. Finally you can detect if a function call was called with
>> error suppression in your error handler and that is the appropriate
>> place to address your issue.
>
> This issue is like file_exists() raises E_ERROR, since
> PostgreSQL does not provide means to check if plan is
> already defined. i.e. design error for the function.
>
> Even if PostgreSQL provide view for already defined plans,
> selecting the view to check requires. It requires overheads
> which requires network traffic. Thus adding new feature to
> check if plan is defined is not good idea.
> i.e. DB is usually a bottle neck of web systems.
So why dont you just do @pg_execute() and in your error handler you can do:
function ErrorHandler($errno, $errstr, $errfile, $errline)
{
// ignore silenced function calls
if (!error_reporting()) {
return;
}
..
If you want a "beautiful" solution you will have to manage your prepared
statements in some persistant layer.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: pg_execute error
Yasuo Ohgaki wrote: > Lukas Smith wrote: >> Yasuo Ohgaki wrote: >> >>> 3) add bool parameter to pg_execute() >>>e.g. pg_execute(resource connection, string stmtname, array params, bool >>> ignore_error) >> how would you intent to implement this? >> AFAIK there is currently no catalog to find out the prepared statements >> in the current sessions (I hear 8.2 will change this). So the only way >> to find out is to simply "try it" and cause an error in the session >> which could trigger all sorts of error handlers on the database side .. >> something I would not expect from calling a php function like this. > > I hear about that. > > Current pg_execute raise E_WARNING if plan is not prepared. > The error is annoying since programmers has to try and > see if it works. > > Anyway, since there are no other comments, I'll get rid of > the error from pg_execute. Since this is the most efficient > way. Just to make it clear: calling pg_execute() on a not yet prepared statement will cause your transaction to be rolled back on the next commit. Encouraging the use of pg_execute() to find out of the statement has been prepared is therefore wrong. Moreover by your logic we would need to remove E_WARNING's from php entirely. Finally you can detect if a function call was called with error suppression in your error handler and that is the appropriate place to address your issue. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: pg_execute error
Yasuo Ohgaki wrote: > 3) add bool parameter to pg_execute() >e.g. pg_execute(resource connection, string stmtname, array params, bool > ignore_error) how would you intent to implement this? AFAIK there is currently no catalog to find out the prepared statements in the current sessions (I hear 8.2 will change this). So the only way to find out is to simply "try it" and cause an error in the session which could trigger all sorts of error handlers on the database side .. something I would not expect from calling a php function like this. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phps line numbering
Lukas Smith wrote: Ilia Alshanetsky wrote: I'd consider it for PHP6, but not for PHP5.1 at least not at this time. what exactly is the big deal with adding a new optional parameter? i dont really see the huge impact that should push this feature back to the next major php version. its something that could go into any minor version. maybe i should clarify that i am only concered about the highlight_file(9 and highlight_string() functions. i dont even think we should add linenumbers to .phps. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phps line numbering
Ilia Alshanetsky wrote: I'd consider it for PHP6, but not for PHP5.1 at least not at this time. what exactly is the big deal with adding a new optional parameter? i dont really see the huge impact that should push this feature back to the next major php version. its something that could go into any minor version. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / NEWS
Lukas Smith wrote: Steph Fox wrote: Where would you want to start UPGRADING from? The main problem I faced with the 5.1.0 version was not knowing how far back to go... or what to count 'in'. E.g. something that was only in CVS for a few weeks and no releases - should that be included? Needs some thought for 6.0 I think realistically to keep the work somewhat manageable we should focus on providing disjunct steps. 4.4 -> 5.0 5.0 -> 5.1 .. 5.y -> 6.0 If we find we have more resources to invest into this, we can inline some of the hints from previous guides. However since we now have a starting point I do not think we really need to. Just to clarify. Someone upgrading from 4.4 to 6.0 would then have to work through a ton of guides obviously. I guess there may be something that get reverted in between (like E_STRICT on var), but those should be rare. There could of course be improvements to changes or ease previous BC breaks. So of course there would be a benefit to provide specific guides, but the effort is going to be huge. Maybe we can provide each of the points in the upgrading guide online as well, where people can comment on the relevance of the given point to specific version jumps. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / NEWS
Steph Fox wrote: Where would you want to start UPGRADING from? The main problem I faced with the 5.1.0 version was not knowing how far back to go... or what to count 'in'. E.g. something that was only in CVS for a few weeks and no releases - should that be included? Needs some thought for 6.0 I think realistically to keep the work somewhat manageable we should focus on providing disjunct steps. 4.4 -> 5.0 5.0 -> 5.1 .. 5.y -> 6.0 If we find we have more resources to invest into this, we can inline some of the hints from previous guides. However since we now have a starting point I do not think we really need to. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Multiple MySQL Connections
Nick Mitin wrote: I was trying to create 2 mysql connections. this is a user question and should therefore not be directed at the internals list.. 1) persistent connections have issues: http://de2.php.net/manual/en/features.persistent-connections.php 2) use the new link parameter to get a new connection for a host you previously already connected to: http://de2.php.net/manual/en/function.mysql-connect.php regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO and/or BREAK LABEL (conclusion)
Dmitry Stogov wrote: We already have exceptions, so we don't need another longjump :) "jump" or "goto"? Just make common decision and I will change it. Dmitry, maybe I have overlooked a single post, but I have yet to see a single post favoring "jump" over "goto". The common decision is here and it is "goto". regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php4 style constructor
Hi,
I am wondering why does defining a php5 style and php4 style constructor
in a class result in an E_STRICT warning, where as only defining a php4
style constructor does not?
class foo {
function __construct() {}
function foo() {}
}
class foo2 {
function foo2() {}
}
I could see it make sense the other way around, or issuing an E_STRICT
for both ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion
Steph Fox wrote: Perhaps there could be just the one hard rule. 'If it's possible to implement it as an extension, do so.' There'd be nothing to prevent co-opting essential functionality into the core, but also nothing preventing fly-by-night technologies from having support in PHP. The biggest problem there is that it doesn't give webhost users a fair crack because changing hosts means you risk losing a package or two; and the ability to write portable applications is affected in the same way. But this isn't about the language itself any more... Actually there is a danger in making all too many different syntax enhancing extensions public: Language fragmentation. At some point some of these extensions might become incompatible with eachother. It just seems to me like a syntax adding extension is a different beast to handle than one that adds new syntax from system administrators/shared hosters perspective. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: GOTO and/or BREAK LABEL
Dmitry Stogov wrote: Hi, Because of some confused people I reverted "break label" patch and post it for discussion once again together with GOTO patch. Please reviw and vote. 1) goto and break label +1 2) goto only (like C) +1 3) break label only (like Java) +1 4) nothing -1 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Adieu register_globals
Zeev Suraski wrote: The point is that breakage is aggregated, not binary. The more stuff we break, the more difficult it is to port, and frankly, it's quite likely that a non OO app could migrate fairly cleanly even to PHP 6 with unicode disabled (perhaps with minor fixes). get_magic_quotes_gpc() is designed for apps to do something differently depending on the value of magic_quotes_gpc. It's fine that it's always off in PHP 6, but there's no reason not to keep this function (to always return false) so that you don't have to fix God knows how many lines of code to remove it. yes .. php script thats worked with gpc off (and that had some code to detect if its on and act accordingly) should still work without change. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach, assigning to a reference, and E_NOTICE
Sean Coates wrote:
it's not the problem of the second foreach, any usage of $j after the
1st foreach as &$j will hurt
Yes. I thought it was clear that I understand this. I guess not.
My point is that foreach is doing something that isn't immediately
obvious. The same is true of your for loop, but to a lesser extent, IMO
(as I don't expect your for loop to ONLY read from $i).
I don't want to start a discussion on references. I'm just trying to
clear up a non-obvious case.
How would you supress the notice (I know error suppression is ugly), but
we need to make it possible for people to quickly adapt to this change
if they indeed relied on this.
would this work:
foreach ($i as @&$j) {}
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.1.3 Release Plan
Ilia Alshanetsky wrote: It has been a while since our last release and we have a fair number of bug fixes and minor improvements accumulated, so it's time for 5.1.3. My goal is to have the release out by March 30th, with 2 RCs between now and then to let us test everything out. I have updated the 5.1.x release management page on my wiki accordingly. If anyone has any features he is planning to "squeeze" into this release please let me know so I can add it there to assist Ilia in the release management: http://oss.backendmedia.com/PhP51 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
Derick Rethans wrote: On Thu, 2 Mar 2006, Jeff Moore wrote: Unfortunately, the problem with making self late binding is that that there are potential BC breaks. Is that possibility on the table? I don't think we should break any BC over this. Neither do I. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
Marcus Boerger wrote: Hello Lukas, no the way things are now are just as expected. my point was this: why even bother with self:: ? you could just as well use the class name. its just syntactical sugar .. however late static binding actually gives you a useful feature (well one could argue that self:: atleast gives you the option of getting the same feature through cut and paste). and of course i was not argueing in favor of a BC break .. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
Dmitry Stogov wrote: Patched PHP will modify zend_function->caller_scope at runtime. This can break ZTS version and probaby opcode caches. Storing runtime information in zend_function is bad decision. maybe stating the obvious here .. but opcode caches are important to everybody on this list i am sure .. so i think you do not have to worry that a majority would favor a solution that puts them in a bind. here is hoping that we can find an opcode cache compatible solution to get this useful feature in. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
Zeev Suraski wrote: 1. I don't think it's a very important feature, even though like any other feature we could possibly think of, we can come with use cases where it would be useful. In terms of complexity vs. usefulness, I think it's more complex than useful. So how about this ... make late static binding the default. The point is: late static binding is the "intuitive" thing to happen when inheriting static methods. So the way things are right now are more complex due to a performance optimization. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
Jochem Maas wrote: rather than an alternative form of static method calling or a new class related keyword, maybe a new magic constant would be sufficient? e.g. __CCLASS__ (C for 'Called') or __OWNER__ (the class the 'owns' the method? [from the view point of the caller]) i dont really think a constant is the way to approach this .. considering your caller will not be constant at all .. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
Zeev Suraski wrote: I actually don't recall there was consensus on even adding this feature in the Paris meeting, let alone how to name it. To quote the meeting results as linked in Mike's original post: 1. We re-use the "static::" keyword to do runtime evaluation of statics. 2. Marcus prepares an implementation suggestion. Atleast back then nobody who attended the meeting seemed to complain about this seemingly definitive decision noted in Dericks summary. Also note the notes on the discussion itself: "Discussion: Currently there is no way do "runtime evaluating" of static members so that we can call B::static2() from A::staticA() and this is a useful feature. In order to implement this we need a new keyword to allow for this. As we do not want to introduce yet another reserved word the re-use of "static" was suggested for this." Again it does not seem like there was any complaints about the usefulness of the feature, yet both you and Dimitry attended the meeting. So have you guys changed your mind on the need for this? Was the summary incorrect? It seems to me you are torpedoing a feature you agreed on as useful because if technical concerns about one possible implementation. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
Dmitry Stogov wrote: Yes I like not a sintetic test but real life example (singleton, factory or something else). (I tried to write generic singleton but it wasn't exelent.) Yeah a singleton method that calls a factory method is a prime example. Now if you want to inherit that class you will have to copy and paste these methods. Essentially whenever static methods meet inheritance you are quickly likely to need late static binding. Sometimes you can hack around the issue using reflection or requiring the user to pass the in the class name he wants (like in a generic factory). But I do not think you can even solve everything with the reflection API and its certainly not as code efficient. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Late Static Binding
Dmitry Stogov wrote: 1) I would very like to see some real example where "static" is necessary? I think Mike illustrated this in his post. Or do you want a "real" world example? 2) "static" is really bad name. I suggest "caller", Marcus thought about "class". I dont really see an issue with calling the thing "static" considering its about late static binding. Also AFAIK this name was agreed upong in Paris. A meeting you also attended. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Late Static Binding
Mike Lively wrote: As far as current userland code impact, there is very little as far as I can tell. No keywords have been added, just another use for an existing one. No changes were made to self:: or parent:: so the change should be pretty transparent. The only thing that I see remotely causing any issues would be the new function (get_caller_class().) I added that just to complete the set so to speak. I will try to find time to test this patch. But it will be another few days before I have time to revive my linux vmware instance. However I just wanted to mention that I would really love to see this feature in php 6 or even php 5.2.x regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] True labelled breaks
Hartmut Holzgraefe wrote: Wez Furlong wrote: I think not many people use it because it's difficult to use. Having real labels might change that. Personally, I'd prefer real goto, as I've stated in the past. Just for the record again, I'm +1 for goto, and +0.5 for labelled breaks only if we've totally given up on goto. FULLACK +1 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Static vs. non static
Andi Gutmans wrote: Yes, this was by design. Via class it should be ::method() and via object it should be ->method(). Why do you think this is wrong? I think it actually makes a lot of sense and don't see what we gain from allowing to call self->method(). If there's a good reason, I'd be open to it though. I just gave a course in PHP5 OOP and this syntax overlap with static calls that do not end up being static seems confusing. If I get Marcus proposal properly he would then allow changing things from: parent::method(); to parent->method(); This would add a totally separate syntax, which would make it clear to users that this is in fact not a static call. It looks ugly, but I understand what he is aiming at. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JSON inclusion in core
Andi Gutmans wrote: At 04:25 AM 1/21/2006, Jared Williams wrote: What are the security implications of doing this? Creating objects based on a string from a untrusted source seems not good idea, unless can prevent tampering (with an HMAC or something). Well I think the right thing to do is pass an array of "allowed" classes into json_decode() and raise an error/exception if it's not in the list. Maybe we should try to come up with a common approach here for unserialize() as well? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Ilia Alshanetsky wrote: Each programming & scripting language has its strengths and areas of focus. Just because another language implements a feature, does not mean the rest should follow suit. What you fail to realize that every feature adds to the language complexity, making it more difficult to use, harder to debug and ultimately makes it slower. PHP's biggest strength since day one was simplicity, to sacrifice that, to allow someone to use something that has been hammered into their head in their CS class is beyond silly. I agree that argueing that other languages have feature xyz and therefore PHP should also have it is pointless. PHP works quite well already and its competitive advantage is among other simplicity. So things need to be weight well. I feel that named parameters would actually finally be a new feature that actually makes things simpler compared to the many features recently added. But then again it seems that the bulk of people who have the power to actively stear PHP disagree. So I see little reason to continue this discussion. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Hartmut Holzgraefe wrote: Lukas Smith wrote: Its sole purpose is to deal with situations where you have a considerable number of parameters. well, i for one would love to write something like $pos = strpos(haystack=$str, needle="foobar"); instead of looking up parameter orders all the time :) I would specifically not go there. This would create the inconsistant situation you describe. It would be fixing one past mistake with a new evil. As noted the cases are not as wide as most people make it sound, also its not really related to this discussion. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Hartmut Holzgraefe wrote: Lukas Smith wrote: - all internal and PECL functions need to be recoded as the API right now doesn't know any concept of parameter names at all I was thinking that this would a userland only feature. do we really want to add even more inconsistencies to the language? Its a choice you make when you define your signature and you always need to check the signature before you call a function using named parameters to know the names of the parameters. Adding this to functions that do not fall into the category of having 5+ parameters, especially internal ones, would indeed be a horror scenario. I would therefore even suggest to make it a binary choice. As in the function does either named parameters or by order. Its sole purpose is to deal with situations where you have a considerable number of parameters. I am not aware of internal functions that fit this criteria. I am not sure if we need to forbid internal functions to use named parameters (as long as its a binary choice). But if we keep it binary I do not see it adding confusion. Its certainly less confusing than having to use some array format that is hard to document properly. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
