[PHP-DEV] SVN Account Request: mryaggi
Fix bugs i'm fed up to cope with while developping in PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: mryaggi
Guillaume F wrote: Fix bugs i'm fed up to cope with while developping in PHP. Hi Guillaume, There's some information about contributing to PHP in http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/README.SUBMITTING_PATCH?view=markup It would be great to see you submit some patches. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/ugpomhome -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ereg deprecation?
Hi! I also won't recommend using ereg, I just thought the unique reason to deprecate it was the unicode stuff, hence wouldn't make sense to keep it deprecated... But as there are others motivations, I prefer leave as is too. I think we have enough reasons to keep it deprecated as we have much better alternative (pcre) which we want to recommend to the users. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi! The optional scalar type hinting would raise a catchable fatal error that could be converted to an exception. If you advocate moving PHP to full-OO with exceptions as primary error handling mechanism, it's fine - but there would be nothing optional or hinting about it - once you have one piece of code doing it, you'd have to have all code that touches it (and all code that touches that code, etc.) to be strict typed and exception-controlled. And then you'd want typed variables and throws clause to methods. Maybe we better rename PHP into Java and be done with it? :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Tue, Jun 1, 2010 at 7:55 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! The optional scalar type hinting would raise a catchable fatal error that could be converted to an exception. If you advocate moving PHP to full-OO with exceptions as primary error handling mechanism, it's fine - but there would be nothing optional or hinting about it - once you have one piece of code doing it, you'd have to have all code that touches it (and all code that touches that code, etc.) to be strict typed and exception-controlled. And then you'd want typed variables and throws clause to methods. Maybe we better rename PHP into Java and be done with it? :) type hinting for arrays and objects does the same (catchable fatal error on mismatch), whats the difference? if you start using a piece of code, which uses type hinting for non-scalar variables, you already have to deal with this kind of situation (custom error handler, or catching the exception) So from my point of view, you are arguing against the type hinting itself, which is too late IMHO. Tyrael
Re: [PHP-DEV] Type hinting
Hi! type hinting for arrays and objects does the same (catchable fatal error on mismatch), whats the difference? if you start using a piece of code, which uses type hinting for non-scalar variables, you already have to deal with this kind of situation (custom error handler, or catching the exception) The difference is it is very rare that you pass object of one class instead of another, and it is usually an obvious mistake (like using wrong variable, etc.). It is very frequent that you want number and get 1 instead - almost all incoming data for PHP are strings. So you may get by with basically ignoring class types since you'd almost never would have to handle failure in your app. With scalar strict typing, you'd most certainly have to handle failures. Also, it never makes sense to convert one object type into another, and almost never this operation can be defined. On the other hand, scalar types are very frequently converted in PHP and generally considered rather interchangeable in other dynamic languages. Nobody would refuse to understand that IS_INTEGER:0 and IS_BOOL:0 is the same and mean false. If you make your application have this distinction, you'd have to code for it in a way that never was what PHP is about. So from my point of view, you are arguing against the type hinting itself, which is too late IMHO. No it is not too late. It is never too late to stop PHP from turning into Java wannabe. If you want strictly-typed exclusively-OO language, you know where to find them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Tue, Jun 1, 2010 at 8:43 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
type hinting for arrays and objects does the same (catchable fatal error
on mismatch), whats the difference?
if you start using a piece of code, which uses type hinting for
non-scalar variables, you already have to deal with this kind of
situation (custom error handler, or catching the exception)
The difference is it is very rare that you pass object of one class instead
of another, and it is usually an obvious mistake (like using wrong variable,
etc.). It is very frequent that you want number and get 1 instead - almost
all incoming data for PHP are strings.
Occasionally, I used to forget, that my arrays get converted object if I
jsonize them back and forth, and sometimes I forget, that my fetched mysql
row is an array or an object, but maybe thats me.
But I agree with you, so I also think, that we should go for the weak type
hinting with scalars.
So you may get by with basically ignoring class types since you'd almost
never would have to handle failure in your app. With scalar strict typing,
you'd most certainly have to handle failures.
I think that with weak type hinting, the only cases, when you should get an
error/exception is when you pass a scalar, which cannot be converted to the
hinted type('123abc' hinted as an int, or 1.3 hinted as an int)
Also, it never makes sense to convert one object type into another, and
almost never this operation can be defined.
array and ArrayObject?
On the other hand, scalar types are very frequently converted in PHP and
generally considered rather interchangeable in other dynamic languages.
Nobody would refuse to understand that IS_INTEGER:0 and IS_BOOL:0 is the
same and mean false. If you make your application have this distinction,
you'd have to code for it in a way that never was what PHP is about.
Agree, we are used to it.
So from my point of view, you are arguing against the type hinting
itself, which is too late IMHO.
No it is not too late. It is never too late to stop PHP from turning into
Java wannabe. If you want strictly-typed exclusively-OO language, you know
where to find them.
I mean it's too late to argue about that the current type hinting triggers
an error in case of type mismatch.
My previous mail was about that we shouldn't implement the weak type hinting
to allow silent truncation on type conversion.
Tyrael
Re: [PHP-DEV] Type hinting
Hi! Also, it never makes sense to convert one object type into another, and almost never this operation can be defined. array and ArrayObject? This is a good example because strict typing would probably reject ArrayObject passed as array, thus defeating the whole purpose of having ArrayObject. That's exactly why we have to be very careful with strict types in dynamic language - because it makes excellent dynamic extensions line ArrayObject, __toString, etc. useless - since you can not really use one type instead of another as they intend, strict typing kills that. Coercive typing, on the other hand, would work just fine with those. I mean it's too late to argue about that the current type hinting triggers an error in case of type mismatch. Actually we could change it if we wanted to, I don't believe there's really some code that relies on it being error for some functionality. The question is what we'd change it to, for which I have no good answer. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Tue, Jun 1, 2010 at 10:11 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Also, it never makes sense to convert one object type into another, and almost never this operation can be defined. array and ArrayObject? This is a good example because strict typing would probably reject ArrayObject passed as array, thus defeating the whole purpose of having ArrayObject. Yeah, I know, this is why I said. That's exactly why we have to be very careful with strict types in dynamic language - because it makes excellent dynamic extensions line ArrayObject, __toString, etc. useless - since you can not really use one type instead of another as they intend, strict typing kills that. Coercive typing, on the other hand, would work just fine with those. Agree. I mean it's too late to argue about that the current type hinting triggers an error in case of type mismatch. Actually we could change it if we wanted to, I don't believe there's really some code that relies on it being error for some functionality. The question is what we'd change it to, for which I have no good answer. As I mentioned, I think that we have to inform the caller about the problem (be either a type or a conversion mismatch), so the only options to trigger an error, or throw an exception. I like the exception idea better, because it can be easily handled localy (no need to register a global error handler), but as the core devs said, it isn't allowed to throw exceptions from the core, so this is why I think, that the weak type hinting should be implemented as an spl interface. This way we could even support array - ArrayObject conversion too. http://wiki.php.net/rfc/splweaktypehintingwithautoboxing The rfc name sucks, but I couldn't come up with a better one. Tyrael
Re: [PHP-DEV] Type hinting
Hello! As I mentioned, I think that we have to inform the caller about the problem (be either a type or a conversion mismatch), so the only options to trigger an error, or throw an exception. I like the exception idea better, because it can be easily handled localy (no need to register a global error handler), but as the core devs said, it isn't allowed to throw exceptions from the core, so this is why I think, that the weak type hinting should be implemented as an spl interface. This way we could even support array - ArrayObject conversion too. http://wiki.php.net/rfc/splweaktypehintingwithautoboxing I'm not sure what is being added by using the SPL interface except a way to justify throwing exceptions on type mismatch with data loss? The only reason I can think of for throwing exceptions in this case would be data validation purposes, which I think is not the intention of type hinting, and also not the intention of exceptions (users inputting bad data is not an *exceptional* occurrence imo). Is there some other reason / use case for wanting exceptions? So, I mean, where is the use case where '123abc' will be passed to a type-hinted field where you could catch the exception and do something meaningful to carry on with the execution of the program other than simply error-ing out? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi! Is there some other reason / use case for wanting exceptions? So, I mean, where is the use case where '123abc' will be passed to a type-hinted field where you could catch the exception and do something meaningful to carry on with the execution of the program other than simply error-ing out? Pretty much everywhere. Suppose you have form with, say, 2 fields and first field does not validate. Maybe you want to check the second field too and give the user both errors if they are both wrong? In general, looking at strict typing as user input validation mechanism is a very bad idea. There are specialized use input validation functions/classes/frameworks, and one should use them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi! Pretty much everywhere. Suppose you have form with, say, 2 fields and first field does not validate. Maybe you want to check the second field too and give the user both errors if they are both wrong? In general, looking at strict typing as user input validation mechanism is a very bad idea. There are specialized use input validation functions/classes/frameworks, and one should use them. Right, that was my point. I can't think of any good reason to use exceptions rather than global errors (E_NOTICE or E_STRICT or similar), but some people seem to want exceptions. I was asking them if they had use valid cases (e.g. *not* data validation or similar which is undoubtably foolish) that would merit using exceptions rather than the global error handling. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Wed, Jun 2, 2010 at 7:41 AM, Chad Fulton chadful...@gmail.com wrote: Hi! Pretty much everywhere. Suppose you have form with, say, 2 fields and first field does not validate. Maybe you want to check the second field too and give the user both errors if they are both wrong? In general, looking at strict typing as user input validation mechanism is a very bad idea. There are specialized use input validation functions/classes/frameworks, and one should use them. Right, that was my point. I can't think of any good reason to use exceptions rather than global errors (E_NOTICE or E_STRICT or similar), but some people seem to want exceptions. I was asking them if they had use valid cases (e.g. *not* data validation or similar which is undoubtably foolish) that would merit using exceptions rather than the global error handling. Regardless of whether it's used for validation (which I agree is a bad idea), type errors may still occur elsewhere in the code; being able to handle those errors using exceptions has the advantage of keeping the context; a custom error handler lacks this and wouldn't be able to distinguish between errors, let alone be able to show the end-user any decent feedback. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
