Using Other Channels (was Scalar Type Declarations v0.5)

-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Thursday, February 19, 2015 4:24 PM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
v0.5)

Zeev,

This topic has been discussed to death in circles over the past several
years.
You're involved now. Awesome. Show me why your proposal is better rather
than trying to just tell me to stop or pause. Show the result of the
discussion.

I already said I respect your decision, even if I disagree with it. Holding
absolutely no grudge. The key tenets of the proposal that's being worked on
have already been shared on internals. Without putting words in your mouth,
based on the feedback you've provided over the last few days I don't have
high hopes that you personally would find it better, but I'm hoping many
others would. The formal RFC takes a bit more time to phrase, but I hope
we'll be able to finish the first version today or tomorrow.

Thanks,

Zeev

Zeev,

Based on Sara's clarification in this thread, I owe you a formal
apology. I interpreted something she said incorrectly, which was then
compounded by messages in private and on-list this morning. I then
attributed both of you qualities and motives that have been proven
false.

For this, I am sorry for any implication or direct acquisition that I
made against you.

Apology accepted! No worries.

I do believe that the best way forward is parallel proposals, as I
believe that we have different goals. So I look forward to seeing
yours, and will continue forward with mine. Hopefully this differing
of opinion can be rectified before too long.

Me too!

Thanks,

Zeev

2015-02-19 16:51 GMT+02:00 Pierre Joye pierre.php@gmail.com:

-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Thursday, February 19, 2015 4:09 PM
To: Zeev Suraski
Cc: Anthony Ferrara; PHP internals
Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type
Declarations
v0.5)

We have seen off list discussions or pressures many times in the pasts.
I
have
(other too but I can only talk for myself) been said an insane amount of
times
to stop private discussions, for anything related to php core. There is
no
exception to this rule. I repeat:
There is NO exception to this rule.

I disagree. Completely.

I did not expect you to agree. I would be surprised if you do.

I think 1:1 or group discussions are completely legitimate, and they're
not
only legitimate - they can be very productive.

There's a huge gap between making decisions in closed groups, or doing
'arm
bending' - and private discussions, which I repeat, are completely
legitimate.
Private discussions happen all the time, in countless mediums.
Conferences,
emails, IRC (public in theory, private in practice), Twitter DMs and
more.

There's absolutely nothing wrong with discussing an idea directly with
one
or more people before bugging thousands of people with it. They'd all be
better served if the idea presented to them already had a slightly more
than
just one person standing behind it (which is an inherent side effect of
barring private discussions as you suggest), and had some of the initial
issues weeded out.

To discuss at an idea or concept at events and co? Indeed. We all do
that. The difference is how to move it to a group discussions and grab
other people thoughts to actually get it done, with consensus. The
latter part is totally absent using your process.

Discussing, working, implementing something for weeks or months
privately? NDA and all that? Sorry, this is not the PHP I want.

Weeding out the initial issues? I wonder which magic you use to be
able to figure out all issues based on the experiences or thoughts of
a couple of people. It does not work. What you say is that a very
small group is able to pin point the perfect proposal better than
actually discussing it on the open channels. This is wrong in so many
ways.

Cheers,
Pierre

--

I think this starts to go the route of putting things into absolute. Ideal
things tend not to happen/work in the real world to the letter.

Some things just don't work out by themselves. The Type Hinting RFC's are
an anomaly in the regular PHP Core workflow and need some creative
handling. My personal view is that the RFC requires a mediator - the
person. who is more or less impartial to what type of hints get into PHP
and is able to handle communications between groups and bring them
together. RFC needs a triage. It needs someone to make a game plan and
implement it. Not someone developing one or the other proposal, but a
strictly managing entity. Because the further we go, the more things are
need to be taken care of. I believe the Type Hint project reached the
point, where it can't be handled by a single person. It touches into some
other RFC's in one or the other way, sometimes maybe requiring some
adjustments in the related RFC or the type hints itself.

Also, whatever way it goes at this point, the RFC's are not going to make
into 7.0 if we follow the release process properly. So, there needs some
decision making to happen considering the PHP itself, like reserving
keywords for 7.0, doing typehints for 7.1 and stuff alike.

Maybe it does not look like I have described it from inside, but from the
side it looks like a disaster is brewing and it's gonna blow any second now
leading to rushed decisions that may screw up things. I saw similar
situations a few times in my carrier and I certainly have that feel right
now. I'd give it 50/50 chance that something will go wrong here.

