headers
Guillaume Lecanu | 1 May 2004 11:06
Picon

[PHP-DEV] CVS Account Request: guillaume

I need a CVS account to managed my PEAR package XML_FastCreate :
http://pear.php.net/pepr/pepr-proposal-show.php?id=47

I aslo need karma to add my XML_RPC_Lite classes to XML_RPC package of Stig Bakken / Martin Jansen (they are ok).

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Marcus Boerger | 1 May 2004 22:09
Picon

[PHP-DEV] [RFC] Type hints

Hello internals,

  while working with php 5 the last days i find it more and more
annoying that we allow NULL with type hints. From my perspective
allowing NULL with typehints would happen only very rare. So i
looked into the issue once again and prepared a patch.

  first i looked back the mails for this issue and found three
possible solutions:

1) (Zeev) allow NULL only when it is the first default argument.
Here the disadvantage is that you cannot have non default parameters
after one that allows NULL. Also this would introduce a BC break if
we'd go this way after 5.0 is out because it changes the standard
behavior.

2) (Andi) introduce 'not null' after php 5.0. This won't introduce
a BC break. But it would require two new keywords 'NOT' and 'NULL'.
The latter is not a problem because it is a define at the moment
and the patch (a) shows that it easy to change it into a keyword.
The problem is the new keyword 'not' which would introduce a BC
break for everyone using the word 'not' already.

3) (Myself) introduce 'or null'. Obviously this would introduce a
BC break when implemented after PHP 5.0 is out. The advantage is
that it only requires NULL as an additional keyword (see above)
and that it reflects the code it replaces. The replacement code
is to check whether the parameter is an instance of the typehint
"or" if specified check if it is null:
(Continue reading)

Permalink | Reply | 52 comments |
headers
Michael Walter | 1 May 2004 22:27

Re: [PHP-DEV] [RFC] Type hints

Marcus Boerger wrote:
> Hello internals,
 > [...]
How about
   function foo(Class? bar)
instead? Too much magic?

Cheers,
Michael

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 1 comment |
headers
Derick Rethans | 1 May 2004 22:52
Picon
Gravatar

Re: [PHP-DEV] [RFC] Type hints

On Sat, 1 May 2004, Michael Walter wrote:

> Marcus Boerger wrote:
> > Hello internals,
>  > [...]
> How about
>    function foo(Class? bar)
> instead? Too much magic?

Too much magic indeed.

Derick

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
John Coggeshall | 1 May 2004 23:27

Re: [PHP-DEV] [RFC] Type hints

I agree with the idea that it would be nice to force an instance of a
particular class, etc. to be passed. However, if we are going to
introduce another keyword anyway why not keep BC intact by by
introducing the 'force' keyword:

function myfunction(force ClassName $param, NextClass $another) {

}

Where 'force' would prevent $param from being passed as anything but an
acceptable ClassName. Alternatively, for the sake of parsing you could
do:

function myfunction(Classname forced $foo) {

}

