Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9633
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20040502195913.0342d9e0@127.0.0.1>
Date: Sun, 02 May 2004 20:00:26 +0300
To: internals@lists.php.net
In-Reply-To: <1083515960.331.84.camel@localhost>
References: <243202120.20040501220932@marcus-boerger.de>
 <243202120.20040501220932@marcus-boerger.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] [RFC] Type hints
From: andi@zend.com (Andi Gutmans)

At 06:39 PM 5/2/2004 +0200, Timm Friebe wrote:
>On Sat, 2004-05-01 at 22:09, 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 allowing NULL with typehints would happen
> > only very rare.
>
>I don't think this is true. I think there are a number of cases where
>passing NULL is used to "unset" or "delete" something. For example, say
>a class supports debugging using a listener model:
>
>   class Foo {
>     function setEventListener(Listener $l) { ... }
>   }
>
>   $foo= new Foo();
>   $foo->setEventListener(new ConsoleListener());
>   // ...
>   $foo->setEventListener(NULL);
>
>This makes perfect sense to me and also gets rid of the constraint of
>having to define an "unsetEventListener" method.
>
>To wrap it up: Would you agree that being able to pass NULL to any
>pointer argument in C is annoying?

Personally, I would leave things the way they are today. But both Zeev and 
Marcus feel this is the wrong way to go and I understand their point.


>[...]
> > 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.
>
>I like this idea best: No magic such as "only when it is the first
>default argument" (the question "why" will inevitably come up sooner or
>later); plus no BC break.
>
>Concerning the new keyword argument, how about using the exclamation
>mark (already meaning "not"), as in:
>
>* function foo(Classname !NULL $val) { }
>   The same as Andi's suggestion, but using ! instead of "not"
>
>* function foo(Classname $val !NULL) { }
>   Ditto, but using postfix notation. Comes close to default value
>   syntax which people are already used to.
>
>* function foo(Classname $val != NULL) { }
>   This would be even more similar to the default value syntax.


I prefer "not null" :)

Andi