> It takes up the syntax php has been using for method-definitions.
The fact is that the existing syntax for nullable type hinting has its own
problems. For example, this is not possible:
function foo( Bar $bar = null , $mandatory ) { ... }
I would love to have the question mark syntax for both properties and
argument type hinting.
> Although, as Stas has pointed out, *not* allowing NULL for a property
will not prevent it from being NULL...depending on wether it has been
initalized.
This does not apply in all cases. Here is an example of a property that is
guaranteed not to be null:
class Foo {
private $_date;
public DateTime $date {
get {
return is_null($date) ? new DateTime() : $this->date;
}
set {
$this->date = $value;
}
}
}
Lazare INEPOLOGLOU
Ingénieur Logiciel
2013/1/8 Lars Schultz <lars.schu...@toolpark.com>
> Am 08.01.2013 08:56, schrieb Christian Stoller:
>
>> But the way 'nullable' properties are defined is not very intuitive and
>> unclean, in my opinion. Stas has already mentioned that.
>> `public DateTime $date = NULL;` // this looks like the property is
>> initialized with null, but it does not show that the property is 'nullable'
>>
>
> To me this makes perfect sense. It takes up the syntax php has been using
> for method-definitions. A syntax we would be using to create a classic
> setter method if there wasn't a fancy new one.
>
> public function setDate(DateTime $date = NULL) {
> $this->date = $date;
> }
>
> Anything other than this would result in an inconsistency. Having accepted
> that syntax previously and now introducing yet another one, would be
> confusing and unnecessary.
>
> Although, as Stas has pointed out, *not* allowing NULL for a property will
> not prevent it from being NULL...depending on wether it has been initalized.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
