Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

Posted by Michael Morris 
Ryan Jentzsch
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 07:20PM
I agree with Michael (to a large degree) and I think I see clearly
Michael's point:
Under the current system I will NEVER create an RFC (or find someone with
the Zend engine coding chops to help me) because the RISK vs. REWARD with
the current RFC system is too likely to be a colossal waste of everyone's
time.
Currently the tail wags the dog (implementation details govern top level
policy). The current process nearly insists I spend valuable time coding up
front with a good chance that if/when the RFC goes up for a vote someone
will still be bleating about syntax, or using tabs vs. spaces, or some
other minor detail -- with a 2/3 vote needed it may shoot all my
preliminary hard work to hell. No thanks.



On Wed, Jan 10, 2018 at 6:27 AM, Michael Morris <[email protected]> wrote:

> On Wed, Jan 10, 2018 at 12:53 AM, Rasmus Lerdorf <[email protected]>
> wrote:
>
> >
> > The difference here is that the end syntax is something like 10% of the
> > problem. 90% of it is fitting it into the engine in an efficient manner
> > giving that it is affecting the very core of the engine. An RFC on this
> > issue that doesn't address the bulk of the problem isn't all that
> helpful.
> >
> >
> It makes absolutely NO sense to do that 90% of the work to have it all
> burned up when the proposal fails to carry a 2/3rds vote because the syntax
> is disliked.
>
> Also, drawing the architectural drawings for a skyscraper is also like only
> 10% of the work, but it's a damn important 10%.
>
> That the implementation will be a major pain in the ass to do is all the
> more reason to create and pass a planning RFC before doing any related
> code/implementation RFC's. It will encourage people to do the research to
> try to figure out how to get this done because they know the syntax is
> approved and they aren't fiddling around in the dark trying to figure out
> how to do something that may not be accepted for inclusion at all, which is
> a huge waste of time.
>
Rasmus Lerdorf
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 07:30PM
On Wed, Jan 10, 2018 at 10:11 AM, Ryan Jentzsch <[email protected]>
wrote:

> I agree with Michael (to a large degree) and I think I see clearly
> Michael's point:
> Under the current system I will NEVER create an RFC (or find someone with
> the Zend engine coding chops to help me) because the RISK vs. REWARD with
> the current RFC system is too likely to be a colossal waste of everyone's
> time.
> Currently the tail wags the dog (implementation details govern top level
> policy). The current process nearly insists I spend valuable time coding up
> front with a good chance that if/when the RFC goes up for a vote someone
> will still be bleating about syntax, or using tabs vs. spaces, or some
> other minor detail -- with a 2/3 vote needed it may shoot all my
> preliminary hard work to hell. No thanks.


There is a middle ground here. I agree that doing months of work on a
rock-solid implementation doesn't make sense if you don't know the RFC will
pass. On the other end of the spectrum, RFCs that are essentially feature
requests with no specifics on the actual implementation also don't make any
sense. A good RFC strikes a happy balance between the two. For many/most
things, the actual work in figuring out the implementation isn't that bad.
As Sara said, a full implementation isn't needed, but a rough sketch of
what changes are needed along with their potential impact on the existing
code definitely is. And yes, unfortunately, if your RFC touches the basic
building block of PHP, the zval, then that rough sketch becomes even more
important. If you stay away from trying to change a 25-year old loosely
typed language into a strictly typed one, then the RFC becomes much simpler.

-Rasmus
Michael Morris
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 07:50PM
On Wed, Jan 10, 2018 at 9:04 AM, Rasmus Lerdorf <[email protected]> wrote:

>
>
> On Wed, Jan 10, 2018 at 5:27 AM, Michael Morris <[email protected]>
> wrote:
>>
>> Also, drawing the architectural drawings for a skyscraper is also like
>> only
>> 10% of the work, but it's a damn important 10%.
>>
>
> Wow, that's rather insulting to the amazing work Dmitry, Nikita, Xinchen
> and others are doing working on the core of PHP.
>

No insult was intended here. I apologize if any is taken.


> Describing the syntax/UI for a feature like this is nothing like the
> architectural drawings for a skyscraper.
>