-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Thursday, February 19, 2015 4:52 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
v0.5)

To discuss at an idea or concept at events and co? Indeed. We all do that.
The difference is how to move it to a group discussions and grab other
people thoughts to actually get it done, with consensus. The latter part
is
totally absent using your process.

What exactly are we discussing here? My email to Sara yesterday? Or your
gripes with how PHPNG was handled?
I have no intention to discuss the latter, as it's been beaten to death ages
ago; And everything you're bringing up appears to be completely
disconnected to the former, which was supposedly the trigger to your email.
If it's just an excuse to reopen the PHPNG discussion, I'm not going to play
along with it.

Focusing on my email to Sara (and several others), there is NOTHING, nothing
wrong with a bit of private communications trying to gauge support,
opposition, gaps and sort out differences before going for a public
discussion. Personally I think it's ridiculous to suggest otherwise, and
it's completely equivalent to the stuff you stated 'we all do'. But
obviously you're entitled to a different opinion, including one that thinks
my position is ridiculous.

Thanks,

Zeev

Hi!

At the function border, yes. But not beyond that.

Not sure what you mean here. If the value is identified as int, it
remains int. How strict typing would change that?

Sort-of correct. We don't know if A is true, but we know what
conditions need to exist for A->B to be true. We know that A can be
any value. It could be a float. But that would lead to an error down
the road when the sum is passed to the function typing for an int.

Yes, and nothing guarantees you that the error actually does not occur
in this code, so you can't derive any additional information here.

Therefore, by knowing $c is passed to a function expecting an int, we
have information about stable states for $a and $b which would result
in a stable state for $c.

But that is not related to strict typing - this is a property of +,
which does not change with strict typing.

With strict mode, then we can work backwards and see that if $a is set
to 3.5, that we know that it's not a stable state (because at best an
error will be created).

I don't see how you can "work backwards". You can, again, reason that if
you passed the function call, then $c was int. But you can not derive
from that that $c was indeed int, since you don't know that the function
call actually worked. In fact, then whole purpose of strict typing is
catering for the case where it didn't, so you can not assume such cases
do not exist and also propose string typing - it is logically inconsistent.

With coercive typing (weak), you can't work backwards there because
3.5 + 1.5 is 5.0 which would be acceptable for an int hint. So you
have a LOT more possibilities to contend with.

You have the same possibilities in any case. Nothing guarantees you that
in fact, in real code, $a and $b is not exactly 3.5 and 1.5. Nothing
prevents them from being so.

This isn't so much about proving an application correct as it is about
proving information about the stable (non-error) states of the
program.

If you just ignore any cases when program may malfunction, what use such
analyzer would be for any real program - which with probability close to
1 has states in which it malfunctions? I still don't see how strict
typing adds any information here.

So with coercive typing (weak), the ability to detect errors and prove
stable states of the application is reduced and requires significantly
more computation.

I still don't see how. You only say that if we assume that the program
never fails, then we can derive more information from strict typing, but
if we could write programs that never fail we didn't have any need in
strict typing at the first place!
In compiled languages, this problem is solved by pre-resolving the types
of all variables prior to execution, but it is not possible in PHP, so
I don't see where the reduction comes from.

I'm talking about using the static analyzer to prove properties of the
stable (non-error) state. Yes, at runtime you only know things about
$a after the expression. But at static time, we can prove based on
what we know of $c, the acceptable input states that could possibly
lead to a stable state. Yes, you can generate errors. But the entire
point of static analysis is to detect the possibility of these errors
ahead of time rather than at runtime.

I still don't see how it is a useful thing. You are saying that by
inserting a code in your program somewhere that says "if(!is_int($a)) {
exit(0);} " you magically improve your knowledge about your program
before this code line. This seems to be a baseless claim, and quite
strange - whatever post-conditions you declare, it can not go back in
time and make the code before the post-condition somehow change or make
your knowledge about this code somehow better just because you have
added some code at the end.

But we're talking about much more than the behavior of one operation.
We're talking about the behavior of the entire set of function calls
around it (and the flow of type information based on these predictable
operations). So while + itself has no advantage from strict types,
passing the result to a function expecting an integer does give you a
lot of information about the non-error possibilities that the +
operation can have.

