Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91749
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender)
MIME-Version: 1.0
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <CADyq6sKRFA667RA8Uzcx8SZ9x+GMEvoiX8S7QqrfV-fh0qgrGg@mail.gmail.com> <CADyq6sJxUrTQu__mQv-649cyvg4htzG+VK5g400b5-Vrvs5+TQ@mail.gmail.com>
In-Reply-To: <CADyq6sJxUrTQu__mQv-649cyvg4htzG+VK5g400b5-Vrvs5+TQ@mail.gmail.com>
Date: Fri, 18 Mar 2016 12:29:14 +0000
Message-ID: <CAGU04m+kojgxBvH0EH80D8wyofWZA4TKT6HvPA4RKTwWxx6V5A@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>, Phil Sturgeon <pjsturgeon@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114102c0ab3837052e51e59d
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: crocodile2u@gmail.com (Crocodile)

--001a114102c0ab3837052e51e59d
Content-Type: text/plain; charset=UTF-8

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 <ocramius@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 <ocramius@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

--001a114102c0ab3837052e51e59d--