In terms of time and effort spent it is. It often takes years to complete
plans drawn up over the span of weeks. The analogy becomes more firm when
you compare the man hours on each side - an architect can draw up plans for
a house in less than 100 hours (unless it's a freaking huge house). The
contractor labor hours will be 100 times that at a minimum. If anything I'm
off in scales, but I was being anecdotal - I wasn't aiming for precise
accuracy.

Plans still must precede work, and if the ramifications of those plans are
to be far reaching they need to be agreed upon as early as possible.
Michael Morris
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 07:50PM
On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf <[email protected]> wrote:

> If you stay away from trying to change a 25-year old loosely typed
> language into a strictly typed one, then the RFC becomes much simpler.
>
> -Rasmus
>

I have REPEATEDLY stated that is not the goal. I don't misrepresent what
you say, please do not do that to me.

I want to see strict typing as an option, not a requirement.

Arggh...

I said I'd stay away from implementation, but would this work? Working
this into z_val in any way is problematic. So, store elsewhere?

Create a symbol table that holds the strict variables and the types they
are locked into. The strict keyword pushes them onto that table, the var
keyword pulls them off. When an operation that cares about type occurs
check that table - if the var appears there than authenticate it.

I would hope that if a programmer doesn't want strict typing the overhead
of checking an empty table would be minimal, even if repeated a great many
times.
Rasmus Lerdorf
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 08:10PM
On Wed, Jan 10, 2018 at 10:48 AM, Michael Morris <[email protected]> wrote:

> On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf <[email protected]>
> wrote:
>
> > If you stay away from trying to change a 25-year old loosely typed
> > language into a strictly typed one, then the RFC becomes much simpler.
> >
> > -Rasmus
> >
>
> I have REPEATEDLY stated that is not the goal. I don't misrepresent what
> you say, please do not do that to me.
>
> I want to see strict typing as an option, not a requirement.
>

But the point is that whether it is an option or not, it still has to touch
the zval. Which means everything changes whether the option is enabled or
not. If you store this information elsewhere, that other location has to be
checked on every zval access. Basically the work is identical to the work
required to make PHP strictly typed. Making it optional might actually be
harder because we have to build both and add more checks in that case.

The only viable place I see to store this optionally is outside the runtime
in a static analyzer like Phan (which already does this) which matches how
HHVM solved it. Of course, there may be a cleaner way to do it. But that is
why an RFC on this topic has to give a clear plan towards this cleaner
implementation.

Now if the RFC was a plan for baking a compile-time static analysis engine
into PHP itself, that would be interesting. But that is a *massive* project.

-Rasmus
Andreas Hennings
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 08:30PM
On 10 January 2018 at 19:59, Rasmus Lerdorf <[email protected]> wrote:
>
> Now if the RFC was a plan for baking a compile-time static analysis engine
> into PHP itself, that would be interesting. But that is a *massive* project.

Even with my limited understanding of the engine, I can imagine this
to be a lot of work.
But it sounds much better to me than adding more expensive runtime type checks.
I think it would be worth exploring as a long-term direction.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andreas Hennings
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 08:30PM
Whether we work with runtime type checks or compile-time static analysis:
The user-facing language design questions would still be the same, right?
E.g. we would still have to distinguish type-locked parameter values
vs dynamically typed parameter values.

On 10 January 2018 at 20:23, Andreas Hennings <[email protected]> wrote:
> On 10 January 2018 at 19:59, Rasmus Lerdorf <[email protected]> wrote:
>>
>> Now if the RFC was a plan for baking a compile-time static analysis engine
>> into PHP itself, that would be interesting. But that is a *massive* project.
>
> Even with my limited understanding of the engine, I can imagine this
> to be a lot of work.
> But it sounds much better to me than adding more expensive runtime type checks.
> I think it would be worth exploring as a long-term direction.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 10:20PM
On 10/01/2018 18:39, Michael Morris wrote:
> On Wed, Jan 10, 2018 at 9:04 AM, Rasmus Lerdorf <[email protected]> wrote:
>
>> Describing the syntax/UI for a feature like this is nothing like the
>> architectural drawings for a skyscraper.
> In terms of time and effort spent it is. It often takes years to complete
> plans drawn up over the span of weeks. The analogy becomes more firm when
> you compare the man hours on each side - an architect can draw up plans for
> a house in less than 100 hours (unless it's a freaking huge house).

I don't think Rasmus was saying architects' plans aren't important, or
making any comment about the scale of the task. I think he was saying
that things like syntax and UI are not the appropriate part of the
process to compare to architects' plans. Architects know how buildings
work, and spend those weeks making sure the subsequent years aren't
going to be wasted because the plausible-looking shape the client asked
for can't actually support its own weight.

And just to be clear, this particular feature IS a freaking huge house.
Worse, it's a type of skyscraper nobody has ever tried to build before.
Sketching the kinds of shapes it might have is interesting; getting hung
up on what size the windows are (the exact keywords to use) is probably
a waste of time until we've figured out if there's a material that bends
that way. And saying "hey, could you make it out of carbon nanotubes?"
is a fun conversation to have over a beer, but probably isn't going to
be that helpful to people who are experts on skyscrapers and material
science.

Apologies for extending the metaphor somewhat beyond stretching point,
but I think it acts as a reasonable illustration of where people are
coming from in this thread.


> Plans still must precede work, and if the ramifications of those plans are
> to be far reaching they need to be agreed upon as early as possible.

Absolutely, and unfortunately, the biggest ramifications of this
particular type of change is going to be in the very core of the engine.
That's not true of every feature, but for this particular feature, one
of the parts that needs planning and agreeing as early as possible is
"how are we going to do this without killing performance".


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ryan Jentzsch
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 10:20PM
In my opinion The Strong Typing Syntax RFC will have less of a chance of
passing a vote than https://wiki.php.net/rfc/typed-properties.
Since the typed-properties RFC was confined to properties on a class (and
looking at the code it appears to me that it wasn't too difficult to
implement the type strictness constraints). Sadly, even after it was shown
to have minimal effect on performance the RFC was still shot down.

Strong Typing Syntax I would think is even more complicated given this
touches ALL zval processing internally. The concern of "expensive run-time
checks" can of course be mitigated by requiring declare(strict_types=1) to
enable/allow strong typing syntax.
I'd love to see Strong Typing Syntax in PHP but realistically, given the
past history, this RFC will need to target version 8.


On Wed, Jan 10, 2018 at 12:25 PM, Andreas Hennings <[email protected]>
wrote:

> Whether we work with runtime type checks or compile-time static analysis:
> The user-facing language design questions would still be the same, right?
> E.g. we would still have to distinguish type-locked parameter values
> vs dynamically typed parameter values.
>
> On 10 January 2018 at 20:23, Andreas Hennings <[email protected]> wrote:
> > On 10 January 2018 at 19:59, Rasmus Lerdorf <[email protected]> wrote:
> >>
> >> Now if the RFC was a plan for baking a compile-time static analysis
> engine
> >> into PHP itself, that would be interesting. But that is a *massive*
> project.
> >
> > Even with my limited understanding of the engine, I can imagine this
> > to be a lot of work.
> > But it sounds much better to me than adding more expensive runtime type
> checks.
> > I think it would be worth exploring as a long-term direction.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Sorry, only registered users may post in this forum.

Click here to login