On Wed, Jun 2, 2010 at 7:41 AM, Chad Fulton 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 s
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
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?
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
On Tue, Jun 1, 2010 at 10:11 PM, Stas Malyshev wrote:
> 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 rejec
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
ArrayO
On Tue, Jun 1, 2010 at 8:43 PM, Stas Malyshev wrote:
> 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 dea
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 th
On Tue, Jun 1, 2010 at 7:55 PM, Stas Malyshev wrote:
> 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
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 yo
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
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.
Ch
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
13 matches
Mail list logo
