headers
Peter Beverloo | 1 Jun 2010 07:44
Gravatar

Re: [PHP-DEV] ereg deprecation?

2010/5/31 Felipe Pena <felipensp <at> gmail.com>
>
> 2010/5/31 Johannes Schlüter <johannes <at> schlueters.de>
>
> > On Mon, 2010-05-31 at 14:09 -0300, Felipe Pena wrote:
> > > Hi,
> > >
> > > 2010/4/28 Michael Maclean <michael <at> no-surprises.co.uk>
> > >
> > > > Hi,
> > > > I think I asked this before on IRC, but I've forgotten the answer. I
> > was
> > > > just remembering that the ereg extension was due to be deprecated in
> > PHP6 -
> > > > does this still apply to trunk?
> > > >
> > > >
> > > I think make no sense to keep it deprecated.
> > >
> > > Here's a patch for undeprecate ext/ereg in 5_3 and trunk:
> > > http://felipe.ath.cx/diff/undeprecate-ereg.diff
> > >
> > > Any objection? If no, I'll commit it in soon.
> >
> > I still won't recommend using ereg - the missing binary-safety causes
> > quite some broken checks ... is there anything that can be done which
> > can't be done using pcre? If not: Less code to maintain -> less
> > trouble :-)
> >
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guillaume F | 1 Jun 2010 15:59
Picon
Favicon

[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
Permalink | Reply | 3 comments |
headers
Christopher Jones | 1 Jun 2010 18:17
Picon
Favicon

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.jones <at> 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
Permalink | Reply | 0 comments |
headers
Stas Malyshev | 1 Jun 2010 19:41
Favicon
Gravatar

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
Permalink | Reply | 0 comments |
headers
Stas Malyshev | 1 Jun 2010 19:55
Favicon
Gravatar

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
Permalink | Reply | 20 comments |
headers
Ferenc Kovacs | 1 Jun 2010 20:27
Picon
Gravatar

Re: [PHP-DEV] Type hinting

On Tue, Jun 1, 2010 at 7:55 PM, Stas Malyshev <smalyshev <at> sugarcrm.com>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 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
Permalink | Reply | 19 comments |
headers
Stas Malyshev | 1 Jun 2010 20:43
Favicon
Gravatar

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.
--

--
(Continue reading)

Permalink | Reply | 18 comments |
headers
Ferenc Kovacs | 1 Jun 2010 22:04
Picon
Gravatar

Re: [PHP-DEV] Type hinting

On Tue, Jun 1, 2010 at 8:43 PM, Stas Malyshev <smalyshev <at> sugarcrm.com>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 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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Stas Malyshev | 1 Jun 2010 22:11
Favicon
Gravatar

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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ferenc Kovacs | 1 Jun 2010 22:27
Picon
Gravatar

Re: [PHP-DEV] Type hinting

On Tue, Jun 1, 2010 at 10:11 PM, Stas Malyshev <smalyshev <at> sugarcrm.com>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 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.

>
>
(Continue reading)

Permalink | Reply | 6 comments |

Gmane