[PHP-DEV] who is running snaps?
Hi! Does anybody know who is responsible the snaps.php.net machine? It seems to be serving 5.4 builds under then name of php-trunk and that confuses people. Not only we don't have trunk as such since the move to git, people expect the latest dev build there which is master and not 5.4. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars
Hi! Perhaps get_class_fqn(string:ClassName) ? Do you propose a function? Because I don't see how it can work as function - namespace resolution is compile-time. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars
Hi! I would expect $variable::class to work (like late static bindings). What this would mean? ClassName::class has a clear meaning - ClassName is a name of the class (possibly aliased) and class is the property of this class, namely its full name. However I do not see how $variable::class can do anything meaningful. Since namespace resolution is static compile-time, $variable can not be anything but the full name of the class, so what $variable::class supposed to do? Just be equal to $variable? What's the point of such operation, what may be achieved by it? Reference to late static binding is even more confusing - if you mean that $variable is object, then the binding is not static - since you have an object - and you have perfectly good get_class($variable) to do that. Is that what you were meaning? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] ::class feature to resolve namespaced class names to scalars
Hi! * Here are the edge cases / implementation details that need a decision: - $variable::class (should it even be supported?) I don't see it doing anything useful. - self, static, parent::class not in a class definition - self, static, parent::class in a method signature - self, static, parent::class in a method body In constant context, self:: may work, but static:: can't work for obvious reasons. parent:: can be made work too I think - though the class may not be known at the run time, its name should be. As for runtime context, static:: can be made work too but I wonder why bother if we have perfectly good get_called_class()... -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] ::class feature to resolve namespaced class names to scalars
Hi! In the current patch, this does not work and would need another run in the parser. Couldn't we just stuff it in ZEND_FETCH_CONSTANT? I'm not arguing for it, I'm just saying *if* we wanted it... -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add simplified password hashing API
Hi! The salt parameter, if provided, will be used in place of an auto-generated salt. This is setting someone up for failure by letting them put in something weak, you should be forced to get an auto-generated salt. If this is for unit testing then it should be explicitly stated. This assumes that we have the best salt generation algorithm that ever existed or could exist, and never would have any bugs or vulnerabilities in it. If it's not the case, it makes sense to let people provide their own salts in case they can generate better ones. E_WARNING in a crypto function is also bad. Throw an exception or fatal. There's no reason to just raise a warning and continue execution, if something went wrong in crypto then its a bad time for everyone. This means the function will be behaving differently than other PHP functions. Because it's crypto and very important, I understand. But then comes somebody else and says my file functions are super-important too, whole application depends on them, why can't I have them work the same as crypto ones?, etc. Core should be consistent in its responses. Also, since the function returns false on failure, you can easily know something went wrong and throw exception/produce fatal error there if you wanted. Just like other functions - e.g. fopen() - do. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add simplified password hashing API
Hi! The benefit is that it can be tested properly and bugs discovered and ironed out first. This is not the sort of thing you want to get security bug reports the day after its released in core. If your ego is big enough you can guarantee you have tested this thoroughly and want it to become the recommended way.. You have to be damn sure you don't fuck it up. This is exactly the sort of thing that doesn't need to be developed in the core tree, but can later be merged in once proven successful. I see you point, and indeed, if we recommend something as a one-stop shop for security-sensitive area, we better be sure we do it right. But: are we really going to get enough testing if we put it out as PECL module? Also, we're not releasing 5.5 tomorrow, so we can have a lot of testing before. But if it's a non-core module, adoption would be much lower since apps could not rely on it being there even in 5.5. OTOH, PECL module that can be built in 5.3/5.4 too might be nice. Not everybody is going to upgrade to 5.5 soon, so having them participate would be good too. Maybe we could do it as a module and have it workable as PECL too for those who are not on 5.5? PHP solution is not really the same - if we have two separate codebases, nobody can be sure they actually do the same thing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is our definition of a Backward Compatibility Break
Hi! That's more about internals APIs, which is not what is meant in the release RFCs for x.y+1 releases. The idea though wasn't about internals APIs. The idea was that for users it's better to have platform that they can expect to work with their code 10 years after than to have a platform that you have to rewrite your code each couple of years. PHP wasn't excellent about it in the past, though there were very good reasons for that. But we need to start thinking about how we can get it much better in the future. Including thinking along the ways that each feature we add today will be set in stone for next 10 years - so we better think 10 years or more ahead when we do them. I know it's not easy and sometimes may be just impossible to know that far in advance, but we should try to do our best. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is our definition of a Backward Compatibility Break
Hi! Based on our recent discussion on #pecl , I'd like we clarify what we think is a BCB (Backward Compatibility Break) as well as what only minor BC breaks could mean. Stas' recent topic on internals On BC and interfaces may serve as a reflection basis. As our release process told us that we should not add BCB (but only minor ones ... hum) in any minor release (nor revision), and as 5.5 release process is going to start soon, I'd like we try to all agree on that point. I think first we have to distinguish several levels of BC: 1. Binary BC 2. Source-level extension BC 3. PHP Code (API) BC Binary BC means that extension compiled with one version would work with another without recompilation. We keep this level of compatibility through all minor (5.x) releases and breaking it is an absolute no-no. However, between minors (5.5 - 5.5) breaking it is fine. Source-level extension BC means that an extension may be successfully compiled and working in two versions. We strive to keep it between minors, though if absolutely necessary for implementing new stuff we may occasionally break it. But this has to be kept to absolute minimum and only done if there's absolutely no way to avoid it - e.g., if we refactoring the engine to use more efficient way to generate opcodes and we need to change zend_op_array structure, some extensions that use it may be broken. PHP Code BC means that a PHP script that works in one version also works in another version. We should keep this level of BC across all major version, and breaking it between minor versions is not acceptable. Only exceptions may be: introduction of new keywords (may break code that uses the same identifier), security fixes (if we have to introduce more secure way of doing something, application using insecure practices may be broken), bug fixes (if application relied on a buggy behavior of PHP to work, it may be broken), removal of already deprecated features. Adding new functions usually not considered BC break, though technically it may break code that used the same function name. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is our definition of a Backward Compatibility Break
Hi! Change in phpinfo related stuff are minor. Adding a notice or warning is minor or irrelevant. Changing return values (like suddenly I'm not sure I agree about warning/notice. Depends if it's a clear bug - either in our code (like, opening non-existing file produces warning but opening it with another function does not) or in user code (like giving wrong parameters to a function or calling it in a clearly wrong context). If it's not than it actually may disturb working code so we have to be careful. E.g., PHPUnit unit tests will drop out on any unexpected warning. Some applications would do the same due to their error handler structure. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is our definition of a Backward Compatibility Break
Hi! This is concerning me a bit. Does this mean that PHP 5.5 will be branched off PHP 5.4 and we will then backport features from master? If so, this would seem like a Very Bad Idea to me, from a purely technical point of view. Unless I'm much mistaken this would have to I think also it's not a good idea, not sure what Pierre meant by that though. So far I don't think we have anything BC-breaking in master, but if we do we may have to split it in bc and non-bc branches. Before Pierre said that I was under the impression that PHP 5.5 will be branched off master, which would make a lot more sense to me. Could someone clarify how it will be done? I was assuming this too. I guess we need some clarification on what Pierre was meaning. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is our definition of a Backward Compatibility Break
Hi! We do not have this clue in master and there are for sure non acceptable BC breaks in master. They won't be in 5.5. I'd said before, Why don't we have a clue? We definitely do have a clue, we have git logs and we know what went into master - it is not that old. Could you list the non-acceptable BC breaks that are now in 5.5? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why are the PHP namespaces different compared to C++?
Hi! Back on the namespace topic. I won't judge on anything, but i know namespaces from c++. I understand that PHP isn't a compiled language and quite frankly that doesn't matter at all. What does matter is that PHP uses the name: namespace which C++ obviously had earlier. Here is something that I would like to emphasize. There's no one right way to do namespacing. And while PHP borrows a lot from other languages, it was never promised or guaranteed that PHP would work exactly like C++ or Java or Python or Ruby or any other language. If it makes sense for PHP, it is taken in. If it's not, it is not taken. In the case of namespaces, we needed to solve a particular problem of PHP - global namespace pollution and people inventing super-long really tedious names to deal with it. Moreover, it is in general *exactly* what namespaces are solving in each language. Namespaces were designed and implemented to solve this particular problems, while keeping all other parts of PHP working properly. Naturally someone that knows both languaes (c++ and php) simply assume that a namespace in php probably works the same as those in C++. If that's not the case then it shouldn't even carry the namespace name. I couldn't disagree more. Namespace is a generic term, not belonging to C++. PHP is not some offshoot of C++ that is required either behave like C++ or stay away from it. Again, if it made sense in PHP to implement *generic* concept of namespaces in a *particular way* that C++ does it - we might do it. But it didn't, so we didn't. We have no responsibility and no obligation to make implementations of generic concepts match those in other languages or invent awkward names for those if they do not. There's a value in behaving like other languages, but it only goes so far. Namespaces in PHP are as valid implementation of namespacing as those in C++, they are just different. You came to it with prejudices about how they should be working, these prejudices proved to be wrong, now you know more and you continue to be more productive. This is natural and happens to many people (myself included) quite often - one assumes something, one is sometimes right and sometimes wrong. If one is wrong, one corrects the mistake and becomes wiser. However I can't understand how it makes sense to blame the language for not matching somebody's personal background and prejudices. To me this namespace in php stuff just looks like and alias. So why isn't it named as that: alias? I do not want to question the ones that implemented namespaces in php, but i do think that the name itself is at the very least confusing. It's not an alias. Aliasing is a part of it, but not the whole. Declaration and the beginning of the file saying alias My\Database makes little sense, declaration namespace My\Database makes great sense - it shows that the file belongs to namespace My\Database, with all consequences of that. Also, lets keep this discussion polite people. I'm not here to smash toes. All i would like to know is the reasoning behind the above and I think I have explained the reasoning - specifically, why we have no global imports - in my previous emails, but if you still have something unclear, you are welcome to ask. It would make me happier though if you tried to read through the archives where namespaces were discussed and see all those arguments so we won't have to repeat them again, even though I understand that nobody really does that :) if there is any intention of changing the namespaces to be more c++ like. I would evaluate the chances of it as very small and I would be in a very vocal and active opposition to that. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
Hi! The lexing and parsing processes will not be slower than actual, and the construction of an AST is a new process. Well, as usual, new process requires new resources. But if we look further, it will certainly be a nice tool to perform better opcode caching, it will remove a lot of hacks, it will allow third-part tools working on safeness, security, quality etc. to go deeper at low-costs which is very important for PHP community, it will facilitate future works I don't see how it would lead to better opcode caching. As for third-party tools, I do not see why third-party tools need PHP to change the parser. If PHP's parser is not good enough for those tools, they can have their own parser. Maybe the upfront cost of a parse goes up, but once it is parsed and the opcodes are cached, you won't have this cost again until you change the script. Then you have all of the benefits for every subsequent request. So far we have not seen not only any of these benefits, but any explanation of what exactly these benefits would be and any proof they would actually benefit anybody. I seriously would propose people interested in this project just take up this project and see if it's beneficial or not. Just talking about what might happen on the list would achieve nothing. Increased cost once, benefits every time. For now it looks like quite the reverse - increased performance and stability costs for everybody, dubious benefits for a small group. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
Hi! Nikita is doing an amazing job with PHP_Parser, which is such a third-party tool. However, it will always lag behind the canonical parser. And it will (probably) never match 100% the behavior of the canonical parser. Wait, so the arguments that it will be amazingly easy to implement new features in this parser - which should solve the problem of the lag - by the time the old and clunky parser is released certainly it is possible to do the same with new, much less complex and much easier to work with parser? - so these arguments weren't true? Or am I missing some important reason why parser that is much less complex and easier to add things to can't do the same old one can do? And if it's impossible to match behavior of the existing parser - do I get it right that the proposed idea is to actually break real code that people run now in PHP because it was too hard to parse for people that write add-on tools to PHP? Somehow it does not sound like a good idea. If we have doubt that we can match the existing PHP behavior then the idea of changing parser becomes even less appealing, because for 99% of PHP users it would be pure downside without upsides. The users don't care if the parser is complex, they care if their code runs. This is why, from my perspective of someone who is interested in static analysis and quality assurance, I think that it would be a tremendous boost for the PHP platform if we had a state-of-the-art parser for the reference implementation of our programming language. I think that the benefit of it for regular PHP user is unclear (and would not be clear until the real benefit of such parser - such as promised optimizations, etc. - is demonstrated) but the harm from breaking of the existing code is obvious. What would happen is that people would just avoid running such PHP version - and what use then would be to have excellent tools for PHP that people don't use because it can't run their code? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Moving to an AST-based parsing/compilation process
Hi! Well, apart from perhaps leaving them with a simpler language that doesn't have the inconsistencies and corner cases that currently exist (and documented ad nauseum) not because of any design decision but because the parser is written that way. If you think writing new parser gets rid of all corner cases you are in for a big surprise. AST is not magic and parser will always be written exactly the way it is written - so if somebody won't implement certain feature in a consistent way, it won't be implemented in consistent way, AST or not. And it's a bit late to take design decisions on existing PHP language, it seems to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why are the PHP namespaces different compared to C++?
Hi! Yes, PHP namespaces are completely different from what you'd be used to in C++. In all honesty namespaces were never well designed in PHP and were implemented in a haphazard way, which is why I generally don't bother using them. I just love how people assume if something does not fit their specific use case people implementing it must be stupid and didn't bother to actually think about it. If only they gave it some though, they would definitely would do it exactly as you want. To clarify, importing namespaces in PHP isn't like importing namespaces in C++ at all, really. You are merely aliasing namespaces There's no importing namespaces in PHP, period. It is not messy, it is by design, and if you bothered to read extensive discussions that happened on the list at the time, you'd know why. But of course who needs that. It simply doesn't work like that because PHP's namespaces are implemented in such a way that they don't really resemble namespaces. They do not resemble namespaces in C++. They resemble namespaces in PHP. That's because PHP is not C++. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why are the PHP namespaces different compared to C++?
Hi! How about adding ability to import the entire namespace? This option was explicitly excluded because this defeats the whole idea of having namespaces - i.e. having names to live in different spaces - by explicitly bringing unknown set of names into global space. If you allow global import, then you do not know which any of the names comes from - it can come from any of the set of imported namespaces, or be just global - and you have absolutely no idea about it and no way to avoid conflicts. And all that to save you three keystrokes so you could write DbConnection and not Db\DbConnection? Definitely not a good idea. Current implementation makes it clear where things come from and avoids naming conflicts, while still allowing you to use short names instead of long and painful ones. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why are the PHP namespaces different compared to C++?
Hi! In C++ when you type: using std; Then you can use all methods/classes/whatever is defined in std without typing std. so: std::cout becomes just cout. PHP namespaces do not work like that. In PHP, namespace is a permanent part of the class/function name. All namespace translations are done in compile-time (which is not the same as compile-time in C++, btw) and are simple alias translations. PHP explicitly avoids mass imports, because this would lead to context pollution and interoperability problems - i.e., if you have some function named foo in two namespaces and you import both, you may have problems. And since imported namespaces usually mean somebody else's code, you may not have control or good information about changes, making importing code fragile. Since unlike C++ PHP does not have compiler that can resolve all the mess before it is run, PHP has to be more conservative in order to avoid problems. For this reason, PHP's use is nothing more than aliasing operator. It does not put any other names into global space but the names specifically mentioned by it. So, if you have to do std::cout, it'd still be std\cout, but if you want to do some\long\import\namespace\cout, you can alias some\long\import\namespace to mystd, and do mystd\cout. So you never have to do more than one \, but you still have to do one, to avoid polluting global space. But i'm wondering why the use Some\Long\Namespace doesn't work like the C++ one. Since i would have guessed that adding that use will give me access to all the methods/classes/whatever that live within that namespace _without_ having to prefix it with the last part of the namespace. This is exactly what we were trying to avoid - for the reasons described above. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why are the PHP namespaces different compared to C++?
Hi! That's true, but we do got the ability to import only one class from given namespace and classes aliasing so we can, for example, do something like: When you import one name, you see this name in import statement. It's explicit. Global imports are not. I really hate to rehash discussion from years ago all from the start. Please believe we did think about it - including having special options, functions, configurations, INI entries, etc. for defining imports. It's not worth it to save couple of keystrokes on namespace prefix, really. Not everything should live in global space, that's the whole point of namespaces. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why are the PHP namespaces different compared to C++?
Hi! I wasn't assuming. I was outright making a factual statement. I never made any implications of the intellectual levels of those implementing the spec. I understand the RFC full well and know why the design is the way it is. I was answering the ops question. Please read what I said before you make your own assumptions. Sorry, statements like haphazard way, never well designed, it's a mess, they don't really resemble namespaces, just some fancy magic, etc. have nothing to do with facts. Actually, facts are exactly the opposite - they were designed, were extensively discussed with soliciting feedback from many stakeholders, and were implemented exactly as planned. You may not like the way there were implemented, that's your opinion (not a fact) and you are entitled to it. But you didn't limit yourself to saying I don't like them. You specifically said that they were never well designed and haphazardly implemented. This is factually false. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $obj-attr::method() is not allowed
Hi! The complexity of the current grammar is working against development. I'm not sure that undertaking a task of rewriting whole grammar, with all disruptions etc. that this is going to cause, will speed up development a lot. But if you want to try it and show how easy it would be with your grammar - you are of course welcome. I agree that yacc parsers in general can be frustrating and complex, but I'm not convinced rewriting it really worth it and would result in something much simpler. How many of those things really are distinct, and how many are an artefact of the implementation? To pick just one a recent example: why is the $x in foreach($array as $x) such a different beast from the $x in $x = $array[0] that the latter could be replaced by list($a, $b) but the former couldn't? Probably because parser wasn't written this way - list() is a special case in assignment (due to special handling required to implement it) but this special case was not part of foreach() parsing. $x is actually exactly the same thing in both cases - 'variable' - but list() is not 'variable' and as such needed special case. Ah, so r_variable means non-writable expression. Makes perfect sense. Incidentally, r_variable expands to variable, then to base_variable_with_function_calls, and _then_ to function_call. I think more precisely it is expression in read context. Then again, $a-b-c is _also_ an r_variable, so does that mean I can't write $a-b-c = 1;? For me, it does not produce r_variable, instead I get compound_variable, and stack like this: $1 = nterm base_variable_with_function_calls () $2 = token - (T_OBJECT_OPERATOR) () $3 = nterm @65 () $4 = nterm object_property () $5 = nterm @66 () $6 = nterm method_or_not () $7 = nterm variable_properties () - $$ = nterm variable () But maybe I'm doing something different that you. Anyway, I think the discussion is getting a bit pointless here - I'm sure that in 10+ years of development there are places in the engine code where you could point and say see? it is called variable but it does different thing!. Yes, I'm sure that happens. But I'm not sure I understand the point of picking out these things. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Moving to an AST-based parsing/compilation process
Hi! To date, I've been basing work, which exposes syntactic structure, on phc's maketea grammar (Phalanger's is more up to date, but also more complicated what with its provenance and the Linq and generics and all), but it's reverse-engineered and certainly wrong (oh, that reminds me...); the existing grammar is unsuitable because no-one wants to see _that_. Well, now if you start to implement yet another AST grammar, it would be wrong too, at least for substantial time until the kinks are worked out - just because it's different approach which probably would work differently in some corner cases. So what we're getting on the plus side is more academically nice parser with potential optimizations, of which nobody knows if they'd have any real effect and all indications point to the possibility they won't, and we have some benefits for third parties doing some (unknown to us) work on PHP. On the minus side we have major disruption of the code base, virtually certain BC problems and stability problems, slower compiler and no real benefit for average PHP user. I'm not sure this equation has the positives outweigh the negatives. It'd be nice to support third-part work but I'd propose to start with writing the actual parser (e.g. as an extension or third-party library) and see if we can make it as fast and 100% compliant and if it turns out good then we could talk about replacing current parser with it. In the meantime you could also use it as base for your work too. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $obj-attr::method() is not allowed
Hi! The problem is that the only formal definition of the language _is_ the parser - there's no grammar outside zend_language_scanner.l/zend_langauge_parser.y. I'm not sure - why exactly is it a problem here? I can understand how having such document might be useful and interesting (not useful and interesting enough that for the last 10 years anybody bothered to do it but still, I can imagine) - but how existence of such document would solve your problem? The developers of phc (http://www.phpcompiler.org/) ended up having to write their own AST-based grammar (which may possibly serve as a starting point for a grammar rewrite) because PHP's own parsing of even simple expressions is so long-winded and unintuitive. That site gives a couple of examples: (for 'printf(Hi!);' (27 nodes, including r_variable) and '$a-b-c' (26 nodes, including base_variable_with_function_calls)). I don't see any relationship between the fact that implementation of separate compiler required separate parser (which is only logical since existing parser is built to suit the needs of existing compiler and not whatever needs phc authors had) and the parser being unintuitive. I also do not see how the number of states the parser passes is a measure of anything and why 27 should looks like a horrible number. There are a lot of things that can happen in expression, in function call and in function argument, the parser must understand it all. As for r_variable, it's just an expression that is not writable (i.e., no printf(Hi)=1) - what's so strange about it? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] On BC and interfaces
Hi! Given many discussions on the list about changing stuff in PHP, I'd like to bring everybody's attention to comment by Linus Torvalds in this topic: https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk It talks about Linux kernel and discussion has next to nothing to do with PHP, but generic point about keeping the interfaces and importance of not serving one use case I think very important for all widely used platforms equally. I think the opinion of the author of one of the most successful platforms in recent history may be interesting to consider. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Hi! I keep being told that there is nothing wrong with E_STRICT, and again someone has said that it does NOT cause crashes. I beg to differ here - IT DOES! If you have a scenario where E_STRICT causes PHP to crash - please submit a bug to bugs.php.net. If this is your application that is malfunctioning and not PHP then you should fix your application. If you have problems with that you can seek help on php-general or any other forums out there. In any case, I don't see how screaming about it here is going to lead to anything useful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
Hi! The terminology negative indexing seems to imply that the feature should work with arrays. To restrict it to just strings might involve creating a term one would only associate with strings. I do not see any way to change behavior of $array[-1] that would make sense. So either only strings get it or nobody gets it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
Hi! They are seen and promoted as core features. Whether we like that idea or not is not really relevant. We messed that up by making most of the Standard PHP Library an extension for only political and licensing reasons. I think you using core here in two difference meanings, and the question of political and licensing reasons is completely irrelevant to current discussion. The question is that we have language core (keywords, syntax constructs, etc.) and we have various APIs. Unfortunately, due to disagreement among PHP developers, there's no consistent policy among APIs on the question of how to handle errors. However, there is a consistent policy about how to do it when we're talking about core PHP constructs - keywords, language syntax, etc. - that we do not use exceptions there. We can't really change existing code without breaking everything out there. So we somehow have to do it on a case by case basis or for new stuff only. We have to have clear policy that can be understood by users. Doing it on a whim of a person that submits particular patch was what we were doing before, and it didn't work very well for us. The consensus by this point was that PHP keywords, language constructs, etc. do not throw exceptions (the unfortunate patch of 2005 aside). If you want to change this - fine, please propose a consistent policy that changes it, let's agree on it and adopt it. But doing it in random places just because it seemed convenient at this moment IMO is not a good idea. It is IMO exactly what we are trying to fix. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
Hi! I've replied here: http://www.mail-archive.com/internals@lists.php.net/msg60706.html I have a feeling you're concocting a very far-reaching scenarios and making a lot of unbased assumptions there to arrive to pre-defined conclusions. Any programming error can cost a business money, and any problem can be fitted with scenario when it leads to blowing up whole world in the flames of global catastrophe, given enough imagination and wild enough assumptions. However, I do not see any technical reason - not involving far-reaching assumptions following from nowhere - that require repeated generation produce a fatal error. So far all the explanations seem to be to the tune of because it's so bad! but I don't see how it's worse than any other fault - such as failing to open the file, database returning no results because of wrong query, etc. We do not produce fatal errors on all of these cases - in fact, we produce fatal errors only when we know there's no reasonable way to go on. I still do not see why just returning empty iterator with suitable warning does not fit the pattern of all exceptional situations we have in PHP that are handled in a similar way. For foreach() specifically, for example, you can put there invalid - non-iterable - value, and it won't be a fatal error. Why non-iterable value from generator should be a fatal error? I think it makes sense to treat it exactly like foreach() treats non-iterable values. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
Hi! indicating such mental model is widespread and (2) given that the exceptions you claim to be surprising don't happen but for a programming error (i.e. they're not exceptions that need to be caught). Following this logic, we'd have to convert all E_NOTICE and E_STRICT to fatal errors or exceptions - they are usually produced by programming errors and aren't meant to be caught by surrounding code (actually, can't). But I don't see anybody benefiting from this - as I don't see anybody benefiting from generator that will explode your application if you touch it twice. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Release scheduling, branching NEWS for 5.4
Hi! And no BC in 5.5 as well. Which will cause us some issue for 5.5 as master actually has BC breaks as far as I remember. We accept binary API changes in 5.5, but only very slight PHP-level API changes (such as removal of functions like logo GUIDs). Another important point - any such change that may influence PHP developers should be in UPGRADING file. Including adding functions, arguments, options, etc. - this will help to keep it properly documented too. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
Hi! First, E_NOTICE exists to permit a compromise between people like Zeev that think its introduction was an error and that one should be able to refer to undefined variables and people who prefer a stricter model. For the programmers that follow this stricter model, an E_NOTICE ends ups frequently being a fatal (because, for instance, you invoke a method on the resulting null); some other times you're lucky and you just missed an else $var = null branch, other times the error is far more serious, like an unintended null - 0 conversion. So it basically comes to it doesn't follow but E_NOTICE in fact should be fatal for those who prefer a stricter model because I had some code where it indicated a bug. That's exactly what I was talking about. But PHP is not designed to be this way and PHP code is not written this way, for better or for worse. If you want to start a radical transformation of PHP into something like Python where accessing a value in array that doesn't exist (and pretty much any other unexpected thing) throws an exception that finishes your application (or at least a segment of it inside a catch-all-then-bail-out exception wrapper) - it should not be done in a hush-hush case-by-case basis. It should be announced upfront and consensus should be obtained. I personally do not see such transformation as beneficial, and I suspect many others do not either. But in any case this would not work on case-by-case basis. If however we want to keep the current nature of PHP, introducing fatal errors where it can be avoided only because it _may be_ a bug makes little sense - we have tons of situations where it may be a bug - just as you described with E_NOTICE and no fatal error there. We use fatal error only when there's no logical exit from the situation - like you tell to call a function and it doesn't exist - there's no default we could substitute and there's no logical way to react on it. When we access undefined variable though there is such way - we can assume the variable is empty. We do the same with foreach() - if it's not iterable, we assume no iteration happens. Can it be a bug? Sure it can. Do we produce fatal error in this case? No we do not. Why we should start doing it with generators? Just because they use iterator classes as implementation detail? Doesn't make too much sense to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
Hi! to be gained vs. the additional risk. And there is little to no benefit in a model where rewinding a closed iterator is allowed, so the threshold for acceptable risk is very low. This is not a difficult case at all, IMHO. We are discussing whether it should lead to the fatal error. I see no reason for that and declaring it's not difficult does not make a reason a bit clearer. There should be a reason for generating fatal error, and this may be a bug is not a reason enough, at least not in PHP, as long established practice in PHP clearly shows. There is no strict technical reason for most fatals in PHP too. Except maybe parser errors, you usually can abstain from doing whatever action would cause the fatal instead of raising the fatal. Calling function that does not exist or abstract method? Return NULL (like an invalid call btw). Returning null is a legitimate function return, and there's no value that can not be legitimately returned from an existing function. Moreover, since unlike empty iterator, not calling a function is not normal (iterators can be legitimately empty, but function can not be legitimately non-existing) fatal error is a proper response to it. Of course, if we used exceptions, there could be an exception thrown instead, which is the same thing more or less. IMO, this is perhaps your strongest argument. But 1) that was a bad idea, 2) we're not really talking about the behavior of foreach(), we're talking about the behavior of specific methods that may or may not be called in the context of a foreach, in a hierarchy where exception throwing is well established. So it's not really analogous. Sorry, but again I have a feeling that you are not satisfied in general with how PHP handles errors and want much more strictness there. Which is completely fine, but I must again emphasize that doing it by sneaking exceptions here and there into the core is not the right way to do it. If you want to change how PHP behaves, it should be done as a language-level principle change, and not being done by altering bits of random patches to behave how the strict people like and inconsistently with how the rest of PHP behaves. I would be happy to discuss it, I have a lot of issues with current error handling too, but we can not just ignore the established principles. If we have a behavior that can be used in two contexts and it is not consistent with one of them, it is not good to point out it may be consistent with another. Not throwing exception in this case is consistent with all other PHP - nothing requires that generator or iterator would throw exceptions on every problem. In fact, I do not believe any of the existing iterators throw on trying to iterate past the end. So not throwing will be consistent with everything. However, throwing will be inconsistent with foreach() usage pattern and only marginally consistent with other iterators - while they indeed throw exceptions, as far as I can see they don't do it in normal iteration scenarios, only when trying to pull something weird like accessing keys of invalid iterator or when using underlying functionality that fails. But as far as I can see you can not make any of existing SPL iterators to throw by repeatedly iterating over them. Even NoRewindIterator - which states no rewind in its name - does not throw when you try to repeatedly iterate over it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
Hi!
Stanislav I though that the discussion on adding this type of functionality
to
strings was already a done deal? Despite the obvious problems it introduces.
I'm not sure what you mean by done deal. There was this RFC:
https://wiki.php.net/rfc/strncmpnegativelen
but that wasn't implemented due to some objections. There's also a pull
about negative strings offset but no RFC and no vote was ever held on it.
I've already pointed out why there is no way that this can be discussed in
connection with 'collection arrays' and so there does need to be a clean
break
between the two for ANY discussion. I believe that PHP is the only language
that
allows us to use -ve indices ( i.e. keys ) in arrays? That was one of the
nice
Depending what you mean by arrays. I'm sure any language that has maps
indexed by value would not exclude values equaling to negative numbers.
E.g. in python:
a = {}
a[-2] = 1
a
{-2: 1}
I'm not sure we need or can do anything else for arrays. We maybe could
for strings, technically, though I'm not currently convinced that having
substr() we really need to. But if the vote goes other way, for strings
I think it may be OK, if we figure out what to do with out-of-the-string
offsets.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC for Adding __toString to DateTime
Hi! Hi, Stas. This has been on my mind as well. I've considered that maybe an INI wide setting would be beneficial here. In fact, there are many places within applications I've worked on where the format for many DateTime objects are the same. What are your thoughts on that? I think yet another ini setting is not a good solution, ini settings are hard to control and they are not meant to deal with application-specific things, since they're global. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
Hi! SPL is not a part of basic language syntax. There are no SPL keywords and no SPL classes used unless you explicitly instantiate those classes. So SPL is different. End users do not see nor buy the difference between what is Zend/ or what is ext/spl (or other) and can't be disabled, like SPL. Of course they'd see it. Here it goes again: There are no SPL keywords and no SPL classes used unless you explicitly instantiate those classes. You can not just write some plain PHP syntax and end up having SPL class. If you use SPL class, you must do new SplSomeClass or something similar. It has nothing to do with disabling. I really think we should consider exceptions, step by step, for the language itself, when it makes sense. And the generators RFC is one We should consider them, but we should not do it in ad-hoc manner. It doesn't work ad hoc - this is exactly what keeps giving PHP users grief and PHP as a project reputation of environment that makes no sense - introducing stuff in random places without regard to how other parts of the language work. Why this piece has exceptions and that doesn't? Oh, that's because one guy implemented that part, another guy implemented this, they didn't want to get to agreement on this, so they just did completely different things in two places. And how the user is expected to work with both? Well, not anybody's problem, each guy got his piece committed, written in his favorite style, matching his unique use case, and couldn't care less about anything else. This is not how language environment should be properly designed. When (and if) we have a model of using exceptions in core, then we can introduce them in core, but introducing them piecemeal in random places just because people fell like it, without any plan or design is just not right. We have to stop doing it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
Hi! * If users do not expect exceptions in the core, they are mistaken. There are indeed exceptions in the core. See ZEND_FE_RESET and zend_interfaces.c. Of course, no evidence has been provided one way or another. This is not right either, but that was done in 2005. We're now in 2012 and trying to make PHP a bit more orderly. * In fact, if there is a unifying theme in the usage of exceptions in PHP, is that exceptions are used when OOP interfaces are involved (see Zend interfaces, SPL, DateTime and PDO -- though optional there). The core vs. non-core argument only looks attractive because there are few built-in classes in the core. That's not my argument. My argument is when you instantiate some class explicitly and work with it, you know you're dealing with certain API that may include exceptions. When you're using foreach(), you don't expect to wrap each foreach() into a try-catch block. But that's what is happening here. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
Hi! More importantly, there is no other satisfactory solution (except a fatal error). foreach has no return value, so it has no other way to signal a failure. If we used a notice or a warning here what would happen is that code that used generators with an invalid state would, except for the notice, work as if it had been given an empty iterator. Put another way, it would fail with only a notice, and continue. That is a far more serious problem. In other circumstances where we emit warnings, we usually have a return value the caller can check for error conditions. I'm not sure I understand why you think behaving as it is an empty iterator and producing an error message is far more serious problem. Could you explain that? For me, it behaves exactly like any other iterator would behave if you had no more useful elements in it - meaning, producing no elements. I do not understand why you think it requires immediate break of the code flow and abandoning the execution of the current function - after all, for the surrounding code the situation where iterator has no elements is a normal situation for an iterator, and iterating twice is indistinguishable - from the POV of the surrounding code - from iterating an empty iterator once. Moreover, if foreach() was supposed to have any side effects, none of these effects would happen with empty return, so there's no danger here either. So I believe the point that this condition requires immediate exit from the code flow needs some explanation. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
Hi! The idea was originally proposed by Marc Easen who created a patch and asked for help with putting together an RFC. I have yet to see a formal proposal but on the list Easen modified his idea so that it should apply to strings alone. With that in mind, would it really cause problems to have code like this: $string = Roses are red; $string[-3] = R; // modifying $string[10] echo $string; // Roses are Red I see how this may work for strings and simple vectors, but what about this: $a = array(-1 = foo, -2 = bar); echo $a[-1]; It should keep returning foo, right? So then the question is - what $array[-1] actually means? Right now I'm not sure I understand it. I guess if somebody wrote an RFC on that it'd make understanding it easier. I see that the patch seems to address just the string part - but the subject also mentions arrays. I think making it clear would be helpful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Generators
Hi! illegal state was written on the RFC when voting opened, and the RFC was accepted almost unanimously. As the proposal was accepted as such, I saw no valid reason not to merge. In fact, changing the proposal after it was voted on would be much more objectionable. I definitely did not agree to using exceptions, though I support the rest of it. I'm completely fine with merging it but just for the record I'd like to note that accepting it doesn't mean we will not tweak it or change some fine details of it - like how we handle some error situations. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC for Adding __toString to DateTime
Hi!
I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.
This must indicate there's actually no default pattern that is default
for everyone. Which suggests maybe we shouldn't have default string
conversion there?
After all, nothing prevents one from having:
class MyDateTime extends DateTime {
public function __toString() {
return $this-format(/* whatever my favorite format is */);
}
}
I'm not sure introducing special state to DateTime for it is the best
way to handle it. Also, most applications would have common date format
- which means since the state is per DateTime object, they'd have to
watch that every object produced would have this property set. I think
it'd be easier to just use DateTime-format() - this way you know what
is produced and it is clear for whoever is reading the code too.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Release scheduling, branching NEWS for 5.4
Hi! I am noticing that the new way we're doing releases in 5.4 is not completely clear to everybody, so I would like to reiterate some points. 1. 5.4 releases are done from release branch (PHP-5.4.X, e.g. current one is PHP-5.4.7). This branch is created 2 weeks before the release, usually on Tuesday, and is released as RC1. Usually, the same code is released two weeks later as official release. This is supposed to happen every month, unless something unexpected happens. 2. Once release branch is created, and until it is released, no code changes are accepted into the release branch, except for: - critical security bugs (remote exploits, remote DoS, etc.) - serious regressions from previous version - grave bugs that make the release impossible 3. This means that every bug that is entered after the branch point is not getting into the branched release, unless it is a very critical bug and even then only if it is explicitly picked up by RMs. Which means the bug should be listed in the NEWS file as belonging to the next version (which at this point is 1.5 months away). I am trying to watch it and clean it up but please when you are committing the bugfixes pay attention to it, it makes the work of the RMs easier. The best and easiest way is just to enter your fix under the tompost version listed in the NEWS file. If you feel any particular bug is so severe that it must go into earlier version than it's supposed to go by default, please send a note to the list and/or to the RMs. 4. 5.3 and 5.4 are stable versions. This means by default new features should not be added there, but go into 5.5 (master), and no BC-breaking changes can be done in 5.3 or 5.4. However, we occasionally make exceptions for small features in 5.4. The proper way to do this is before merging the change to send a message to the list and to the RMs, notifying of the change (with pull URL) and asking if it's fine to do it. It is not because we doubt the quality of anybody's code or think the patch is somehow not good enough - it is to make everybody explicitly aware of the change and give chance to people to raise objections in the (unlikely) case there's some unnoticed problem with the change. I would like to thank everybody that is contributing for their work and I hope following these rules will allow us to maintain the quality of the releases and avoid errors. Thanks, -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
Hi! The spl ext has exceptions all around, so if would count spl as core, we have exceptions in the core already, so it would be ok to add more exceptions where appropriate. SPL is not a part of basic language syntax. There are no SPL keywords and no SPL classes used unless you explicitly instantiate those classes. So SPL is different. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Generators
Hi! Thanks, this is now fixed. It'll throw an exception now, saying that you can't traverse an already closed generator. Nothing in the core throws an exception, why would this?! I'd rather have it skip foreach, maybe producing a warning/notice. It'd otherwise also be only place generators throw exceptions, which is a bit unexpected. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_execute_internal hook missing from PHP 5
Hi! While this has no immediate impact for average PHP users, it basically kills the possibility for an extension like Suhosin to catch all function starts. This should also be a problem for your DTRACE support. And IIRC Xdebug was hooking this point (at least in the past), too. My suggestion is to change the code to call the hook again. Please take a look at https://github.com/php/php-src/pull/178. Would it be a satisfactory solution for this problem? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach
Hi! That's where it gets ugly, in my experience; there are lots of mediocre C++ developers (and legions of even expert PHP/JavaScript/Python/Ruby/etc. devs) who couldn't so much as use a pointer without insert favorite C++ pointer wrapper here around to check their NULLs and do their deletes for them. As a person who used both C and C++ and had to figure out others' code written in C and C++, my experience is that C code is usually easier to figure out (unless it's written in some heavily macro-ed style - remember that C preprocessor is a separate functional language and if you mix the two you can make some fine mess there) because C++ has tons of magic you have always to keep in mind. Operator is never just an operator, assignment is never just an assignment, pointer dereference is never just a pointer dereference. There's magic in all of that. And don't get me started on multilevel templates and trying to figure that out. Of course, C++ gives you a nice means of hiding complexity. But if you're not careful, you'd hide it in a way that it's still there, but you are no longer able to figure out where it is. So if somebody thinks C++ is a panacea here - probably not. Some pieces of Zend Engine are genuinely complex because they do complex things. I don't think hiding it behind C++ would help us much. Yes, we'd earn some with making zval an object, but probably not as much as one would think. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Session Id Collisions
Hi! What's the status of session adoption patch? I've created patches for all 3 versions and I think Stats is going to merge it to master and PHP 5.4. As far as I remember there were some things that needed to be refactored/changed and I didn't see the updates since then, but if you could point me to the latest version I could check it out. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Session Id Collisions
Hi! I know session ID collision will not happen most likely, but there are few people who worries collision. We can check session ID collision when it is generated. You mean two randomly generated session IDs colliding? I think the probability of it is pretty low. I mean it'd take PHP's random number generator function to generate two equal random numbers in the same microsecond. And these are random 64-bit numbers, so unless you're generating billions of sessions per microsecond I don't think it's a very real concern. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach
Hi! foreach supports list syntax: 11 for yes, 4 for no. accepted. foreach supports list with silent token: 2 for yes, 10 for no. denied. And here's again the problem with this voting setup. With all these long discussions about people not getting votes we have 15 people that bothered to vote at all, and essentially the vote is decided by one or two single votes, and the vote doesn't even have to be from a PHP contributor - but the vote of anybody who can register on PHP wiki is enough to decide questions on the core of the language. And I'm not talking about the voice of the masses there but by a single vote of anybody who bothers to vote, which 99% of people just do not. I do not this it is a healthy state of things. Sorry to raise the topic that was discussed 1000 times before, but the situation does not seem to improve. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach
Hi! I got a PHP Wiki account but couldn't vote. Are you sure the Wiki accounts got the permissions to vote? Hm... Not sure, maybe somebody has to enable it? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach
Hi! Only people with a VCS account (or voting group) can vote. OK, I stand corrected then, but participation rate is still awfully low. We can't talk about consensus when everything is decided on one vote. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach
Hi! And this is how democracy works, Stas. If voters don't bother to turn up, too bad. Putting aside the fact that democracy has very little to do with what we're trying to do here (we're not government, we're opensource project), that's how democracy *doesn't work*. As you noticed, it is too bad, and it is exactly the problem we're having - without participation, votes are decided by a random sample of whoever bothered to appear, often on a single vote. This is not a way to build consensus. It is a very unhealthy state of things, and it only contributes to the image of PHP as a project having no direction, no governance and basically existing in a state of brownian motion. I thought we were trying to shed this image. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default input encoding for htmlspecialchars/htmlentities
Hi! In PHP 6 we tried to introduce separate input, script and output encoding settings. Currently in 5.4 we don't have that, but we have those 3 separately for mbstring and for iconv: iconv.input_encoding iconv.internal_encoding iconv.output_encoding mbstring.http_input mbstring.internal_encoding mbstring.http_output Ideally we should be getting rid of the per-feature encoding settings and have a single set of them that we refer to when we need them. This I agree, having unified set of encodings would be a good thing. However, I have a feeling most of the people won't really understand what these three do, and would never bother to set them. From my experience, people don't even bother to set PHP timezone, even though PHP complains each time date function is accessed. So these will be left as default in 99.999% of cases. So do we create a new default_input_encoding ini directive mid-stream in 5.4 for this? Of course with the longer-term in mind that this will be part of a unified set of encoding settings in 5.5 and beyond. What happens to these 6 directives? Will we now have 9 directives for setting the encoding? This reminds me of: http://xkcd.com/927/. Having yet more settings is not really a solution to the problem of too many different settings. So unless we deprecate all others in 5.5 and have people use only generic ones it's not very useful. If we do deprecate them, we need some kind of migration path - i.e. if you set iconv.input_encoding what actually happens? If you set default_input_encoding will it also set mbstring.http_input - or will it affect mbstring without actually setting it? I guess we'd need a good detailed RFC on this :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Generators
Hi! I think the generators RFC has been discussed thoroughly enough by now, so I opened the vote: https://wiki.php.net/rfc/generators#vote I think it's fine but I'd still like to put forward a proposal to reconsider the requirement for parentheses in syntax like this: $data = (yield $value); I don't see how it's particularly useful in this case, or in any case except for the array(), in which case one would want to always use parens to make the code clear, but I don't think we need to make it mandated everywhere just to cover this one (and pretty rare) case. Is there a technical reason to do that? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach
Hi! I honestly don't see what the problem is. If the sample is indeed random, there's no bias as to what the voters as whole would do, tough for close votes or for votes where very few people vote the result could differ. The problem is that this is not consensus, this is apathy and disfunction. If out of 100 or 1000 or whatever we have project participants we can barely find a dozen that want to support a particular change - can we really say this change has the support of the developer community? But most importantly, I would prefer that the people voting actually thought hard about the proposal. And it's more likely (I think) that I'd prefer that too. That's another problem with votes which I did talk about in the past too. However, right now we do not have any guarantee that those 10 people that voted are those that thought hard about the proposal, and not just saw it first time yesterday and thought neat, let's do it, I'll spend as much time on it as it takes to click 'yes' button. I want to emphasize here I don't mean anybody in particular that would do that (I hope nobody does), I am just saying we do not have any way of knowing that, so if you're concerned about that current situation is not ideal. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Session Id Collisions
Hi! Thank you for the links! master https://gist.github.com/1379668 5.4 https://gist.github.com/2224196 5.3 https://gist.github.com/2224360 I think patch of this magnitude is not a good idea for 5.3. As for the rest, it'd be much easier to track and comment on if you could create a pull request. I'll read it through and see if it's OK for 5.4, but either 5.4 or master pull would be great. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Session Id Collisions
Hi! It seems I've already added collision detection when I last updated :) It tries to generate new session ID a few times and if it fails, it does not initialize session. It'd be nice if we could keep it separate. Could you create a pull that includes only the strict session functionality? You could add the collision part in separate pull and we could discuss it separately but it'd be nice to not mix these things. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Combined assignment operator for short ternary
Hi! To point that out: I _don't_ want to change the behaviour, which means | $foo['xy'] ?:= 'bar'; would trigger a notice like | $foo['xy'] = $foo['xy'] ?: 'bar'; Then I personally don't see much point in it. Saving a couple of keystrokes IMHO is not really worth it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Merging fix for quoted_printable_encode()
Hi! Hi everybody, I would like to merge https://github.com/php/php-src/pull/120 in HEAD, 5_4 and 5_3 to fix splitting of soft line breaks. Any concerns? Yes. For 5.3, it does not look like a critical bug, so it shouldn't be there. Also, the tests are still not there - so they should be added before the merge can happen. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
Hi!
generator function f() {
echo Hello World;
}
even more interesting,
$a = generator function() {
echo Hello World;
}
or even:
function foo() {
return generator function() {
echo Hello World;
}
}
$a = foo();
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
Hi!
What would *actually* make sense here are return value typehints. E.g.
one could have something like `public Iterator getIterator() { ... }`.
And again we're back to inventing syntax to do what documentation should
be doing.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
Hi! I am against this. This is even more magic in PHP. Is it really that difficult to have to mark the function with a different keyword, such as generator: You have a point here, but public static final generator function foo() sounds a bit long-winded to me... Also, we'd have then to decide which function can be marked generator and which can't (e.g., interface probably can't, abstract probably can't, anonymous probably can, etc.) which adds more complexity. Also, I think that people that complain about having to scan through huge functions to see if they're generators or not, forget one thing: documentation. Yes, there is a way to make the purpose of the function understandable to a human without having him to do computer's work. That's documentation. Undocumented code is broken code. Broken code is not a good example when we're talking about right design. This should not be a concern, sure, it's annoying for the hiphop developers but they chose to copy and then *chance* the PHP language for their own effect. Here I tend to agree with you - we should base on what's right for PHP, not what HipHop or any other implementation is doing. If we can make their lives easier - fine, but we don't have to be bound by their decisions. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
Hi! For PHP we would need to have some similar behavior. PHP's current exception model is incompatible with GeneratorExitException (because PHP does not have BaseExceptions). So what I'd probably do instead is monkeypatch a ZEND_RETURN opcode at the current execution position and Patching opcodes is not a good idea, since opcodes could be cached, and the cache can be shared between different processes. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi!
My proposal is simple: behave as an inline type hint. The same type hints
you have in arguments lists, but inline. The use case is I want to make
sure this value is of this type and a side benefit is the IDE can know the
variable is of this type too (for autocompletion purposes).
What's wrong with instanceof? You can then throw fatal error if you
want, it's just two lines:
if(!($foo instanceof Bar)) {
trigger_error(E_USER_ERROR, Wrong foo!);
}
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi! And assignment is a kinda common operation. So I hope you can see what's wrong with it now. No I do not. Not every imaginable use case should have dedicated language construct for it - sometimes it is OK to type 2 lines of code. Sometimes even 3. This case is well served by existing language syntax, which also allows much more flexibility and control over what happens if the variable does not match. I see no reason to invent language construct the only purpose of which is to save you typing one if clause. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi! Let me ask you - do you think the existing PHP typehints are pointless too? Do you feel they don't give you enough flexibility? Do you feel they reinvented a language construct for the purpose of saving the typing of one if clause (per argument) (per method) (per class)? They are not pointless, but I think they are often misunderstood and not used correctly. And they definitely lack flexibility in many cases. But they are helpful for one important thing - defining interface between the method and the method client. Having strictly typed variables does not serve it, and trying to make PHP into half-baked half-statically-typed language does not sound like a good idea to me. And why do you keep ignoring the fact that IDE's need additional clutches to understand the type of the variable? Because I don't think inventing language constructs for the purpose of helping IDEs simulate static typing in dynamically typed language makes much sense. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi! All right, your method accepts an array of objects, instances of Foo. How do you enforce this contract? You are trying to re-invent generics/parametrized types and bolt it onto PHP. I still don't think it is a good idea - PHP is not a statically typed language. Just check you array elements if you need. What's your proposal? From the discussion so far, I'd guess it's peppering out code with if-s with the same error written everywhere everytime we check the item in an array. By peppering here you mean one if. Yes, this is my proposal - if you need to do a check - do a check. The same applies to typehints, so make up your mind. No it does not. But this is exactly why I think one of the problems with strict typing in arguments is - because people take it and starting to use it as a legitimation of turning PHP into weird hybrid of dynamically typed language with random islands of static typing popping in random places. I still do not think it is a good idea. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
Hi!
How come there is no straight-foward obvious way to simply remove a given
value from an array?
The same reason there's no simple way to undefine variable whose value
is 42 without knowing the variable name. Array is a container indexed by
keys, not values. So if you've got just a value, there's no way to know
if it's in the container at all, and if it is, where it is, except for
going through all the values and checking if any of them is equal to
what you nedd.
Just look at the number of horrible ways people solve this obvious problem:
I see:
if(($key = array_search($del_val, $messages)) !== false) {
unset($messages[$key]);
}
Nothing horrible here.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Decorators Revisited
Hi! 2. Move instanceof to a handler from the current standalone function. Then each (pecl level) class could choose its own implementation if it is needed. The function could still exist for BC reasons, but would proxy to the handler method if it existed... Then, the wrapped class (the additional pointer) would only need to live on the objects internal store... I don't think overriding instanceof is a very good idea. instanceof has very defined meaning, which implies certain contract between classes and their clients, and allowing everybody to override it to mean whatever one likes looks very dangerous to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi! I agree with you. The one case where this syntax may be very useful is if we want to implement class casting. So introduce a pair of magic methods I do not think we want to implement class casting. I'm not sure how class casting even makes sense - if the object is of one class, how can you just make it into another class by casting? If you mean casting actually returns another object of different class, then just make a method for that that returns that object, I do not see how obscuring the purpose of this operation with unobvious syntax would help. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
Hi! That said, rewind() should behave consistently. I don't feel it makes sense to have rewind() succeed at one point, and fail at another. It would only cause confusion when not familiar with the behavior. Either allow it, or don't. Not both. It does, since foreach uses rewind. So first rewind should succeed if you want iterators be usable in foreach. OTOH, on something like DB result set, next rewind does not make any sense, if you have non-seekable cursor, since the results consumed are gone and there's no way to get them back (you could rerun the query, but it might have side effects and nobody guarantees you'd get the same result anyway). So it makes sense for the generator to succeed on first rewind but fail on next ones. Note that generators by nature are stateful objects, so it is not unexpected that they would produce different result in different states. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Decorators Revisited
Hi! Simply because your object responds to all the same methods of, for example, the FooInterface, does not make it a FooInterface subtype. It just means that in the duck typing sense of the phrase, it can act like a FooInterface for people that are not necessarily concerned that it's actually not is_a() FooInterface. Excellent point here. I have a feeling that with these proposals people want to eat a cake and have it too. To have strictly defined typing structure enforced by strict parameter checks, instanceof checks, etc. and at the same time have the freedom of duck typing. I don't think it's going to work well - if you want duck typing, that's one thing, if you want class hierarchy, that's another thing. Both are viable models for different cases, but I don't see how they can work using the same operators and language constructs. They should be distinct. Now, we could probably make duck typing a bit easier by allowing to check if specific object can respond to specific interface. But I'm not sure if it's worth the effort - why not just have it implement the interface then? In any case, I think duck typing improvement may be a good place for proposals, but let's not confuse it with inheritance hierarchy. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error handling brainstorming
Hi!
Have you stopped for a moment to think this opinion through? Look at two
Of course not. Why would I bother thinking? It is always safe to assume
nobody thinks before writing anything to the list.
typical patterns of error handling. The examples below are generalized from
my file cache code. Having no cache is exceptional, because 99.999% of the
time I run this, there is cache, except the first time when there's not.
Tell me again how you using try..catch is very verbose and how you need to
supply multiple catch blocks for every kind of exception possible?
You are either purposefully exaggerating or not doing it right.
if(fileop1() fileop2() fileop3()) {
// do valid stuff
} else {
// do error stuff
}
It's not that hard.
With exceptions:
try {
fileop1();
fileop2();
fileop3();
normal_actions();
} catch (IOException $e) {
exceptional_actions();
}
Now imagine fileop1 throws some other exception - note that you have no
idea which exceptions are there and nothing guarantees you fileop1
throws only IOException, and by the proposal here, any problem in any
code whatsoever results in exception now, even if the problem was in
converting log message to utf-8 while writing some log inside some
function called by fileop2(). Now your whole app has failed, even though
you don't really care about that log message at all.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
Hi!
https://wiki.php.net/rfc/generators#yield_keyword
https://wiki.php.net/rfc/generators#sending_values
I'm not sure $data = (yield $value) makes a lot of sense. Why we have
two variables here? Why it is only operator in the language that
requires parentheses around? All these complex parentheses rules seem
unnecessarily complicated. I'd rather do it in a more simple way: yield
in an expression means incoming yield. I.e.:
$data = yield;
foo(yield, 1, 2);
list($a, $b) = yield;
Same with:
call(yield $value) - what is the meaning of $value here? Why not just
call(yield)?
I would also not support array((yield $key = $value)) - it seems to be
really unclear how it works. I'd just have yield produce a value which
was sent, and that's it, and you could use this value in the same way
you'd use any other expression.
Only question I have here is what happens if you use yield in the middle
of function call expression, for example:
call(foo(bar(), $foo, yield, 3), baz());
We are kind of stopping the function in the middle of the function call
and going to unrelated code here, and may never return back. Where the
required cleanups, etc. should happen?
Another question is, if my function is like this:
function foo()
{
var_dump(yield);
}
And I do: foo()-current() - what happens? Do I get null there? What
happens if after that I do send() on the same generator? In general,
interaction between incoming and outgoing yields is not very clear,
especially what happens when you combine them.
Also, small point: yield is repeatably called statement in the doc,
but in fact it can be both statement and expression with returning yield.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error handling brainstorming
Hi! Because checking that the returned variable is `!== FALSE` is *way* better than throwing an exception, right? Yes, it is. You can control it, unlike the exception which you can not, unless, again, you wrap everything into try/catch on every kind of exception possible. This type of thing is one of the main reasons I like PDO more than MySQLi. In MySQLi I'm constantly checking return values. In PDO I just wrap it all up one try/catch. It's not like if my query fails I'm going to try a different one. Most of the time it's just logging that something went wrong and reporting it upstream somehow. You are using exceptions for normal flow control. It is not what exceptions should be used for. They are called exceptions for a reason. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error handling brainstorming
Hi!
but sometimes you want to be more precise. With exceptions, we have an
elegant way to manage all failures as a whole, or to differenciate each
reason.
You do not, unless you have 20 exception types and catch them all
separately. Which nobody would ever do for one simple reason - what if
you miss one? What if next version adds one and you didn't update your
code? In practice what happens is people just write try { ...}
catch(Exception e) {} and that's it.
protected call function [1]. A convenient mean to say «OK, I know this
expression may raise an exception, but I don't care, discard it silently
please. I will check if my variable has been set or not.».
[1] : http://www.lua.org/pil/8.4.html
Which, coincidentally, is exactly like PHP works. I see no reason to
rewrite all the functions just to add the functions that allow you to go
back.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error handling brainstorming
Hi! Personally, I'm used to what other languages like Python do, and I think it makes more sense. Exceptions mean you can try/catch the things your code needs to be prepared for (non-existence, maybe), but other things No, they mean you need to *always* try/catch since you have to means to check if the downstream function can throw and exception or maybe call some other function that throws and exception. Exceptions propagate. In Java, you have compiler-controlled throws (which doesn't work in 100% of cases either - I regularly get exception messages from Eclipse, and this one is written by people with great knowledge of Java) - in PHP, you will have nothing. It's one thing when the code writes a warning and returns null when something unexpected happens, another when it throws and exception and you *have* to know which kind it will be and catch it - or just catch everything and ignore it (because you have no idea what it might be) and - check some success value then! you haven't considered or are very unlikely, can just not be caught and cause your code to halt execution. And it makes it harder to accidentally avoid checking for errors and then wonder why $file is some NULL or FALSE or other error value. How it makes it harder? If you forget to check the result, you'll as well forget to try/catch. It just makes the consequences worse - and remember, this all happens in runtime! -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error handling brainstorming
Hi! circumstance. If it's not, you should be checking for existence first (via file_exists() or is_readable(), etc)... This is exactly how we got into this mess with $x = isset($a['x'])?$a['x']:null; We're trying to get out of this mess and you're proposing to build another mess just like that. errors, you can't just fread the return value. You *need* to change your execution flow based on that error. Therefore, it is exceptional. That's exactly what I am saying. Exceptions should not be a means of flow control, and that's exactly what are you doing here. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error handling brainstorming
Hi!
Basically Etienne mentioned that the original issue was a good example why
would we reconsider throwing exceptions from the core, which is currently
discouraged.[2]
Stan replied with the idea of turning the current error handling mechanism
in php into using Exceptions for everything, but keeping some error types
as is/uncatchable. [3]
Exceptions are different from PHP errors. For example, if you try to
open a file and the file isn't there, throwing exception is a very
annoying behavior (yes I know some languages do that, IMO it's wrong).
The reason is that it's pretty normal and within normal set of
situations to which code should be prepared, so you will either have to
obsessively wrap everything with try/catch blocks or do exception typing
like Java does. Both options are quite annoying. I think it's much
better to just open file and check if the result is OK. Converting it to
exception doesn't really improve situation, as if downstream code didn't
handle it the upstream probably won't know what to do with that
exception either. This leads to code like try { whatever(); }
catch(Exception e) {}. I saw tons of that in Java.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Integrate PECL into PHP
Hi! Many developers use shared hosting as PHP env which not allows them to install new extensions in PHP. You do realize they do it not because they are evil people thriving on suffering of their clients, but because they need controlled environment they can maintain? If you need environment you control, buy a VPS hosting. Shared hosting is cheap for a reason, and trying to cheat shared hosters by changing PHP both wrong and pointless. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.
Hi! I'm looking at a segfault in the SPL caused by the blind creation of a class, which seems to only fail when the class is disabled. I'm wondering in how many other places this could occur. This seems to be pretty bad. I'd say creation of an instance of disabled class should be a fatal error, but regardless SPL should handle returns properly. Did you submit a bug about the SPL problem? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4.6RC1 Released for Testing!
Hi! I've released PHP 5.4.6RC1 which can be found here: http://downloads.php.net/stas/ Windows binaries as always are at: http://windows.php.net/qa/ This is a regular bugfix release, the full list of issues fixed can be found in the NEWS files. Please test and report if anything is broken. If no critical issues is found in this RC, the final version will be released in two weeks. Regards, Stas Malyshev and David Soria Parra -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove calls with incompatible Context
Hi! https://wiki.php.net/rfc/incompat_ctx An RFC for deprecating and removing $this from incompatible context. IMO makes sense. Nulling-out $this makes most of the sane code (like de-facto static functions not marked as static) work, and breaking insane code in 5.5 in acceptable. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] xml ext and amp; entities
Hi! Can you try using a stock version of libxml or using the latest version? I met some issues in the past on Centos because of bad patches applied to libxml. I've built both 2.7.8 and 2.8.0 from source - same result. amp; is ignored when parsing with PHP xml extension. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing users along ...
Hi! The current raft of PHP problems arise from the fact that we actually put a lot of emphasis on not breaking backward compatibility seems just to be lip service to the real problem ... Taking stuff out in PHP5.4 would be fine if people are So what would happen if it would be real BC? I mean, if you want 5.4, we need to make some changes. Some of these changes will make either impossible or impractical to support broken code, and some broken code warnings were actually requested by the users. So I see one of the two ways: 1. Ignore our users asking for warnings on broken code, since somebody might have problems upgrading when his code is broken. 2. Listen to our users asking for warning on broken code, and prefer future clean code to old broken one. Do you see any third way to do? If so, please describe. Helping to solve the problem would also help everybody else upgrade TO PHP5.4? OK, so what help do you require? Add to this the fun getting Apache 2.4 configured with PHP and my old framework, it is no wonder I grumpy ... I would much rather be adding functionality and working on NEW stuff than fixing the problems other people leave behind. And I don't need any of the new PHP5.3/44 features to write my own new code. While I can sympathize with your problems fixing bad code left by other people, I am not sure how it is relevant on this list - is there something that people present on this list can help you with? What is it? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing users along ...
Hi! PEAR and PECL that work with PHP5.4 out of the box? At least the core of PEAR that does not throw strict warnings from a stock install of PHP5.4 as E_STRICT is on. For PEAR is think it is a wrong list, as for PECL most extensions are maintained by their maintainers, and internals specifically works only on the core. I think that this is the problem here. fixing bad code is simply not a statement that I recognise! I am not fixing bad code, I am re-writing much of it simply because the style is no longer acceptable, or somebody changed a default You are trying to reframe the same meaning with different words, but the meaning does not change - the code that is no longer acceptable in 5.4 is not acceptable for a reason. Usually the reason is that the code is broken or using PHP in a wrong way - such as silently converting nulls to objects, strings to arrays, arrays to strings, etc. setting without considering the consequences ( ?= not working in PHP5.3 is STILL biting as ISP are only upgrading to PHP5.3! ) Err, I'm not sure what you mean - ?= certainly works in 5.3. I still have not had a proper answer to a question I repeatedly ask. Please can we have some tutorials on how 'strict' styling should be used? I'm fixing the warnings created but I still do not fully understand what I am fixing. The main I, for one, do not understand what you are asking. If somebody could explain it would be nice. Strict warnings are issued when your code is doing something that the designers of the engine consider a bad idea, which in vast majority of cases means a bug. rework area has been not being able to use '$this' in static functions, even if the function checks $this and defaults to the static code internally. Adding Good example. static function is called static for a reason, and the reason is it does not belong to an object but to a class, thus it can not and should not have $this. Code that uses $this in a static function is thus broken and needs to be fixed. In overwhelming majority of the code this is a bug. If some code used it as feature, it was a bad idea, and the time of this bad idea is gone now. 'public/private/protected/static/self ...' and using them in the right places is well documented in bits and pieces, but there is no general 'how to' put the whole together? I suppose someone will want to add traits and the rest to that, How to put what together? The manual page for static states explicitly: Because static methods are callable without an instance of the object created, the pseudo-variable $this is not available inside the method declared as static. What other howto is needed for this? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing users along ...
Hi! Only with short tags on ... 5.4 has detached it from that, but 5.3 still switches it off by default, and convincing ISP to switch short tags on again is a lost cause :( Fixing it in PHP5.3 was rejected :( Errm... So you are complaining we're not going back in time now and make different decision about PHP 5.3 that was made years ago? Or what is your point exactly? Fine, so I just add 'static' rework all the code, and fix the error, but I think I should also be adding public as well? It's not needed to clear the warning, If your functions are public, I'd recommend adding public. However, as the same manual states, public is optional for BC reasons and if access is omitted, public is assumed. Same manual, same page, one paragraph above: For compatibility with PHP 4, if no visibility declaration is used, then the property or method will be treated as if it was declared as public. mind so much some of the rework, but I've no confidence that I will not be doing this exercise again next year - on the same code :( If you want somebody to assure you that the code that nobody except you have seen would not contain any problems after you fix some of the problems you have now but nobody except you knows about - then I'm afraid it's not something that anybody here is able to promise you. If you have some specific proposal - let's hear it. Otherwise I'd recommend following current best practices for writing good PHP code - e.g. what described in the manual and many framework style guides, etc., don't use any clever tricks that abuse PHP constructs for what they weren't meant to do - and you have reasonable assurance it will keep working fine. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
Hi!
I've looked a bit into other languages (Ruby, Python, Go) and
all of them do not generate an error when an undefined dict/hash/map key is
accessed.
Python would definitely throw an exception:
a = {}
a
{}
print a['a']
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: 'a'
And it's just as annoying as in PHP. Actually, probably more annoying
:). But it has .get() which solves the problem usually, albeit in a bit
more verbose way. Also, Python has defaultdict which I would usually use
when I need keys to be created automatically.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] xml ext and amp; entities
Hi! I was running PHP tests on my freshly installed CentOS instance and I noticed that two XML tests were failing: ext/xml/tests/bug35447.phpt and ext/xml/tests/xml011.phpt. Looks like for some reason XML parser when parsing something like this: This amp; that - produces empty string instead of when parsing amp;. Any idea why it could be happening? libxml2 is of version 2.7.8 and in general it's standard CentOS 6.3, 64-bit. Does not reproduce on Mac with same PHP and same libxml2 version. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug on bc math?
Hi! but on the hand, we may also consider this as a bug, behavior not act like the doc said :) If the library we are wrapping behaves in certain way, our function should behave in the same way. If docs say otherwise, docs should be fixed. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
Hi! Secondly, I noticed that Python's PEPs are numbered, unlike PHP's RFCs. Whilst they aren't quite the same thing, I wonder if this would be useful, particularly since it provides a simple and unambiguous way to refer to one, e.g. RFC 123 instead of RFC on how to write an RFC. Why have numbers if we can use URLs? URLs both uniquely identify the RFC and suggest what they are about. Can you say what PEP 410 is about? How about https://wiki.php.net/rfc/releaseprocess? If we do that, we should call them PHP RFCs (PRFCs?) instead, to avoid confusion with IETF RFCs, otherwise it may get confusing. I have yet to meet one person who was confused when we talked about generators RFC and thought we meant IETF RFC describing standards for electrical generators in data centers. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Release Frequency, NEWS, etc.
Hi! The current idea would be to skip every second release (unless security issues demand something else) both in release date as well as version number. So for instance 5.4.6 will be released sometime next month alone. A month later there will be 5.3.17 and 5.4.7. I think it makes sense. Doing this has an obvious issue, though: NEWS entries are currently only placed in the lowest branch. With the example from above and the current way the NEWS are handled 5.4.6 NEWS would be quite small and there would be no 5.3 NEWS to check for further things. I think note in the NEWS should be placed immediately when the bug is fixed (at least the lowest version NEWS). However, if we want the bug to appear in all NEWS for both 5.4 and 5.3, I think we'd have to ask people to put note in both. I, on my part, am reviewing NEWS periodically and merge entries that I can find that are in 5.3 but not in 5.4. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
Hi! Speaking of parse errors, I'm having trouble parsing this line. I *think* you're saying that generators are just complex things and that's the way it should be. I... guess I agree, though I have a lower opinion on the complexity of generators. Seem like a fairly straightforward concept to me. They are certainly proven concepts. They're not that complex. They are basically a syntax sugar around iterators, and we already have tons of iterators which are widely used. Actually, it's easier than iterator since you have to implement just one method, not five of them. Of course, it's not a beginner's feature - but we have now many features which require some understanding of the language - like magics, anonymous functions, etc. It doesn't by itself make it inappropriate. If we can make it work in a way that won't be confusing and illogical for people knowing how iterators work, then I think it's OK. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
Hi! The implementation is outlined in the RFC-stub here: https://wiki.php.net/rfc/generators Before going any further I'd like to get some comments about what you think of adding generator support to PHP. Some notes on the RFC: 1. I think we should support rewind() by just creating a new generator instance (i.e. doing the same that is done when generator is called for the first time). If it depends on the resource that generator changes as a side effect, so be it. rewindable() looks like unnecessary complication which IMHO will not be useful in most cases. 2. I understand the pre-yield code is called on current(). What about key()? I think it makes sense to call it there too - i.e. pre-yield code is called whenever first key() or current() - it should be made explicit. 3. return values. I think non-empty return in generator should produce a notice or E_STRICT. 4. What happens to the state variables when generator is cloned? Just addref or real cloning for objects? 5. Are multiple yields allowed? I.e. the rfc mentions something like yield yield $a - what that would mean? I'd allow yield only be applied to variable expression (lval) because double yield doesn't make sense to me, but maybe I miss something. 6. “Sending values” section seems to be missing. Especially useful would be to cover what happens with keys there and what is the syntax there - is it just $a = yield;? Or does it mean when yield is used in expression it becomes incoming yield? And, last but not least - do we need sending into generators at all? 6. What happens if you send into a by-ref generator? Is the data sent by-ref then? What if it's an expression that can't be send by-ref? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: finally, was: Make try/catch brackets optinal
Hi! For finally see https://bugs.php.net/bug.php?id=32100 it seems that the core devs don't like the idea, but that feature request seems to have a lot of supporters, and comes up frequently. I haven't seen it come with a pull req though ;) BTW, look at how finally is implemented in Java, for example, to see why it may not be that easy to do it properly. But if somebody would provide the RFC with a patch, we could discuss it and run a vote and see if it has any support now or not. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Hi! In particular this means that... ... if a die() is execute somewhere in the try clause (or a called function) the finally clause must still be run. ... if a parse error or other fatal error occurs in the try clause (or called function) the finally clause must still be run. ... if the user interrupts the process the finally clause must still be run. No I don't think so. finally clause is used to clean up resources allocated/initialized by the code inside try clause. All the above functions will terminate the script and thus all the resources that were allocated will be freed. If you so something more persistent, then a) use shutdown functions b) know that the script can be killed at any moment anyway, so PHP can not guarantee you anything. I don't see how finally ever implied it would be called on die(). Basically this requires that all of the actions that are currently fatal need to be converted to exceptions. E.g. Python has special SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError and so on. So basically this requires that PHP will be converted to Python. ;) I'd almost write an RFC but then I remembered somebody already wrote Python! :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Hi! PHP risks losing some of its uniqueness to fixing things, unfortunately. But losing bad features and moving forward is good, right? I'm not sure what you are talking about here, but I'm sure I can not accept argument Python does it this way, so we must do it exactly the same way even if we have to rewrite whole engine and change whole approach of how things done in PHP. If you want exactly what Python does, you always have Python. It's fine to look into what Python does, but how it fits PHP and uses cases of the *PHP* users should always come first, and implementation details of how Python or any other language does things can be a guidance, but never should override this. So if Python does finally in certain way, fine, but it's no no way by itself defines how PHP should do it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 7/24/12 4:20 AM, Laruence wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally I'm not seeing tests for the following situations: 1. Return from catch block. 2. Another try/catch block inside finally block. 3. Multiple nested functions with finally blocks. 4. Exception thrown in catch block. Could you add those? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi! from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2, ForthSpace\Class3 as Alias3; I'm not sure it's necessary. If you import a real lot of the classes from the same namespace, just import the parent namespace. And this syntax makes less clear what is the true name of Class2 and also by similarity to python syntax would lead people to think it does the same thing python one does - which it is not. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Hi! Still my point stands. If fatal errors and die are not handled by finally the feature does not make sense to me. You simply can't do any kind of remotely important cleanup in there (like releasing locks etc). Well, I'm sorry you don't understand it but I think you are too focused on exactly copying what you are accustomed to, and this is not the goal for PHP. I don't know what you mean by important cleanup but if you mean you do some persistent things that absolutely need to be cleaned up by code, I have very bad news for you. PHP is not the language that can do it. PHP script can be terminated at any moment - by the webserver, by the OS, by other means - and that'd be just that, it would cease to exist and no code will be run. finally can not and will not solve this problem. It is not meant to solve this problem. It is meant to solve specific use-case of using temporary resources in a block of code and cleaning them immediately (as opposed to waiting until request-level cleanup). Fortunately, in my many years of working with PHP I don't think I ever saw any case where simple OS functions coupled with more powerful constructs like transactions were not enough to cleanup anything that PHP script could do. Similarly die; is commonly called in code doing header redirects. I think it would be unacceptable to not run cleanup clauses in that case. If you need cleanups on the request level, you already have shutdown functions. Those, btw, aren't guaranteed to run in every case too - there can be situations, albeit rare, that shutdown could fail and thus some cleanup not run (e.g. the process being killed, PHP getting out of memory, etc.). Also, there could be more frequent situation that your shutdown code has a bug which causes it to terminate early. Which btw may be a case with Python code too - unless you wrap every statement in a separate finally clause you have the same issue. Another, separate point against finally is that in PHP (unlike many other languages) most (all?) built-in resources clean up after themselves. So if you open a file you don't have to worry about closing it again. It'll do that all by itself as soon as it goes out You don't have to, but in some cases you better to if you write more than two-liner, since otherwise, while the file does not survive the request, with suitable scope it may linger much longer than you expect. So in some cases having shorter-scope cleanups can be helpful. Of course, you can also do pretty much the same with RAII pattern - so it's not strictly necessary. But may be nice to have. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