The whole point is that these operations are not predictable. What
you're doing here is saying "I don't care about hard cases where program
malfunctions" and then define any unexpected input as a hard case. With
this definition, of course, it is very easy to reason about the
remaining cases, only this reasoning is useless since it does not cover
what happens in real program run. That's like saying if you have code
that says $a = $b/$c then you can derive from mere existence of such
code that $c is non-zero, since otherwise the program fails. But of
course you can't derive that $c is non-zero only because you wrote a
code that relies on it! Otherwise no debugging would be ever necessary :)

It's not about how data gets in, it's about how data moves once it's
in. It's about knowing how types change and flow into other functions

I'm sorry, I don't see how the data moves differently in strict model
than in weak model. The only difference happens when passing the
function call, afterwards everything is the same, so if you say "it's
not about how data gets in" then there's no "it", since the only
difference between the models is exactly when the data gets in!

that's important. Because that lets you determine more data about the
stable (non-error) state of the application.

That claim is repeated again but not proved so far. Unless we accept the
(non-error) qualifier which makes the data useless, as if we assume our
program never fails we don't need any analysis at all - we just can read
the spec! The whole point of analysis is (usually) finding where the
program may fail!

Stas Malyshev
smalyshev@gmail.com

While typing this I did think to just scrap what I was writing, but I
think it is relevant if only if someone can explain why I am wrong?

With strictly typed $a and $b, the expression drops to 1 possible

permutation. And you can detect if it's a valid one. And many static
analysis engines do this.

I didn't see any proposal that proposes strictly types variables. As for
parameters, both strict and coercive typing provide knowledge about the
types of parameter inside the function they are defined in, so no
advantage to strict typing here.

It's not about how data gets in, it's about how data moves once it's
in. It's about knowing how types change and flow into other functions
that's important. Because that lets you determine more data about the
stable (non-error) state of the application.

With much of this it is what validation needs doing where. Data coming
into the process can either be well constrained, or totally random.
Pulling stuff back from a database, it has already been sanitised and
should be well constrained but even that may be questionable. Processing
the data may well introduce other constraints and I make no apology
hammering data size again. If we get an overflow for what ever reason
it has to be handled, and while that may be by adding additional checks
on a generic datatype, using a suitable already constrained type just
seems logical. Even more so if your reason for introducing strict
elements is to produce better optimized code? If all I need is a 16bit
count and the process will never exceed that do I really want an
unconstrained variable to represent it?

I will put my hand up and say that up until now I've not worried about
just how some of this works inside the box. It has only been since 64bit
builds have become the norm and unexplained errors started that I have
dug into that layer and to be honest some of the constraints that the
zend objects have created perhaps does not make sense although it does
explain why some people want to take it a stage further.

If I have a variable which is populated by a string of characters as a
starting point, then viewing that as a numeric value is a function of
that object rather than creating a new different object. Back to my
as_xxx rather than is_xxx ... as_xxx fails if the result can't be
produced, or yes it gives a new object of that type. It's how all these
extra objects exist that is confusing, but if all the persistent data
simply creates objects of the correct type in the first place then why
do you need to cast anything?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

De : Pádraic Brady [mailto:padraic.brady@gmail.com]

As I understand it, Andrea left her RFC free to be reused, reopened
and derived without any specific limitation. It would therefore appear
that it would be possible for there to be 100 derived RFCs all owned
by different people, i.e. nobody has an exclusive right to either the
RFC text or the concept of scalar typehints insofar as I understand
it.

You're right. The process of taking over an RFC in this case is not defined. Even if Andrea explicitly authorized anyone to derive anything from her work, I thought it was lack of respect for her work to take control and switch to another direction. That's why, while I'm not totally in sync with Anthony's proposal, I think he is acting the right way regarding Andrea's work.

And yes, apparently, you could have 100 RFCs derived from the same one and published by different people. I also guessed it was forbidden, at least by common sense, but it is possible.

I would happily support more rules for such cases.

As I believe Sara noted before, she will work with either of the RFCs
(yours or Anthony's) as it fits her own purposes, so it will boil down
to whichever RFCs gets published in the end. There's one up. I assume
yours will follow. That shall make two :).

Not sure we compete. Main reason is that, while I sometimes believe in (fair) competition, I am pretty sure one on such a hot subject would be globally negative for the community. Anyway, we will publish work done so far but, maybe, just for information. Anyway, nothing is decided and I'm talking for myself only. Others may decide differently. I don't own anything.

Regards

François