Re: [PHP-DEV] Attributes support proposal
On Apr 18, 2005, at 8:26 AM, Wez Furlong wrote: From a technical viewpoint, how do these attributes affect the class? Are they simply no-ops that are tagged and made available via the reflection API? How does this really help improve PHP? I know it sounds cool, but so does recording phpdoc comments, and we decided to not do that in the default case for performance reasons. How are these attributes much different from that? A docblock parser would be nice though. :) George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new overloading feature?
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Leonardo Pedretti [EMAIL PROTECTED] writes: I would like (for code cleanliness purposes) to make 'new' return a reference to an already created object under certain circumstances without using a factory, is it possible? A number of months ago, I proposed a similar feature, implemented as overloading a __new() function. At the time, it seemed I was the only one who wanted it, but your request is for a feature identical to my request. Here's my previous message. (The whole thread can be found under the subject new overloading feature? from 5 Nov 2004). I'd love for this to be revisited now that there's someone else with a similar desire. I'm not an OO expert, but doesn't this break a fundamental semantic of OOP -- namely that new() returns a new object of the specified class. Isn't this the whole reason that the Singleton pattern exists? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annoying DOM limitation
On May 13, 2005, at 5:29 PM, Jared Williams wrote:
While hacking on a PHPDoc - WSDL generator, I ran into an
annoying limitation in the dom extension: you can't add a
namespace to a dom document unless you have an element in
that namespace. Why might you want to do this? Well, a
common thing is to have your xml-schema types to be specified
as attribute values, i.e.
element name=foo type=xsd:string/
for this to work I need xsd to be an alias for
http://www.w3.org/2001/ XMLSchema.
To work around this, I added a DomElement::addNS($uri,
$alias) method to Dom. Adding the namespace 'manually' as an
attribute on an element does not work.
I know this isn't part of the Dom spec, but it's incredibly useful.
Does anyone (Rob, Chegru) mind me adding it to HEAD?
Hmm, I have been doing this via setAttributeNS(), with the XML
namespace namepace
define('NS_NS', 'http://www.w3.org/2000/xmlns/');
define('NS_XLINK', 'http://www.w3.org/1999/xlink');
$document = new DOMDocument();
$root = $document-createElement('root');
$document-appendChild($root);
$root-setAttributeNS(NS_NS, 'xmlns:xlink', NS_XLINK);
echo $document-saveXML();
Haven't encountered any problems with this method, seems to produce
XML (SVG in this case) fine.
Apparently I had one too many margaritas yesterday while I was
writing this. Whatever I was doing to trigger my error, your methods
work.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for php_error_cb
On May 16, 2005, at 3:16 PM, Blake Matheny wrote: Attached is a small patch that allows for a custom error handler to be used instead of php_log_err. This is useful for custom logging of error types that can't be handled with a user-space error handler (such as E_ERROR, E_PARSE, etc.). In order to use a custom error handler set error_log to so:/path/to/ so in the php.ini file, where the shared object has a function called error_handler with the following prototype: This is already possible without your patch: just write a php extension and change the zend_error_cb function pointer to your custom C function in MINIT. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for php_error_cb
On May 17, 2005, at 8:04 AM, Blake Matheny wrote: Is there anything incorrect/wrong with the solution I proposed? I realize that a custom extension would also work, but there are several advantages to doing it the way I implemented it - No need to add an extension every time you upgrade PHP You can of course dynamically load extensions from your ini, and they only need to change when the API version changes. What you have is essentially a special purpose extension. The situation is that you want to provide an alternative type of extension to accomplish something that can already be accomplished through an extension (and which was designed to support exactly the things you're trying to do (and more)). That sort of redundancy isn't very useful. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php5 - target for migration or new innovation (was: Re: [PHP-DEV] Re: References Problem Patch)
On May 30, 2005, at 7:15 PM, Andi Gutmans wrote: Not sure who you're talking to but I know a large amount of companies (some of them huge) who have based their development on PHP 5. Can you share (or guess at) the skew of companies migrating existing apps from PHP4 to PHP5 versus the number of companies developing new apps on PHP5? What I'm seeing at OmniTI is that customers with (big or XML-intensive) existing PHP4 code bases are reluctant to migrate to PHP5 (actually to my frustration, so it's not just my bias entering the fray), while customers developing new apps are keen to do so on 5. But anyway, it's really irrelevant to this discussion. Yes, but interesting. Maybe it will live in a new thread? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Jun 6, 2005, at 3:09 AM, Derick Rethans wrote: On Mon, 6 Jun 2005, Jani Taskinen wrote: And the much needed goto for the next one (5.2/5.5/6.0 or whatever it will be) ? So +1 from me. (wasn't there a patch for this already somewhere?) For me too: +1. +1 here as well. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Jun 6, 2005, at 9:28 AM, Derick Rethans wrote: On Mon, 6 Jun 2005, Stanislav Malyshev wrote: MMExceptions ? No thank you, even worse then continue/break.. Why is it worse? That's something that I don't understand - why people think exceptions, which have clear structured mechanism of using them, are worse than goto which has no safeguards at all and allows to do a lot of messy things. What's the problem with exceptions? Because not everybody and their mother uses OO. Why do you need to use OO to use exceptions?
Re: [PHP-DEV] PHP 5.1
On Jun 6, 2005, at 1:46 PM, Sebastian Bergmann wrote: George Schlossnagle wrote: Why do you need to use OO to use exceptions? Maybe throw new Exception; is already too much OO for somebody's mother because you create a new object of the Exception class here. I'm pretty sure I can convince _my_ mother to use that without 'embracing OO'. At any rate, exceptions are distinct from OOP in many languages. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Jun 7, 2005, at 7:37 AM, Nelson Menezes wrote: Goto is a plainly bad idea. Yes it has its uses, but 99% of the time it would just be completely, mercilessly, utterly abused. Its not good or bad, just a language construct. Its how you use it. I agree. I just think it will be used badly in most instances, and PHP reputation will suffer as a result. IMHO that's a bad tradeoff when you consider the advantages you get from goto. I don't think I've ever heard Perl or C maligned on the basis of their support for goto. Perhaps I just travel in the wrong circles. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Jun 7, 2005, at 8:08 AM, Stanislav Malyshev wrote: AHDoes C suffer from having goto? Does C suffer from being able to freely convert any type to any and access any memory location? Should we add these features too? Funny, I was just talking with Andi about that at dinner the other night (arbitrary class casting) Still, goto is the discussion, let's not create strawmen of things not on the table. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Jun 7, 2005, at 8:12 AM, Stanislav Malyshev wrote: GSAnd yet it exists and people use it productively - so you've GSsuccessfully undermined your own argument (and Perl's goto is far more GSflexible|evil than the one proposed for PHP). Care to give example where it is really needed and can't be trivially reduced to labeled break? Perl's goto has a number of features that the proposed one does not, for instance the ability to jump out of scope. This is necessary when using AUTOLOAD in Perl for altering the callstack to not reflect that you were just in AUTOLOAD, but were in the overloaded function instead. It's a standard (albeit advanced) Perl idiom. Very few things are really unnecessary. Is the functionality supported by ifsetor() necessary? Is the ability to use assignments in conditionals necessary? Is the existence of switch() as a language construct really necessary? All of these can be trivially implemented with other language primitives. PHP is full of syntactic sugar that makes common tasks easy, and gives people the ability to solve problems in the way they see fit. The point isn't whether or not you see Perl (or C's) goto as useful or not. The point is that other people do, and neither has caused the ruinous demise of either language. As for my own example, many state machines make extensive use of goto to avoid recursive calls. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Jun 7, 2005, at 8:25 AM, Stanislav Malyshev wrote: GBcontrol structures are not useful. This is not the case in PHP. A GBsimple example in the manual showing proper usage of break/ continue GBand warning to only use goto as a last resort would be sufficient for GBdiscouraging newbies from shooting their feet off. The problem is not only that - the problem is that some constructs might be unsafe to jump in. Example - jumping in or out of foreach may be very problematic with current engine (jumping in may result in crash, jumping out - in memory leaks). And there can be more such things. Perl's goto specifically forbids jumping into control structures that require intialization (for instance, foreach()). That seems like a sensible limitation to me. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Jun 7, 2005, at 8:43 AM, Stanislav Malyshev wrote: GSPerl's goto specifically forbids jumping into control structures that GSrequire intialization (for instance, foreach()). That seems like a GSsensible limitation to me. jumping out is no good either. Because of the memory issues? This is a) an inherent problem with labeled break as well, b) a problem that self-rectifies at the end of the request (as per Derick's discussion). George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Jun 7, 2005, at 8:46 AM, Sascha Schumann wrote: As for my own example, many state machines make extensive use of goto to avoid recursive calls. Goto is not required for that. State machines such as the following You conveniently ignored the part of my mail where I noted that none of the features being discussed these days (and in fact many language constructs in PHP) are not 'required' either (in the sense that it is trivial to reimplement their functionality using other language features). We are far past a minimal set of language primitives in PHP. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Jun 7, 2005, at 8:55 AM, Stanislav Malyshev wrote: GS b) a problem that self-rectifies at the end of the request (as per GSDerick's discussion). So you basically is saying let's ignore memory leaks. Well, point a) implied that it's a solvable problem, at least as much as it is when doing any sort of premature exit from a block. Isn't ignoring memory leaks the official (tm) strategy for using exceptions in PHP5 though? :) George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Jun 9, 2005, at 6:51 PM, Andi Gutmans wrote: Hi, Finally catching up with all the million comments. Definitely a way to get distracted from real work :) I don't want to get distracted from what I consider should be the main objective and bigger issues than yes to one or another feature. We should get PDO, new execution engine and some other changes out to the public. We need to fold in the Unicode changes into public CVS before we have a maintenance nightmare. We can't manage more than two PHP 5 branches at once. It'll be unmaintainable and tough. I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start getting some very much needed feedback from the public for HEAD. After talking to Andrei Rasmus, I think it becomes clear that we should aim to RC 5.1 in the beginning of July so that we can close the 5.0.x branch and merge Unicode into HEAD. There will hopefully then be a quick development cycle for upgrading a lot of functions for Unicode support, and in addition we could address some features like goto, and other improvements which are required. Releasing 5.1 doesn't mean 5.5 or 6.0 (whatever we call the Unicode version) couldn't be released this year. I'm sure Andrei would love that :) (so would I, and incidentally my original name is Andrei too). It's for the benefit of all to make progress and not slow the release cycle to a halt, especially for people who are looking forward to the major features. We have some great stuff coming and it'll go bad if we don't move the major pieces along. I think this is an excellent idea. All of the features being debated hotly now are extremely minor compared to good unicode support, and given the broad effect of that change, getting it into HEAD and thus into mainstream development usage would be a really good thing. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] In regards to E_STRICT and PHP5
On Jun 16, 2005, at 2:50 PM, boots wrote: --- Andi Gutmans [EMAIL PROTECTED] wrote: You missed the point of E_STRICT. I introduced it as an E_PEDANTIC. That was the whole idea. To be pedantic about code that works, not to warn about code that doesn't work (which is for higher warning levels) I don't think I missed that, I just don't appreciate it :) If you don't want pedantic checks, don't run with E_STRICT. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] In regards to E_STRICT and PHP5
On Jun 16, 2005, at 10:15 PM, boots wrote: These answers make me feel as if maybe just a little bit you guys are looking down your nose at me without really considering the basis of the issue I am trying to raise. I know the tools well enough to use E_ALL -- thanks. I'm concerned about end users who don't know enough to help themselves -- but whom I have to support. I'm talking about problems running PHP4 codebases on a PHP5 engine. E_STRICT isn't part of E_ALL and isn't on by default. If your clients have the relatively basic sophistication you describe, how do you think they'll stumble into E_STRICT? It's a pedantic error warning, just like gcc -pedantic. To paraphrase, I didn't miss your point, I just don't appreciate it. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Jul 7, 2005, at 7:56 PM, Andi Gutmans wrote: It would look the following: $timeZone-getName(); vs. date_timezone_get($date); $date-getOffset(); vs. date_offset_get($date); Personally, unrelated to OO I think it's a nicer and cleaner way of exposing such an API. It would also make it easier for some of the other new extensions like SimpleXML, SOAP, PDO , etc. to take advantage of it when exposing data types. I think this should be seriously considered. I'll be happy to work with you on this if it makes sense to you and others. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mail() into separate extension?
Drop-in replacements are evil. If you want to do this, you should just create a new function that does what you need to do and name it differently. If you're dead-set on doing a name-based replacement, then you should have your extension modify the symbol table directly, but again, this is evil. George On Jul 18, 2005, at 9:57 AM, Piotr Roszatycki wrote: Hi. I'd like to see mail() function in separate extension module. It would be possible to replace i.e. standard `extension=mail.so' with i.e. `extension=sendmail.so'. What do you think? Is it worth to prepare the patch? -- .''`.Piotr Roszatycki, Netia SA : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php George Schlossnagle -- Vice President of Engineering -- OmniTI Computer Consulting -- http://www.omniti.com
Re: [PHP-DEV] mail() into separate extension?
On Jul 18, 2005, at 10:30 AM, Andrew Yochum wrote: On Jul 18, 2005, at 10:15 AM, George Schlossnagle wrote: Drop-in replacements are evil. If you want to do this, you should just create a new function that does what you need to do and name it differently. If you're dead-set on doing a name-based replacement, then you should have your extension modify the symbol table directly, but again, this is evil. George George, Can you please substantiate your statement that drop-in replacements are evil? I could only see them being a problem if they don't fully implement the existing API. Sure. They inevitably will have differing behaviors (if not, why not just have a single unified function). Given that, you'll have different behaviors on different machines in a way that is not terribly transparent to end-users. That's evil. Not that there's anything wrong with being evil from time to time. That's the reason that apd had a replace_function call for mucking with the symbol table. But that's something that should be done locally. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SOAP SSL support doesn't work when allow_url_fopen is turned off
On Jul 28, 2005, at 9:10 AM, Zeev Suraski wrote: At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote: Are you therefore saying SOAP support should be 100% diabled when allow_url_fopen is off? SOAP is not disabled, simply prevented from querying remote data sources directly. What exactly can you do with it other than query remote data sources? I tend to agree with Adam (and I guess Wez) - SOAP should not be affected by allow_url_fopen. We can have another directive, allow_web_services_clients or whatever, that will affect SOAP instead. The average user will have no idea that allow_url_fopen is in any way related to web services. I think we should namespace them per extension: soap.allow_url_fopen (or something more inspired). This will allow you to toggle it on a per-extension basis easily. That having been said, in the current implementation this should probably only affect the pulling of the WSDL file, right (since currently the actual client request is done through a non-streams implementation). You can certainly have a local WSDL file. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SOAP SSL support doesn't work when allow_url_fopen is turned off
On Jul 28, 2005, at 9:21 AM, Ilia Alshanetsky wrote: Zeev Suraski wrote: At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote: Are you therefore saying SOAP support should be 100% diabled when allow_url_fopen is off? SOAP is not disabled, simply prevented from querying remote data sources directly. What exactly can you do with it other than query remote data sources? I tend to agree with Adam (and I guess Wez) - SOAP should not be affected by allow_url_fopen. Why not simply make existing INI option only restrict script loading operations such as include/require, afterall this is what it tries to primarily prevent anyway. Maybe - I would say that there are good (non-security-related) reasons for restricting url open elsewhere. I'd rather see a per- extension override that allows you to say exactly what you want occuring. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SOAP SSL support doesn't work when allow_url_fopen is turned off
On Jul 28, 2005, at 9:49 AM, Ilia Alshanetsky wrote:
sure: eval('file_get_contents(http://evil.org;);');
Ok, but there is nothing (allow_url_fopen does not work here)
preventing me from doing similar via:
$fp = fsockopen(evil.org, 80);
$fp = fwrite($fp, GET /evil_code.txt HTTP/1.0\r\nHost: evil.org\r\n
\r\n);
eval(stream_get_contents($fp));
But I can (easily enough) disable the socket functions in PHP, not so
convenient with file_get_contents.'
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
On Aug 9, 2005, at 5:56 AM, Pierre-Alain Joye wrote:
On Tue, 9 Aug 2005 10:15:15 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
This technique is already frequently used to cope with lazy
loaded code, which even with cached code compilers, is pretty
damn efficient in a scripted language (less IO operations,
less parsing, less memory...)
It is not about the fact we 'can' load the class, but that we
dont 'want' to load the class.. - it's a waste of resources,
memory, cpu etc. just for the sake of CS perfection..
Last time I looked PHP was about getting thing done
efficiently, not about giving your university professor a
woody... ;)
That's my point. The autoload magic (crap? :)) is not in cause
here. If you _test_ something, you do not expect the test
operator to abort your execution (fatal error).
But you're testing for something that you *know* that can not
exist in your code base. That is a broken test, so it should
throw a fatal error.
function wrapperFoo($obj) {
if (is_a($obj, 'MyFoo') {
}
... other tests
}
worked before is_a was deprecated.
function wrapperFoo($obj) {
if ($obj instanceof MyFoo) {
}
}
To duplicate the old semantic now you need to do:
if(class_exists('MyFoo') $obj instanceof MyFoo) { }
which is definitely uglier than
if(is_a($obj, 'MyFoo')) {}
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to PHP5.1 and Apache 2.2 next year, need help
On Aug 9, 2005, at 3:12 PM, steve roussey wrote: On 8/8/05, Rasmus Lerdorf [EMAIL PROTECTED] wrote: 3. Problems with thread-safety of modules You missed the most serious one. Thread safety problems in random libraries you link in and we have absolutely no control over those. OK, I am confused. I always thought (an assumption with nothing to back it up, now that I think about it) that the core part of PHP was thread safe and that it was the third party libraries included from _extensions_ that were at issue. So if I used mysqli then it was at the mercy of the mysql library. So if the mysqli maintainer knew that that library was safe and their extension was safe then they could mark it as safe. All others would go through a single mutex, etc... But if PHP core uses a library and has no idea if it is safe or not (like glibc, though would run under such a system?) then I get your point. I hadn't considered it before. I suppose that is why MySQL statically links in such things that it knows works, not leaving anything to chance. This can affect you even if you're not statically linked. Dynamically loaded libraries run in your address space and have the same ability to mess you up as statically linked libraries. Otherwise your understanding is spot-on. Here there be dragons. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GCOV
On Aug 9, 2005, at 4:55 PM, Wez Furlong wrote: JFYI: -o doesn't work on all versions of re2c Since when has PHP been concerned about not requiring the most-most recent version of a library, let alone a development tool? George still sore about having to upgrade libxml2 every couple weeks --Wez. On 8/9/05, Nuno Lopes [EMAIL PROTECTED] wrote: Hi, I've already had a change to test your patch (I've even have asked my university for a server to put ithe reports on-line). I've also came into this issue, which happens because re2c is called in the wrong way (the output is printed to stdout, rather than directly to the file). Those files should be generated with 're2c -b -o output_file.c in_file.re'. (also: re2c should be called from the directory where the in_file.re is, so that it uses relatives paths) Conclusion, you just need to regenerate the parsers correctly. BTW, there was an error in your patch: it cleans the *.gcno files (which are generated at compile time) in cov_gen_clean() before running lcov, thus breaking the proccess. Nuno - Original Message - From: John Coggeshall [EMAIL PROTECTED] To: internals@lists.php.net Sent: Tuesday, August 09, 2005 9:38 PM Subject: [PHP-DEV] GCOV Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. The changes are relatively minor and I've already run it past Andi. I'm trying to get around one last problem that maybe someone else can take care of: The basic issue is that our parsers have broken file/line preprocessor directives... since we're pre-generating these files and then committing them, things like #file and #line are breaking gcov because it's using them to look for source and the paths are from whomever committed them to begin with. I spoke with Andi about this at OSCON and we agreed that it's probably best when GCOV is enabled to strip those preprocessor directives out beforehand. Any other thoughts/comments? If no one has a better solution I'll commit the code later today. John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php George Schlossnagle -- Vice President of Engineering -- OmniTI Computer Consulting -- http://www.omniti.com
Re: [PHP-DEV] Re: PHP Unicode support design document
On Aug 10, 2005, at 10:30 AM, Rasmus Lerdorf wrote: Yeah, print/echo was just a way of describing the underlying output stuff. It wasn't meant to be taken literally. Given the __toString fiasco, it's understandable that this would be confusing though. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 12, 2005, at 1:48 PM, Rasmus Lerdorf wrote: Since we are breaking a lot of stuff in 6.0, at least with Unicode_semantics=On I am wondering if it may not be time to break some more stuff and do a bit of spring cleaning. It would mean many apps would need some work to work on PHP 6, but at the same time I think it is work people would welcome since it would mostly involve removing hacks instead of adding them. And yes, I know this is pretty controversial, so take a few deep breaths before replying, please. 1. Remove register_globals completely +1 2. Remove magic_quotes_* +1 3. Add input filter extension which will include a mechanism for application developers to very easily turn it off which would swap the raw GPC arrays back in case the site had it turned on by default. That seems a bit scary, and almost as if it would defeat the purpose. I'm all for an input filter extension, but it should be one that can't be easily neutered by (potentially malicious) applications. 4. Include an opcode cache by default. A lot of work has gone into pecl/apc recently, but I am not hung up on which one goes in. +1 6. Remove some stuff that has been marked deprecated since PHP 3/4 +1. I agree with Ilia that this should be done on a case-by-case basis. A couple of others that we could consider, but I don't actually think wins us much apart from academic purity (which I have never been all that keen on) are: 7. Make identifiers case-sensitive +1 9. Radically change all the operator syntaxes. Oh wait, that's Perl 6.0, sorry. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 12, 2005, at 2:19 PM, Derick Rethans wrote: On Fri, 12 Aug 2005, George Schlossnagle wrote: 3. Add input filter extension which will include a mechanism for application developers to very easily turn it off which would swap the raw GPC arrays back in case the site had it turned on by default. That seems a bit scary, and almost as if it would defeat the purpose. I'm all for an input filter extension, but it should be one that can't be easily neutered by (potentially malicious) applications. I wrote up the following spec for this extension: http://files.derickrethans.nl/filter_extension.html Where's the part about an application swapping back for the raw arrays (as opposed to accessing them specifically as _RAW_GET or whatever)? Or are you and Rasmus talking about two different proposals? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 13, 2005, at 2:29 AM, Ilia Alshanetsky wrote: Marcus Boerger wrote: 9. __toString) everywhere, but i already said i'll take care of that unless i am being held back. So now go for that or live with the fact that php is meant to generate html pages which is text output. Thus sooner or later your objects create text simplifying that aas much as possible is at least to me mor ethan welcome. +1. Either that or just drop __toString altogether. Right now it's about worse than useless, as it's hard to understand exactly when it will and won't be called. 10. namespace support (we are telling everyone php is ready for the big soup. In those scenarios you often find big teams and any help allowing things like dedicated responisbilities and preventing communication problems is more then welcome.) -1 before, -1 still. A big +1 for namespaces, -1 for namespacing existing internal functions (or somehow importing them by default so that they can be referenced by their current name. 13. eventually cleanup parameter order. Guys who knows in which functions the needle is first or second? My solution is to look up every function always which is a bit inefficient. I know the param order in c/C++ and sometimes in java but in php storing that info is impossible and useless so far. -1 -1 George
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 13, 2005, at 5:08 AM, Ondrej Ivanič wrote: 9. Shared memory storage for variables with transparent access. (superglobal array?) -1. This is hard to make consistent across all platforms, and will break instantly when you go past 1 machine, making it confusing and of marginal usage. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 13, 2005, at 8:14 AM, Derick Rethans wrote: On Fri, 12 Aug 2005, George Schlossnagle wrote: I wrote up the following spec for this extension: http://files.derickrethans.nl/filter_extension.html Where's the part about an application swapping back for the raw arrays (as opposed to accessing them specifically as _RAW_GET or whatever)? Or are you and Rasmus talking about two different proposals? Nah, we discussed this thing for a bit, but I didn't add that function yet to this RFC. Good. That function would be evil (imho). Given that you can't access super-globals as variable-variables, I think that having to really get at _RAW_GET[] will make it much more transparent when an application is using unfiltered data. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 13, 2005, at 8:19 AM, Derick Rethans wrote: On Fri, 12 Aug 2005, steve roussey wrote: 4. Include an opcode cache by default. A lot of work has gone into pecl/apc recently, but I am not hung up on which one goes in. I have no karma to +1, but would if I could. It would be wonderful if something like xdebug could profile with op code cache on as well, should it be possible. :) Technically it's possible I guess. Just no time to do it :) I had this working with apc and apd. If any opcode cache goes into the core, I'll happily work out interoperation with all the profilers. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 13, 2005, at 3:21 PM, Derick Rethans wrote: On Sat, 13 Aug 2005, George Schlossnagle wrote: Good. That function would be evil (imho). Given that you can't access super-globals as variable-variables, I think that having to really get at _RAW_GET[] will make it much more transparent when an application is using unfiltered data. But then everybody will just start using $_RAW_GET instead of $_GET. What will that solve? No... reasonable people will use _GET. Applications that need to use _RAW_GET will do so, and (due to the lack of variable variables support for it) be easy to track down. With a function it's much harder to track when you're getting the filtered attay or the raw array. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 6.0 Wishlist
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider [EMAIL PROTECTED] :
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using this in our production system ;-) :
foo('id' = 42, 'name' = foo);
+1 -- this is one of the biggest things I miss coming from perl to
PHP.
Huh? Perl doesn't have true support for this anyway, just a simpler
syntax for hashrefs. If you want Perlish named params this is 100%
identical to doing
foo(array('id' = 42, 'name' = 'foo'));
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 6.0 Wishlist
On Aug 13, 2005, at 5:49 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider [EMAIL PROTECTED] :
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using this in our production
system ;-) :
foo('id' = 42, 'name' = foo);
+1 -- this is one of the biggest things I miss coming from perl
to PHP.
Huh? Perl doesn't have true support for this anyway, just a
simpler syntax for hashrefs. If you want Perlish named params
this is 100% identical to doing
foo(array('id' = 42, 'name' = 'foo'));
George
Well, this idea I think comes from Python. Last time I checked they
had these
and as far as I remember this have been brought 2 times. The first
time before
5.0 and has been rescheduled for 6.0 :)
:)
I'm not against named parameters. Python's support for them is nice
as well. But Perl doesn't support named parameters any different
than can be done currently in PHP.
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 6.0 Wishlist
On Aug 13, 2005, at 5:57 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 5:49 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider [EMAIL PROTECTED] :
9. Named parameters. Preferred way would be via array()-less
array
collation as we are already using this in our production
system ;-) :
foo('id' = 42, 'name' = foo);
+1 -- this is one of the biggest things I miss coming from
perl to PHP.
Huh? Perl doesn't have true support for this anyway, just a
simpler syntax for hashrefs. If you want Perlish named params
this is 100% identical to doing
foo(array('id' = 42, 'name' = 'foo'));
George
Well, this idea I think comes from Python. Last time I checked
they had these
and as far as I remember this have been brought 2 times. The
first time before
5.0 and has been rescheduled for 6.0 :)
:)
I'm not against named parameters. Python's support for them is
nice as well. But Perl doesn't support named parameters any
different than can be done currently in PHP.
George
I could be wrong, but I think you were the one who first wanted
named parameters
that long time ago :)
Possibly, which would fall inline with not being against them now. :)
I like them in Python. The ones in Perl are a hack, though, with
limitations on how they can be positioned, lack of prototyping and
default values, etc. The Python ones are much more flexible, imho.
The only difference between Perl's support for named params and PHP's
current support is that in Perl:
foo( a = 1, b = 2) is the same as foo((a = 1, b = 2)), i.e. that
you have in Perl:
(a = 1, b = 2)
whereas in PHP we have
array('a' = 1, 'b' = 2);
Andrey
George Schlossnagle
-- Vice President of Engineering
-- OmniTI Computer Consulting
-- http://www.omniti.com
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 13, 2005, at 9:06 PM, Jani Taskinen wrote: On Sat, 13 Aug 2005, George Schlossnagle wrote: On Aug 13, 2005, at 5:08 AM, Ondrej Ivani wrote: 9. Shared memory storage for variables with transparent access. (superglobal array?) -1. This is hard to make consistent across all platforms, and will break instantly when you go past 1 machine, making it confusing and of marginal usage. Maybe this could be something that ext/session could provide. I sure can find some uses for a 'global session'. That seems like a reasonable to go. I question it's utility a bit - how often is this really useful? For large objects (like a real cache), this isn't the best place to store it, for most resources it won't work at all. So what's a typical use case for this? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 14, 2005, at 1:08 PM, Lukas Smith wrote: As for removing register globals, a simple auto prepend will get you register globals back, same goes for magic quotes. But moving this stuff into userland will force people to take another hard look at their code. Also a good thing for PHP_Compat. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 14, 2005, at 1:24 PM, Al Baker wrote: An embedded opcode cache I think is also essential and the surrounding $_MEMORY sounds perfect to me. All Java guys (yeah I know PHP != Java) say PHP isn't ready for the enterprise because it can't share information between processes other than arcane sessions. The use of name calling and other ad hominem attacks usually indicate that someone has already lost the argument. Not that you're doing this -- I'm referring to critiques of PHP's session facility by Java folks that amount to calling it arcane, hackish of whatever. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 15, 2005, at 5:05 AM, Zeev Suraski wrote: That's an excellent response. If one percent of the energy put into the 'yay parade' and the 'let's break this too!' parade were invested in coming up with a clean upgrade path, I wouldn't have had to write the response I wrote. Would it be productive to compile a list of wants, then to agree that allowing BC/ensuring a good migration path will be a criteria by which these wants will be vetted? I agree that ensuring a migration path is critical. Wez and I were discussing this in the car this morning, and short of magic_quoutes_runtime, they all seemed like they were straightforward to handle through am include (except for the parameter order thing, but that's an awful awful idea). George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 15, 2005, at 2:29 AM, Jani Taskinen wrote:
On Sun, 14 Aug 2005, George Schlossnagle wrote:
On Aug 14, 2005, at 3:37 PM, Jani Taskinen wrote:
On Sun, 14 Aug 2005, Ilia Alshanetsky wrote:
If apc comes bundled then it includes apc_store() and apc_fetch
() this
is pretty much $_MEMORY with a few tweaks.
Yes, but that is restricted to one server installations.
I need such a 'global session' that is available with multiple
front-end servers..ie. using DB as session storage.
ext/session has the framework for doing this. I concur with your
original idea of augmenting it to provide those services. Perhaps
a new autoglobal $_GLOBAL_SESSION[]. Thoughts?
?php
the usual pre-session_start() things here..
session_set_application_id('someid');
Why shouldn't this be implicit (and bound to a userid under safe
mode). i.e. what's the point of having an application id?
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 15, 2005, at 10:18 AM, Zeev Suraski wrote: I agree that ensuring a migration path is critical. Wez and I were discussing this in the car this morning, and short of magic_quoutes_runtime, they all seemed like they were straightforward to handle through am include (except for the parameter order thing, but that's an awful awful idea). Where does using case sensitive identifiers fall? In my opinion? It's a huge BC break, and one that would be impossible without a ... feature request N) A global __call() method that handles any call to undefined functions. Similar in concept to registering a main::AUTOLOAD in Perl. I personally think this would be both useful and evil for all the same reasons that AUTOLOAD is both useful and evil in Perl. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 15, 2005, at 11:38 AM, Zeev Suraski wrote: (*) Based on the fact php-general@ has 787 subscribers and current estimates at the amount of PHP developers worldwide range between 500,000 to 2,000,000 developers. I actually got the opening number wrong - it's 99.84%, not 98.5%. Sorry. You're probably being glib, but I don't think that being a dedicated, professional PHP developer has much to do with being on any of the lists. Most of the people I know who do serious work in PHP subscribe to none of the lists.php.net lists. It's probably not the best place to catch the pulse of the user-base. If anything, I'd assume that your own pro-services group and consulting partners would have better insight into what people are doing with PHP. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 15, 2005, at 11:52 AM, Zeev Suraski wrote: That's exactly what I was saying (in another part of the email). It doesn't work in reverse order though - being on one of these lists does usually mean that the developer is more 'hardcore' than others. Have you seen Harold and Kumar Go To WhiteCastle? 'hardcore' here reminds me of the 'extreme' guys from that movie. If you don't know the reference, I'm basically saying that being a 'hardcore' is often equivalent with being loud more than anything else. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Aug 15, 2005, at 2:52 PM, sebastian wrote:
W4: Better lambda/anonymous functions and debugging for them.
Consider Perl's anonymous functions which disappear as the
references to them disappear. See the create_function() docs for
notes about memory leaks.
Well, Perl subroutines are first class objects, while PHP functions
are not. That having been said, one of the number one things I miss
from perl is being able to say:
$sub = { ... };
The nice part is that you don't need to do wacky escaping inside the
text for the function. It would be swell for PHP to support:
$func = function ($a,$b,$c) {
// ...
}
and also require no escaping (even while using the existing
create_function symbol table storage semantics).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simplexml and xml namespaces
On Aug 18, 2005, at 10:43 PM, Rasmus Lerdorf wrote:
Or, alternatively, have a separate arrays:
[title]=
array(2) {
[0] = string(6) Title1
[1] = string(6) Title2
}
[media:title]=string(11) Media Title
The latter is actually what I was (naiively) expecting.
I think this latter one is bad. The local prefix is local, and I
think it's broken to have it show up in a parsing of the document. I
agree the current namespace handling is really frustrating, but I
don't think this is a good solution.
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 6.0 Wishlist
On Aug 22, 2005, at 2:08 PM, Stanislav Malyshev wrote:
MB * Anonymous functions. The real stuff, not just some odd string
MB passed to create_function().
MB
MBThere were some others already asking for this, maybe we should
at least
MBgive it a thought if it is doable at all, anybody?
Just out of curiosity, what's bad in create_function and how real
ones
should be different?
Two major differences as I see it:
1) syntactical: the amount of escaping/funkyjunk you need to do to
have anonymous functions look like regular functions in their
declaration is huge (yes, you can use heredocs, but they have their
(big if you run up against them) limitations as well).
2) no garbage collection on them (so in something like perl, when you
anonymous sub goes out of scope, it's cleaned up).
3) runtime vs. compiletime definition
For me 3 is good the way it is (the whole point of anon. functions
(for me) is to allow me to easily vary their definition at runtime).
2 I can see being a pain, but I don't consider it critical.
1 keeps me from using create_function - the required code is to
obtuse to use in most cases - I really would like to be able to do:
$max = function ($a, $b) {
return $a $b?$b:$a;
}
(for why heredocs suck here, consider the case where I want to use
constants in the definition).
George
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
George Schlossnagle
-- Vice President of Engineering
-- OmniTI Computer Consulting
-- http://www.omniti.com
Re: [PHP-DEV] type hinting throwing a fatal error
On Aug 22, 2005, at 3:50 PM, Zeev Suraski wrote: At 20:53 22/08/2005, Marcus Boerger wrote: So in that case, the implementation in zend_error_cb() should simply call the user error handler if it's available, or treat it as if it's E_ERROR if there is no user error handler. Isn't an E_ERROR by default good enough or do you want exceptions here always? I'm not sure what happened, but I don't want exceptions at all, let alone always :) In the former case it might be better to have a new error level E_HINT. In the latter case maybe it might be a good idea to move the default exceptions from ext/spl to the engine and have a 'Hint' whatever exception class derived from RunTimeException. One of us is missing something, or we're not talking about the same thing at all. I'm talking about allowing type hints to be trappable by users, without complicating them with exceptions. I'm proposing a new error level, which behaves like E_ERROR, except it can be caught using a userland error handler, for those cases where the engine/ PHP are in a stable state. This sounds good to me. We talked about this briefly a year or so ago, in reference to being able to convert E_ERROR errors to exceptions in an extension. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Aug 22, 2005, at 4:02 PM, Derick Rethans wrote: On Mon, 22 Aug 2005, George Schlossnagle wrote: I'm talking about allowing type hints to be trappable by users, without complicating them with exceptions. I'm proposing a new error level, which behaves like E_ERROR, except it can be caught using a userland error handler, for those cases where the engine/PHP are in a stable state. This sounds good to me. We talked about this briefly a year or so ago, in reference to being able to convert E_ERROR errors to exceptions in an extension. Right, my current patch allows you do to that for the new E_CATCHABLE error. I don't like the name though, so we need to come up with a better one (sorry Zeev :) . My original proposal (at least as I recall it), was to move irrecoverable errors to something like E_UNRECOVERABLE_ERROR or E_FATAL Leaving current errors as E_ERROR (since most are recoverable, imho) George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] omitting T_CLOSE_TAG
On Aug 29, 2005, at 2:38 PM, Gabor Hojtsy wrote: Hi, I am searching for some evidence in the PHP source code that the possibility of omitting the closing PHP tag is absolutely intentional, and in fact part of the language syntax, and therefore it is going to be supported indefinitely. Digging for T_CLOSE_TAG and similar stuff have lead me to nothing. Actually I would like to clarify and possibly extend the note on page: http://php.net/manual/en/basic-syntax.instruction-separation Also if you have any positive notes on not using the closing tag (or any negative thereof :), please do let me know. Benefit: No unintentional leakage of whitespace (following a closing ? ). George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bogusing bot (Was: [PHP-DEV] Reference handlingchange and PHP 4.4.0)
On Sep 15, 2005, at 9:21 AM, Leigh Makewell wrote: If you don't know why it's wrong to tell them they are stupid, and can't be bother spending an extra 10 seconds formulating a respectable response instead, then you are the wrong person for the job. A cursory survey of the bugs db suggests that you've resolved zero bugs, and filed one (which was resolved, successfully, by Derick). There aren't people lining up to take Jani's position - I can guarantee that if you want to dedicate a couple hours of every day to resolving bugs that there will be ample work to fill your time (and you'ld earn the appreciation of many folks). George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] timezones date() breakage
On Sep 28, 2005, at 8:54 AM, Derick Rethans wrote: On Wed, 28 Sep 2005, Steph wrote: This is probably a stupid question, but why isn't there a default setting? And why can't the missing default setting be set by the system date () data? That's exactly what I was trying to do, except the fall back abbreviations (IDT) didn't all link to timezone IDs yet (Asia/ Tel_Aviv). Carrying on the stupid questions: Is it possible to make a better 'guess' in the case that there are name-collisions or missing names and no ini setting is set? Perhaps something like determining the current offset from UTC and just choosing the first matching timezone (as well as throwing a E_STRICT error). George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] timezones date() breakage
On Sep 28, 2005, at 12:46 PM, Derick Rethans wrote: On Wed, 28 Sep 2005, George Schlossnagle wrote: Carrying on the stupid questions: Is it possible to make a better 'guess' in the case that there are name-collisions or missing names and no ini setting is set? Perhaps something like determining the current offset from UTC and just choosing the first matching timezone (as well as throwing a E_STRICT error). Heh, yes - did you read the whole thread yet? :) I've read most of it, though I admit I skimmed some parts. I saw the part about the E_STRICT notice, didn't see the part about improving the guessing, I'll go back and inspect it more closely. :) George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comment on Bug #30153: FATAL erealloc() error when using gzinflate()
On Oct 4, 2005, at 11:50 AM, Tim Nufire wrote: Ramus, Thanks for the response. Unfortunately, I don't have any great ideas on how to patch this and for now have just stopped using gzinflate :-/ Is there a way to reopen bug 30153? That description of this issue is pretty good and, even if the bug is hard to fix, it should still be tracked somewhere You should file a bug against zlib, as it is the library that needs to export these sorts of validation methods. If/when zlib supports this sort of feature, PHP will support it. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Oct 7, 2005, at 5:05 PM, Derick Rethans wrote: On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: Which is why we need the unicode=off switch. I don't think there is any way we can make Unicode PHP as fast as non-Unicode PHP. For people who need Unicode support, Unicode PHP will be faster and easier than any other way for them to get there, but for people who have no need for Unicode it would be really nice to maintain the fast non-Unicode mode. What is wrong with PHP 5.1? People don't *have* to upgrade to the unicode enabled PHP if they don't want to. And it would probably be nice to have that mode for some users, but should that be over our own back with multiple implementations of everything? Are you suggesting that people who don't want unicode should stick with 5.1 for perpetuity? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode Implementation
On Oct 7, 2005, at 5:41 PM, Rasmus Lerdorf wrote: Ilia Alshanetsky wrote: George Schlossnagle wrote: What is wrong with PHP 5.1? People don't *have* to upgrade to the unicode enabled PHP if they don't want to. And it would probably be nice to have that mode for some users, but should that be over our own back with multiple implementations of everything? Are you suggesting that people who don't want unicode should stick with 5.1 for perpetuity? Assuming that 5.1 would be actively maintained and not just for bug fixes, I'd say that is a viable approach. There are plenty of sites that have no use for Unicode as nice as it may be, and much rather retain performance over useless (for them) functionality. So, you are saying that something like the namespace patch would be added between 5.1.2 and 5.1.3, for example? That doesn't make much sense to me. Perhaps we need a separate version fork for the unicode support. I'm thinking one of those nifty unicode glyphs. It could be called 'the language formerly known as PHP'. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are there plans to support Mysql 5 soon?
Oliver Grätz wrote: Do you read the posts you're commenting on? I said there _were_ (there are not anymore) problems with PDO betas on _Windows_ systems (that was a PECL build for PHP 5.0.3). This was not a complaint on anything and I didn't complain then because it was beta and not meant to be used with PHP 5.0.x, it's just to support that it is reasonable for people to ask will it work?. I remember when FreeBSD didn't support ELF binaries. Does that mean that it's reasonable for me to ping the FreeBSD dev list with 'when will you support ELF?' without checking whether or not that support works? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Labeled Breaks (not the G-word)
me 3. goto is good. Wez Furlong wrote: me also On 11/27/05, Edin Kadribasic [EMAIL PROTECTED] wrote: Ilia Alshanetsky wrote: If it comes down to count of +1/-1 about this feature, I am +1 for unrestricted forward/backward jumps and -1 for restricted version. I agree with this. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 2006 OSCON Reminder
Just as a reminder to all interested parties: the submission deadline for 2006 O'Reilly Open Source Convention is coming to a close. All submissions must be in by Monday, February 13th 23:59 PST to be considered. Proposals can be submitted online at http://conferences.oreillynet.com/cs/os2006/create/e_sess/ OSCON is probably my favorite conference of the year; gathering together innovators not only from the PHP community, but all the other major open-source languages as well. This cross-pollination is really exciting and helps advance the state of the art for all projects. If anyone has any questions or problems with the submission process, please feel free to contact me offline. Best, George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dead C Scrolls - Missing Code for Writing New Extensions without recompiling PHP
Andrew Mather wrote: i)a walkthrough of the exact steps + sample code to write an extension without requiring re-compilation of Php and without access to Php source code ii) as above but with access to Php source code You're clearly missing the -devel RPM that installs the necessary header files to allow you to build extensions outside of a source tree. That devel rpm will install the phpize and php-config executables, and a set of headers under the appropriate destination for your distro (I'm not a SuSE user, but I would expect them to be either under /usr/include/php or /usr/local/include/php). If you don't have these then you need to get the RPM that provides them (php-devel or something along those lines) before you can move forward. Look at practically any extension in PECL and read it's INSTALL instructions. For instance, look at APC and read it's INSTALL file. Again, without the -devel RPM that provides your necessary headers you will be up th creek. iii) as above (either i or ii) but with instructions to allow the project to be initiated and compiled within the KDE development environment That shouldn't make any difference. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Embedded
Sara Golemon wrote: Originally George and Wez were going to be writing this book (and may yet do their own version -- that's up to them). Due to innocuous reasons that I can probably talk about but won't to be on the safe side, I wound up taking over the project (and the ISBN number along with it). I heard it was because those guys were total slackers. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [SOAP] In-memory WSDL cache for ext/soap
Michael Rasmussen wrote: On Wed, 19 Apr 2006 13:52:13 -0400, Adam Maccabee Trachtenberg wrote: Not if you think the improvements will break the code base because you don't have time to do sufficient testing. I would prefer to avoid regressions in minor releases and would like to use the longer 5.2 beta period for testing. This is a god point. No need to inflate Adam's self-image _that_ much. :) George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 23, 2004, at 6:52 AM, Edin Kadribasic wrote: On Tuesday 23 March 2004 11:58, Georg Richter wrote: I agree with Marcus (and I think Andi) here. If its not too much trouble OO interface to mysqli should IMHO follow the same conventions other OO extensions do, beside changing c-code it's - changing documentation (english, german, spain and french) - changing all samples - changing testcases (incl. ~300 testscripts on my machine) - changing ~200 slides - changing 2 articles and 2 authors told me they don't have a chance to change it anymore in their books, they will be printed these days. I've had stuff (not mysqli) change underneath me in my book. It's annoying, but it's a problem inherent to writing to a moving target. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php5 class initialization
On Mar 23, 2004, at 11:53 AM, Andrei Zmievski wrote: On Mon, 22 Mar 2004, Andi Gutmans wrote: What would you expect? That if a new style constructor is defined we always use that and allow old-style as regular method? Yep. I agree with the part about the new-style constructor always being preferred to the old-style constructor, but besides being really confusing, where do you being able to call the old-style as a regular method coming in handy? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php5 class initialization
On Mar 23, 2004, at 1:11 PM, Rasmus Lerdorf wrote: On Tue, 23 Mar 2004, Brad Fisher wrote: Sure, but George was asking for a case. I think the case where you have some existing PHP4 code that you want to make minimal changes to but you might have a little bit of PHP5-specific code to run in the constructor I could see this sort of chaining being something people want. I am not saying that is the way people should create a portable class, just that I could see such code popping up. And the question was what to do about the old-style constructor method. I think it would be very confusing if it was some sort of illegal method name that wasn't callable. You sold me on the usefulness. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 23, 2004, at 4:30 PM, Andi Gutmans wrote: At 01:24 PM 3/23/2004 -0800, Rasmus Lerdorf wrote: On Tue, 23 Mar 2004, Georg Richter wrote: Changing everything after an announced feature freeze sucks. It's just ignoring others (users, authors and publishers) - a loss of face. Obviously some people like this kind of policy - me not! I do agree with this. There is no point in announcing a freeze if you turn around and change a bunch of fundamental things the next day. If we are really going to go back and change all these method names then I think the correct way to do it is to pull RC1 and let people know that we discovered some things that need to be cleaned up and we will attempt another freeze and RC1 at a later date. Huh? Now you're really going to confuse people. You can always have RC2 and more. As it is there will be enough meat to have an RC2 after bug fixes (things which weren't discovered before more people started testing the RC). Two RC1s would be a clusterfuck. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sqlite's oo api
On Mar 23, 2004, at 6:48 PM, Marcus Boerger wrote: As you know my actings started a long discussion and now i am questioning: Are we following our rules and decisions? And if so which rule/decision do ppl want me to follow? The one i did which potentially hurts some article writers? Or the other one which would lead to a revert and inconsistency? Being concerned about BC before there is an actual release seems silly to me. The whole of PHP5 could be accurately described as 'experimental' atm. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 23, 2004, at 11:21 PM, Adam Maccabee Trachtenberg wrote:
On Tue, 23 Mar 2004, Rasmus Lerdorf wrote:
they are all in sync. For example, Derek Ford's simplexml-related
message
to internals last week(*) worries me somewhat. He passed on what
looks to
be some basic brokeness in the extension which nobody has addressed so
far.
(*) http://news.php.net/article.php?group=php.internalsarticle=8660
Here's my take on these issues:
1: You can't tell if an element exists or not
OK. So I haven't really looked at this code before, but a cursory
inspection leads me to believe that sxe_prop_dim_exists() doesn't work
right at all for elements.
When you come in testing for the existence of $obj-element, node is
set to the xmlNodePtr for $obj (which exists of course). Then you fall
into this case:
if (elements) {
if (Z_TYPE_P(member) == IS_LONG) {
if (sxe-iter.type == SXE_ITER_CHILD) {
node = php_sxe_get_first_node(sxe, node TSRMLS_CC);
}
node = sxe_get_element_by_offset(sxe, Z_LVAL_P(member),
node);
}
if (node) {
exists = 1;
}
}
I don't see where this actually looks up 'element', it seems like it
simply evaluates the existence of node. I committed a fix, but someone
who knows the code better should validate that it is correct.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 24, 2004, at 12:06 AM, George Schlossnagle wrote: I don't see where this actually looks up 'element', it seems like it simply evaluates the existence of node. I committed a fix, but someone who knows the code better should validate that it is correct. btw, is there a bug number for this? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
The middle case of this dude's example raises a separate concern: count() does not work for objects - it will always return 1. For objects that implement the Iterator interface, it seems reasonable for count() to return a non-trivial answer. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 25, 2004, at 9:29 AM, Andi Gutmans wrote: OK Guys. It's decision time. I suggested to move to studlyCaps and keep consistency with the new PHP 5 changes. If we go with this, I think we should make these changes ASAP and try and aim for RC2 within two weeks. Now I understand it's kind of hard to force extension authors to change their own code but as I said in the past it's important to show some responsibility and follow the CODING_STANDARDS even if books/articles and stuff have been published with the old information (it's only function name changes). Marcus has already stepped up and showed his willingness to make many of the needed changes. I didn't author any of the affected code, but I'm happy to help affect this change. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 26, 2004, at 9:16 AM, Ilia Alshanetsky wrote: I should also mention that majority, if not all of the users whom I spoke to at the Montreal conference seem to prefer to have PHP stick to a single naming convention that they are familiar with rather then use 2 distinct naming conventions. They were even able to raise some valid points we had not previously considered. For example it appears that it is quite common for people to use studlyCaps syntax to naming their own functions/methods, which allows them to easily distinguish between native PHP functions methods and the ones they wrote themselves. The StudlyCaps standard only applies inside OO code, so I see this as much less of an issue (certainly no worries of conflicts). In case it's not obvious, I'm +1 for StudlyCaps. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 26, 2004, at 9:38 AM, Ilia Alshanetsky wrote: On March 26, 2004 09:35 am, you wrote: So one would inherit from/extend a native class and then use studlyCaps and call underscore style methods from parent class. Can you imagine how ugly would this look? It may look ugly, but without a doubt it would be very clear which code is 'user' and which is 'PHP'. Ugliness in general makes code difficult to read, in this case (IMO) it actually makes the situation a little clearer. As Edin and Lukas have both pointed out, one of the major precepts of OO programming is that you can (and often do) overload methods in your parent. Adopting two different styles really doesn't work if you ever want to use any of the in-core classes, as it will force your own code to adopt both notions. In fact, the argument that people use StudlyCaps in their own code is precisely why it should be adopted in OO code, so that overloading won't result in a mishmash of styles. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 26, 2004, at 10:30 AM, Stefan Walk wrote: On Fri, Mar 26, 2004 at 07:05:15AM -0800, Rasmus Lerdorf wrote: On Fri, 26 Mar 2004, Stefan Walk wrote: Oh, and the strpos/str_repeat inconsistency should be 'fixed' too, maybe make strpos an alias to str_pos or alike... So you are saying strlen() should be str_len() as well? If I ever see a patch to change that I'll hunt the person down and make them swallow an entire KR C book. -Rasmus Well, C is consistent in that it doesn't use underscores there. If no underscores at all would be used, i wouldn't complain either. But the way it is now is inconsistent... and using a different naming convention for member functions a.k.a. methods introduces new inconsistency. I know that it's not possible to kill all existing inconsistencies, but why introduce new ones? No one is discussing changing the names of these functions. The standard being discussed is specifically limited to OO code, so please stop trying to take this discussion astray with such strawman arguments. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reload() in Python, Possible in PHP?
On Mar 28, 2004, at 4:36 PM, Jon Parise wrote: On Sun, Mar 28, 2004 at 03:57:22PM -0500, Andrew Heebner wrote: AFAIK, Python supports the reload() method, which lets you dynamically control includes while a script is running. This is conceptually easier to implement in Python because a module is its own namespace. In PHP, the stuff that is included from another file has no such common organization. In PHP, even workarounds are tough to create reloadable modules for scripts, so, what other means are there to reload includes, and redeclare functions? If it's not already safe to include() your file multiple times, I don't think adding a reload() function to PHP is going to improve your situation all that much. The engine would have to do a fair amount of work to figure out how to reload the contents of the external script. You can do this easily enough in an extension. Combine the function/class tracking stuff that APC performs and internally use the overide_function() function from APD. Obviously that would require a bit of glue to get it working, but the primitive facilities are all there. I don't see any of that ever making it's way into PHP proper though. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault in HEAD
On Mar 31, 2004, at 1:17 PM, Sterling Hughes wrote: php5 shouldn't crash _at all_ within an infinite loop because we aren't in one big execution loop. Why shouldn't this crash eventually? You still have to account for all the callers stacks. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC2
On Apr 1, 2004, at 5:58 AM, Lester Caine wrote: Andrey Hristov wrote: Hi, scripts relying on the API of RC1 and before it will be broken (exception are scripts that rely on ext/mysqli). The API is changed (afaik) in : Reflection API ext/sqlite pecl/ffi pecl/soap probably other places. OK so we are talking internal API - which will affect me when I get round to producing a pure Firebird branch of the Interbase module? Rather than the external API - which would mean processing ADOdb, TikiWiki etc. which are all currently stable ( as far as I have found ) with RC1. If those products rely on any of the method names in the above extensions, they will need to account for the name changes. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch to minimize Session Fixation Risks
On Apr 7, 2004, at 10:17 AM, Robert Cummings wrote: On Wed, 2004-04-07 at 09:56, inodes wrote: Hello, The PHP manual says it is the developer's job to ensure PHP sessions cannot be stolen or fixed (this is called Session Fixation). To minimise the risk of session fixation, I wrote a patch for PHP-4.3.5 (I can port it for the other versions too - just ask...), that makes (almost) sure the current user IS the session creator. It is based on client IP addresses. This patch is available at: http://www.trickytools.com/php/sesfixpatch.php If you think this could be useful, it could be improved and someday be part of the official distro. I remember reading in the forums before that using the request IP to fixate a session isn't practical since some ISPs (namely AOL) can have the request IP suddenly change between one request and another. Yes, this behavior is quite common for many of the large ISPs. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] protected __call() question
On Apr 7, 2004, at 9:28 PM, Jochem Maas wrote: maybe its possible for the parser to ignore public/private/protected declarations on __call() ( also __set(), __get()) methods, given PHP forgiving nature/image (at least that is my impression). The whole point of PPP is to not be forgiving or permissive unless you instruct the engine to do so. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch to minimize session fixation (continued)
On Apr 7, 2004, at 9:48 PM, Jochem Maas wrote: Sean Coates wrote: While I like that your patch can be turned on and off in the INI, this sounds much more like an application-level problem, and thus should be implemented at the application level. Loads of people have actually put stuff out that does this... ^ | Other tests could be made: - on the browser headers - on IP ranges rather that on the single client IP address - and so on... What about a scoring system (based on checks on the above and more?), a bit like that which is used in products like spamAssassin, the ini setting could be a threshold value (0 basically meaning attempt no checks and any value 0 = 1 to be reject/accept* threshold). ...anyway the idea of being able to do some kind of sanity check on behalf 'beginners' (no offensive intended) is a nice idea. Advanced users tend to have specific environment requirements (and set them up accordingly) and perform decent checking anyway. All of the above methods have problems with proxy servers. As a robust solution to the problem doesn't exist, people should implement their own non-robust solutions in their own scripts. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 12, 2004, at 10:58 AM, Adam Maccabee Trachtenberg wrote:
On Mon, 12 Apr 2004, Ilia Alshanetsky wrote:
There is 1 problem with this approach. Currently an uncaught
exceptions
results in a fatal error (E_ERROR) meaning that if a particular
method throws
an exceptions it MUST be caught otherwise the script will terminate.
Having
to wrap some methods inside exceptions can be extremely frustrating
since you
may want to allow those methods to fail.
Yes. This sucks. Maybe PHP should only issue exceptions for problems
of E_WARNING severity. An exception is an Exceptional Event. If you
have an E_NOTICE or E_STRICT then that's an informational event, not a
exceptional one.
I'm fine with this, but it's really just a documentation problem,
right? Your method can still fail, you just need to try/catch around
it.
try {
$obj-bornToFail();
}
catch(Exception $e){}
Uglier than just swallowing a warning for sure, but still just a doc
problem.
Either that or uncaught exceptions should be E_WARNINGs instead of
E_ERRORs. (I don't want to introduce Java's checked versus unchecked
exception concept.)
-1.
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 12, 2004, at 1:00 PM, Sterling Hughes wrote:
On Apr 12, 2004, at 8:50 AM, George Schlossnagle wrote:
On Apr 12, 2004, at 11:42 AM, Sterling Hughes wrote:
I like OO (*), and I think warnings (non-fatal errors) as exceptions
are a stupid idea. Does that count? ;-)
Exceptions in languages like Java are used explicitly to catch fatal
errors, not to catch basic errors.
If 'languages like Java' means languages designed for OO, then this
is not true. Python throws exceptions for almost everything
(KeyError, for example). Even Java throws exceptions
(java.sql.Exception) for things like failed database connections
which are warnings in PHP.
Languages like Java doesn't mean languages designed for OO, but
languages closely adhering to the OO model that PHP uses, Java being
the language that can most easily be called the parent of our current
model - although I do keep Python in this context even after your
KeyError example. The triviality of an exception doesn't make
exceptions themselves less severe. Whether or not a KeyError is
warranted as an E_ERROR, doesn't in fact change that a KeyError will
bump you firmly out of your control flow branch, and make you handle
an error condition. In PHP, E_WARNINGs may be misused (that's a
discussion for another time, i think); but the fact remains, they do
not end your current control flow branch. Changing E_WARNING's to
errors catchable by try{}catch{} will not only break BC, but will not
make sense for a large number of warnings currently thrown for PHP and
lead to the same inconsistencies.
A KeyError is an E_NOTICE in PHP. It's so frequent in loosely typed
languages that it is rarely severe. Your argument is a tautology: the
only reason it breaks control-flow in Python is because it's defined
to break control-flow there by means of it being an exception.
John has gone ahead and committed a perfect example of where
exceptions just mess things up. In the tidy extension if you try and
set an unknown configuration option it throws an exception. This is
not by any stretch of the imagination an unrecoverable error, but
rather a simple failure. Yet, if you use tidy in a script, and it is
not within a try {} catch {} block your script execution will be
terminated because the configuration option could not be resolved.
This is much less than desirable and probably confusing for someone
who doesn't understand what an exception or why he should care.
I don't have a strong feeling about this either way, but to play devils
advocate: You requested an option be set. That option could not be set
because it is impossible to set a non-existent option. How do you know
how someone wants to handle that error?
You might argue that python or java would throw an exception in this
case. For the majority of the java standard library and python code i
have found this the opposite, however, even conceding that, PHP should
never do this. We have the concept of warnings, in our world an error
of this type does *not* terminate script execution. There are even
less severe usages of warnings throughout the PHP source code, and
there is no reason to convert them to exceptions. And if you don't,
you still have the same inconsistencies.
The discussion was on OO code throwing exceptions. Given that there is
very little OO core code in php4, I don't see a widespread conversion
happening.
Java and Python both use a mix of philosophies, and indeed there is no
complete consensus. However, in my experience and the books that I've
read on the subject, the general thought is:
a) throw specific exceptions, not just a tidy_exception. PHP would
need to add a library of built-in exceptions to make this even
remotely useful. this is not feasible to do at RC1.6667
But the beauty of OO Code is that all the tidy exceptions should derive
from TidyException. So life can continue as before, with no BC break.
b) don't throw exceptions except when truly exceptional. a function
failing is usually not an exception, but rather signified by failure.
The exception to this is when using constructors that contain logic
(considered bad practice by many btw), and overloading. In these
cases exceptions are used in leu of a better solution. This brings us
back to KeyError - KeyError is only thrown when overloading is used:
names = [barney, fred, wilma]
print names[betty] # throws an exception
print names.get(betty) # returns None
You'll have a hard time defending Python as being restrained in it's
use of exceptions for warnings. It's a rather exception-happy langugae
and throws exceptions for the equivalent of most PHP E_NOTICEs.
Most of the exceptions i've found when using both these languages
happen on something that maps to something more severe than a
configuration option not being found. YMMV.
The key point that you're missing in all this is that _you_ don't know
what's a serious error and what's not. Only the developer knows
Re: [PHP-DEV] Exceptions and Errors
On Apr 12, 2004, at 1:21 PM, Pierre-Alain Joye wrote: On Mon, 12 Apr 2004 13:18:51 -0400 [EMAIL PROTECTED] (John Coggeshall) wrote: snip Again, we are talking about a very specific situation (PHP 5 extensions written using a dual-syntax model).Things in the PHP 4 branch are not an issue here, there is no expectation that such things would be changed. We may keep in mind that a specific (or rare) situations now will certainly be a not so rare situation in a near future. When PHP5 is out and people start to create php5 only extensions (thinking that the internal API will then really be freezed). That's why this discussion is happening now. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 12, 2004, at 2:14 PM, Sterling Hughes wrote:
John has gone ahead and committed a perfect example of where
exceptions just mess things up. In the tidy extension if you try
and set an unknown configuration option it throws an exception.
This is not by any stretch of the imagination an unrecoverable
error, but rather a simple failure. Yet, if you use tidy in a
script, and it is not within a try {} catch {} block your script
execution will be terminated because the configuration option could
not be resolved. This is much less than desirable and probably
confusing for someone who doesn't understand what an exception or
why he should care.
I don't have a strong feeling about this either way, but to play
devils advocate: You requested an option be set. That option could
not be set because it is impossible to set a non-existent option.
How do you know how someone wants to handle that error?
I assume they don't want their script to stop executing, their
transactions to be rolled back and a nasty error page shown :
Uncaught exception, could not set tabsize to 2 spaces
That could just be my crazy assumption though.
It is. It's a hardocded portion of their app, and they made a mistake.
They may not care, but it's also possible that they do. Assuming that
they don't care enough to fix it seems equally crazy to me.
You might argue that python or java would throw an exception in this
case. For the majority of the java standard library and python code
i have found this the opposite, however, even conceding that, PHP
should never do this. We have the concept of warnings, in our world
an error of this type does *not* terminate script execution. There
are even less severe usages of warnings throughout the PHP source
code, and there is no reason to convert them to exceptions. And if
you don't, you still have the same inconsistencies.
The discussion was on OO code throwing exceptions. Given that there
is very little OO core code in php4, I don't see a widespread
conversion happening.
No, this discussion was on having exceptions thrown instead of
E_WARNINGs inside OO code.
Rewind to the beginning of the discussion, the scope is not as broad as
you claim.
I'm pointing out that the two paradigms don't map, and in other
languages for many of the common errors given by E_WARNINGs (but not
all) simply wouldn't propagate as Exceptions. Many cases it would,
but in order for this idea to work, it needs to map for the most part,
which it doesn't.
[snip]
You'll have a hard time defending Python as being restrained in it's
use of exceptions for warnings. It's a rather exception-happy
langugae and throws exceptions for the equivalent of most PHP
E_NOTICEs.
I haven't noticed that, and I've written quite a bit python code. It
does throw exceptions, no argument, but it depends largely on what you
are doing. The above example you've given is a place where an
exception is not out of place (although I don't particularly like one
being thrown), because you are using an overload. Different paradigm
than PHP arrays imho.
Most of the exceptions i've found when using both these languages
happen on something that maps to something more severe than a
configuration option not being found. YMMV.
The key point that you're missing in all this is that _you_ don't
know what's a serious error and what's not. Only the developer
knows. For instance, the python smtplib can throw any number of
exceptions based on bad connect data or bad command responses. Is
this a 'serious' error? It depends. If sending a mail is an
inconsequential part of the app, maybe it's just an informational
warning. It's also easy to imagine it being a very critical,
non-recoverable error. The severity of the error lies entirely in
the purview of the receiver.
Nothing sums this up for me better than KeyError, which is almost
never fatal in my applications but which constantly bites me in the
ass. Obviously your experiences may differ, which is really the
whole point.
Well, you can use get() now and be happy. :)
I could, I could also catch my exceptions. There are plenty of other
exceptions (casting errors, etc) that will irk me whenever I use
Python.
I'm not saying that exceptions should never be used. But, John
suggested As a matter of consistency, I would like to suggest that
for those extensions which have a OO/procedural syntax that the
non-fatal errors
generated by those extensions be thrown as Exceptions when called from
an OO syntax.
I'm undecided on whether it's advisable to throw E_WARNINGs as
exceptions. I think that all but engine-consistency-affecting E_ERRORs
should be exceptions, but that's a different discussion.
Either i'm missing the point or we are agreeing this shouldn't be so.
You were saying that not doing this was consistent with other
languages. I was saying that it was not.
George
--
PHP Internals - PHP Runtime Development Mailing List
To
Re: [PHP-DEV] Exceptions and Errors
On Apr 12, 2004, at 3:06 PM, Sterling Hughes wrote: It is. It's a hardocded portion of their app, and they made a mistake. They may not care, but it's also possible that they do. Assuming that they don't care enough to fix it seems equally crazy to me. Could be a version mismatch with tidy, and a newer library. They develop there code, the option exists, and then someone with an older version of the library doesn't have that. Whether or not i have 4 spaces or 2 in my output is rather inconsequential. Now you deploy somewhere else and this explodes somewhere within a function and bumps the script out of a critical execution context and refuses to work. Setting an option has semantic meaning. Whitespace has no semantic meaning in PHP. These are apples and oranges. Rewind to the beginning of the discussion, the scope is not as broad as you claim. I did. fast-forward to the end of this message, that's exactly the point john brought up. He's talking about all E_WARNINGs in an OO context, not in an OO extension. I could, I could also catch my exceptions. There are plenty of other exceptions (casting errors, etc) that will irk me whenever I use Python. I've probably written a considerably large amount of python and I haven't run into this rampant exception problem you talk about. Could also be the reason why I like Python more than you... ;) It makes sense that overloads would cause exceptions, as it does with type casting exceptions - remember, python is a strongly typed language, that type schiznizzle is important to them. I'm not arguing whether it's important to them. I'm arguing that things that are not important to my app generate exceptions in Python. Something can be important in a language but not important to my app. Either i'm missing the point or we are agreeing this shouldn't be so. You were saying that not doing this was consistent with other languages. I was saying that it was not. Ok, then we disagree. I think its entirely inconsistent because the two systems don't map to each other, and you get plenty of cases where the two simply don't map. John is talking about *all* E_WARNINGs in OO code, and in the procedural variants, sending E_WARNINGs. The scope of E_WARNING is not in my opinion the same scope as an exception in any language, and we may just have to agree to disagree. The not-mapping issue is a serious one. PHP's procedural error-handling does not map well to Java or Python. PHP's OO error-handling can. The former can't change, the latter can. I don't think there's a clean answer. And before I incur a rant from Sascha about how I ramble endlessly without point, I'll resign from this argument. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 13, 2004, at 4:16 PM, Adam Maccabee Trachtenberg wrote: On Tue, 13 Apr 2004, Marcus Boerger wrote: Hello Marcus -- This brings us back to an old problem the severity levels are inconsistent. And further more we decided some time back that E_ERRORs shouldn't be converted to exceptions because of a few E_ERRORs that might not be continuable. From my point of view we should do two things: 1) convert the non continuable E_ERRORs to a higher severity (if there are any at all) Is there a reason not to move non-continuable E_ERRORs to E_WARNINGs? This prevents us from adding another severity level and also allows us to make all E_ERRORs fatal in the process. This is a huge bc break. Raising the severity on non-continuable errors and throwing exceptions for E_ERRORs produces no bc issues. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 13, 2004, at 4:52 PM, Adam Maccabee Trachtenberg wrote: I guess I'm confused about why some E_ERRORs are now able to be handled in userland, but only by using exceptions. It's important to note that this is now technically feasible but not (yet) part of PHP. (You can actually do it as an extension though. :) If these types of errors are now recoverable, shouldn't we let the programmer decide how they want to handle them? You could, but you'ld break existing scripts that rely on E_ERROR being fatal in PHP4-ish code. Since exceptions don't exist in PHP4, using them to avoid previously fatal errors doesn't alter any existing behavior. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 13, 2004, at 5:18 PM, Adam Maccabee Trachtenberg wrote: On Tue, 13 Apr 2004, George Schlossnagle wrote: On Apr 13, 2004, at 4:52 PM, Adam Maccabee Trachtenberg wrote: I guess I'm confused about why some E_ERRORs are now able to be handled in userland, but only by using exceptions. It's important to note that this is now technically feasible but not (yet) part of PHP. (You can actually do it as an extension though. :) Okay, so it's just an unenabled feature, not an impossible one. :) Uncommitted, technically. I have a patch against an old ZE2 build lying around and the extension version is in chap 23 of my book. For the type of error in question consider this: ?php $a = array() + 1; ? this is fatal in PHP, but can be completely recoverable from an engine-consistency standpoint. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 13, 2004, at 5:50 PM, David Sklar wrote: George Schlossnagle wrote: ?php $a = array() + 1; ? This doesn't print Brray or maybe Arraz? :) Not even in Perl. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 15, 2004, at 8:28 AM, Christian Schneider wrote: No, I dislike them because they create more problems than they solve. Then don't use them. You're a bit late to the party to debate their existence in the language. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 15, 2004, at 9:49 AM, Jani Taskinen wrote: On Thu, 15 Apr 2004, George Schlossnagle wrote: On Apr 15, 2004, at 8:28 AM, Christian Schneider wrote: No, I dislike them because they create more problems than they solve. Then don't use them. You're a bit late to the party to debate their But if some extension (e.g. sqlite) forces you to use them? (yes, I can always use the non-OO-API, but still..) ^ Yep. Or use it in the documented way. I don't see what the flap is about. It's not mysterious. It's doc'd that constructors throw exceptions to signal failures. Refusal to use something in the documented (and standard, as far as other OO-centric languages are concerned) way solicits little sympathy from me. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Construct Request
On Apr 15, 2004, at 3:35 PM, Timm Friebe wrote: On Thu, 2004-04-15 at 21:36, Chuck Hagenbuch wrote: Quoting Hartmut Holzgraefe [EMAIL PROTECTED]: [...] If this were added, wouldn't it make sense to use the convention already adopted by perl? $foo |= 'default'; Already used: $ php -r '$a= 1; $a |= 2; var_dump($a);' int(3) perl's is ||= anyway. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 15, 2004, at 5:21 PM, Marcus Boerger wrote: Hello Christian, Thursday, April 15, 2004, 1:06:20 PM, you wrote: [EMAIL PROTECTED] wrote: modern dynamic languages in that context, as for instance in Python there is no error handling but by using exceptions). Sorry but that's simply wrong. Python methods can return false or null as much as PHP methods can. It might be a lot more _common_ to use exceptions but there are options. And the exception part is the one I don't like about Python anyway ;-) Still a ctor cannot return a value. Supporting this, if you look through the Python standard library you will see that exceptions are the employed method for handling constructor failures. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] ifsetor operator
On Apr 16, 2004, at 5:51 PM, Marcus Boerger wrote: Hello George, thinking twice and rechecking it is a bit more complicated though. NVL in oracle means Null-VaLue or beter 'NULL Value replacement'. We want to replace the non-existing situation with a predefined value which is slightly different. Hence the name should be NEL, NEV or NEVAR for Non-Existing-Value-(Replacement). sorry i had to read my own mail to recognize this fact. Well, oracle doens't really have a non-existing value, so in their language it's the same. The point of the suggestion was to re-use a familiar function name with the semantic meaning (since non-existent values == null in oracle, that's the best you get). To beat a rather dead horse, you can also say it's Non-existing VaLue. :) George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __autoload() and code caching (Was: [PHP-DEV]
On Apr 18, 2004, at 2:24 PM, Marc Richards wrote: Do the pages that get included by the __autoload() function get parsed and compiled along with the original page when using a code cache? No, but since all the code caches cache each include file independently, it doesn't matter. The include (assuming that your __autoload() does an include) will happen, the file will get cached, etc. I assumed that since __autoload gets called at runtime, it would be too late for the caches to do their parsing, optimizing and caching. On the other hand I was under the impression that include()d files get pulled in at compile time and therefore get parsed and cached. The whole point of a compiler cache is that files are included many many times. The compiler cache trys to avoid the compilation on every request after the first. ZE mixes compile and execution stages pretty fluidly (for example, an 'include' is compiled when it's statement is hit during runtime), so the time that __autoload() gets called is pretty orthogonal to a compiler cache's ability to cache things. The things a compiler cache doesn't speed up are eval()'s, because the code to be compiled is dynamic. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
On Apr 19, 2004, at 5:45 PM, George Schlossnagle wrote: On Apr 19, 2004, at 5:37 PM, Christian Schneider wrote: George Schlossnagle wrote: Just to clarify a bit on why I think that we should differentiate: 1. First of all, I agree that in a perfect world we should go with E_COMPILE_ERROR for everything. Maybe now that's constructors are +1 Are you guys serious about a compile error if I override a method with different parameters? This must be the mailing list of a different language than PHP... If you override an interface with a different number of parameters or with incorrectly typed parameters, yes. ^^^ make that read 'implement', of course. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
On Apr 20, 2004, at 3:22 AM, Derick Rethans wrote: On Mon, 19 Apr 2004, Sterling Hughes wrote: mo compile errors mo better. But NOT for normal methods! I agree with Derick. Compile errors for interfaces methods good. Compile errors for normal inherited methods bad. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php // George Schlossnagle // Postal Engine -- http://www.postalengine.com/ // Ecelerity: fastest MTA on earth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