I remember discussing 'array' as a typehint (big +1 there), but I don't
see anything gained from such a type-hint. When exactly would you use it
(that you couldn't use the existing type hinting).. I guess the obvious
answer is when you don't know the type of class being passed, but if you
don't know that how do you plan on actually using the parameter at all? 

John

--

-- 
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall                   http://www.coggeshall.org/
The PHP Developer's Handbook    http://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcus Boerger | 2 May 2004 00:05
Picon

Re: [PHP-DEV] [RFC] Type hints

Hello John,

Saturday, May 1, 2004, 11:27:32 PM, you wrote:

> I agree with the idea that it would be nice to force an instance of a
> particular class, etc. to be passed. However, if we are going to
> introduce another keyword anyway why not keep BC intact by by
> introducing the 'force' keyword:

the point of solution 3 was not to introduce a new keyword other than null.
And adding null as a keyword dosn't have implications other that ppl may
have a fucntion called 'null'. But i don't think that happens often. Using
force or forced on the other hand seems to happen often at least i used it
myself.

> I remember discussing 'array' as a typehint (big +1 there),

good so far

> but I don't
> see anything gained from such a type-hint. When exactly would you use it
> (that you couldn't use the existing type hinting).. I guess the obvious
> answer is when you don't know the type of class being passed, but if you
> don't know that how do you plan on actually using the parameter at all? 

What are you speaking of here?
array means the parameter must be an array.
class means the parameter must be any class instance which can be used for
reflection as an example.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markus Fischer | 2 May 2004 11:17
Picon

[PHP-DEV] php-src/TODO foreach-enhancements

    Hi,

    has anyone played around with those two subjects from php-src/TODO ?

    * Allow foreach ($array as $k => list($a, $b)) syntax for multi
      dimensional arrays.

    * Allow foreach ($array as $k => &$val) syntax. right now we cannot
      traverse an array without copying each element.

    I'm just curious to know if someone has worked on this recently.

    cheers,

        - Markus

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 2 comments |
headers
Wez Furlong | 2 May 2004 13:11

Re: [PHP-DEV] php-src/TODO foreach-enhancements

The latter of these is in PHP 5 afair.

--Wez.

----- Original Message ----- 
From: "Markus Fischer" <mfischer <at> gjat.josefine.at>
To: <internals <at> lists.php.net>
Sent: Sunday, May 02, 2004 10:17 AM
Subject: [PHP-DEV] php-src/TODO foreach-enhancements

>     Hi,
> 
>     has anyone played around with those two subjects from php-src/TODO ?
> 
>     * Allow foreach ($array as $k => list($a, $b)) syntax for multi
>       dimensional arrays.
> 
>     * Allow foreach ($array as $k => &$val) syntax. right now we cannot
>       traverse an array without copying each element.

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Andi Gutmans | 2 May 2004 17:40
Favicon

Re: [PHP-DEV] == object comparison bug?

Thanks for the detailed report. This should be fixed in the latest CVS.

Andi

At 01:25 PM 4/28/2004 -0400, Hans Lellelid wrote:
>I'm using PHP5.0.0RC2.  I saw that there was a similar question posted, 
>but apparently that issue had already been fixed.
>
>
>---code----------------------------
>
>class File {
>         public $var;
>         function __construct($val) {
>                 $this->var = $val;
>         }
>}
>
>$t1 = new File("test");
>$t2 = new File("test");
>
>print_r($t1);
>print_r($t2);
>
>print "\$t1 == \$t2 ?";
>if ($t1 == $t2) {
>         print "YES\n";
>} else {
>         print "NO\n";
>}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andi Gutmans | 2 May 2004 18:09
Favicon

Re: [PHP-DEV] [RFC] Type hints

Hi Marcus,

It probably makes sense to go with (3) because as Zeev says, the majority 
of the times you don't want to allow NULL.
If we decide to go this direction we definitely need to implement it before 
PHP 5 because otherwise it'll be a big BC break.
I wouldn't use the syntax you proposed but you:
function func(MyClass $obj or null);

Concerning type hints, I don't think that a type hint of "class" is useful. 
If you don't use a base class as a type hint (which you will almost always 
use) then how useful will this really be? Also, it's not really Class but 
it's an Object, so we'd have to add another reserved word. In my opinion, 
I'd only go with the "array" part of the typehints patch.

On another note, I think PHP 5 is already stable and quite mature. It's an 
order of magnitude more stable than PHP 4 was when it was released. I think 
we should start thinking of a deep feature freeze and a release date. As 
we're in the beginning of May I think sometime towards July makes sense. 
This does mean that we really need to stop adding stuff. I agree to open 
the typehints issue because it could potentially lead to a BC break 
depending what solution we take.

Andi

At 10:09 PM 5/1/2004 +0200, Marcus Boerger wrote:
>Hello internals,
>
>   while working with php 5 the last days i find it more and more
>annoying that we allow NULL with type hints. From my perspective
(Continue reading)

Permalink | Reply | 44 comments |

Gmane