Just an idea of a syntax for nullable properties. What about:
/**
* Can be null
*/
public int null $foo;
/**
* Can NOT be null
*/
public float $bar;
This type of syntax has a long-living predecessor - SQL (INT NULL). I think
it is readable and it does not introduce ambiguity as in string|null case:
one might suggest that "string|int|float|null" is also possible. In my
solution, it is clear: the property either has the NULL predicate or it
doesn't.
Cheers!
On Fri, Mar 18, 2016 at 12:49 PM Marco Pivetta <ocram...@gmail.com> wrote:
> To answer my own question: the entire RFC is a no-go in its current state.
> On 18 March 2016 at 10:09, Marco Pivetta <ocram...@gmail.com> wrote:
>
> > That said, I have a few quite common use-cases that arise and that are a
> > bit problematic, both because they are hacks and because they are
> actually
> > used in large projects.
> >
> > Specifically, I'm worried about two particular use-cases:
> >
> > * unsetting properties
> > * by-ref property assignment
> >
> > To clarify, un-setting properties allows us to hide properties
> completely,
> > loading them on a per-usage basis:
> >
> > class Foo {
> > public int $bar;
> > public function __construct() {
> > unset($this->bar); // is this operation legal? For BC compliance,
> > I'd expect that to be the case
> > }
> > public function __get(string $name)
> > {
> > initialize_properties_here($this); // external thing connecting
> to
> > db, loading files, yadda yadda
> > }
> > }
> >
> > var_dump((new Foo())->bar); // what happens here? can
> > `initialize_properties_here` actually assign a non-int to `$bar`? Will
> the
> > type safety still work?
> >
>
> See https://3v4l.org/bsHXH/rfc#tabs - unset() doesn't work, and that
> breaks
> some basic PHP semantics that are covered by phpt tests, but just for the
> case of typed properties.
>
>
> > The by-ref property assignment is a bit trickier, but can probably be
> > worked around with some overhead (re-assigning).
> > Here's what is going on:
> >
> > class Foo {
> > public int $bar;
> > public function __construct() {
> > unset($this->bar);
> > }
> > public function __get(string $name)
> > {
> > $this->bar = 123; // default value
> > $props = ['bar' => & $this->bar]; // is this operation now
> > considered illegal?
> > initialize_properties_here($props); // external thing connecting
> > to db, loading files, yadda yadda
> > }
> > }
> >
>
>
> See https://3v4l.org/sKqYb/rfc#tabs - by-ref assignment is forcefully
> disabled, and that breaks some more PHP semantics just for the case of
> typed properties.
>
> To sum it up, the RFC has one major problem: it focuses on the WHEN
> assignments happen, rather than just checking WHAT is assigned.
>
> I think the scope of the proposal needs to be reduced strictly to type
> checking.
> As it stands, this is too magic (and I do qu
>
> Cheers,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
--
Best regards,
Victor Bolshov
