Re: [RFC] Alternative typehinting syntax for accessors

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