[PHP-DEV] Scalar type hinting

@Simon If it's ok with you, I would like to set this aside briefly and
divert our attention toward the RFC voting thing, primarily because I think
that will make the drafting process much easier and less confusing when
we're ready to start working on the typing RFC initial draft. Any
objections?

If not, I'll go ahead and draft an RFC for these proposed amendments
sometime today or tomorrow when I get a spare moment. If anyone has any
thoughts on this, please share them! Thanks!

--Kris


On Wed, Feb 29, 2012 at 4:18 PM, Simon Schick
<[email protected]>wrote:

> Hi, all
>
> What's next?
>
> I think the next step would be to write down a good Introduction,
> Requirement, Solution and Examples.
>
> As we had some discussions and ideas around here I think we came to a
> proper place where we could write the first draft and discuss it after
> writing it down in one place.
> I wont have the time tomorrow but I'll try my best to get it done at the
> weekend.
>
> If someone else has a good overview and wants to write the RFC, just go
> ahead and ping me when you've started.
>
> @Kris:
> I like the idea of having a second vote-level. The first level could be
> "Like / Dislike this feature" and the second one could be "Like Solution1 /
> Like Solution2 / Like Solution3"
>
> Bye
> Simon
>
>
> 2012/3/1 Kris Craig <[email protected]>
>
>> @Simon Well said! For some reason, the issue of typing in the PHP and
>> other programming communities brings out a lot of emotion in people. Given
>> some of the heated rhetoric we've seen, you'd think we were debating
>> whether Roe v. Wade should be overturned lol.
>>
>> I think it is important that we try to remember to be civil, on both
>> sides. Falling into cliche hyperbole, condescention, and personal attacks
>> just makes us look immature to the outside world IMHO. I'll try to do my
>> part and not fly off the handle so much whenever somebody jumps in with a
>> dismissive, patronizing comment relating to something that was already
>> addressed earlier.
>>
>> Regarding the RFCs, just to clarify my earlier remarks, I should mention
>> that the current policy, at least as I understand it, does not provide for
>> expiring old/abandoned RFCs. The idea that it should was just a
>> recommendation on my part. That said, I think you've got the right idea by
>> looking at previous RFCs for insight into this! All I was saying is that,
>> when it comes time to put forth our own proposal(s), it would probably be
>> easier to write it from the ground up instead of trying to modify a bunch
>> of older ones. =)
>>
>>
>> Oh and if anybody has any thoughts on the suggestion I made earlier about
>> adding "secondary questions" to the voting procedure (please read it before
>> commenting), I'd love to hear them! I think that could be very helpful in
>> future RFCs, so if there's any interest I'll go ahead and draft one for
>> this.
>>
>> --Kris
>>
>>
>>
>> On Wed, Feb 29, 2012 at 3:56 PM, Simon Schick <
>> [email protected]> wrote:
>>
>>> Hi, All
>>>
>>> Sorry for pulling the old RFCs out. But why is their status is still *in
>>> draft* or something like that? I did not know something about the
>>> 6-month-rule.
>>> That's also what I mentioned before with the missing solution ... If you
>>> close an RFC or set it to *accepted*, please also write what has been
>>> accepted. Btw: the old RFCs need to be cleaned up some when ... archived ...
>>>
>>> As I see from your mails, you're not in detail following this
>>> conversation.
>>> Btw. The conversation got quite down to a personal level in the last
>>> hours ... not really talking about facts and arguments.
>>>
>>> I don't want a strict/weak type-binding of variables, either do I want
>>> something strict if you pass stuff into a function.
>>> I simply want to define a type for each argument of a function/method.
>>> If someone calls this function with a parameter that is not compatible with
>>> the required type, let it break.
>>>
>>> The other RFCs were just something I saw on my way. That's nothing I
>>> personally wanted to push forward (not right now at least) but they fit in
>>> our discussion and were written in an RFC that was related to what I wanted.
>>>
>>> @Kris:
>>>
>>> > I prefer the latter, which is why I am now pushing this.
>>> What I am very thankful for ;)
>>>
>>> Bye
>>> Simon
>>>
>>>
>>> 2012/2/29 Kris Craig <[email protected]>
>>>
>>>> With all due respect, it's a logical fallacy to draw a direct comparison
>>>> between these two simply because they both happen to be uphill battles.
>>>>
>>>> We've demonstrated in this discussion that it can, in fact, be done
>>>> without
>>>> breaking the PHP concept at all. The only consistent argument I'm
>>>> hearing
>>>> against it is, "It's been voted down before." And yet, it keeps coming
>>>> up. Why do you suppose that is? Mind you, this is the first time that
>>>> I
>>>> have ever brought this up. So it's not just me. Ignoring this
>>>> obviously
>>>> hasn't made it go away. We can either continue sitting in denial and
>>>> whining whenever somebody brings this up, or we can finally stop
>>>> procrastinating and take on the unpleasant task of actually working this
>>>> out. PHP 6 presents the perfect opportunity for something like this
>>>> anyway.
>>>>
>>>>
>>>> Voting it down hasn't made it go away. What is it they say about the
>>>> definition of insanity? Doing the same thing over and over again and
>>>> expecting a different result. This concept has been proposed in many
>>>> different ways, but now it seems like some of you have decided to just
>>>> vote
>>>> it down because you're tired of it being talked about. But that hasn't
>>>> worked, has it? And it won't. So we can either keep doing this every 6
>>>> months or we can try to work something out that addresses this finally.
>>>> Even if we were to take the totalitarian approach of restricting the
>>>> voting
>>>> process, that wouldn't stop people from bringing this up on the list, so
>>>> the "problem" of people continuing to bring this up would still go on.
>>>>
>>>> Seriously, just step back and look at this from a practical, logical
>>>> standpoint. What we've been doing hasn't worked. Summarily voting
>>>> anything resembling this down to make it go away hasn't made it go away.
>>>> One of the main reasons I finally jumped into this discussion after all
>>>> these years is because I noticed this pattern was once again repeating
>>>> itself in the enum thread. This isn't going to just magically go away.
>>>> People aren't going to "see the light" and suddenly stop asking for this
>>>> just because they've realized the core devs decided to click the
>>>> "ignore"
>>>> button. We can either keep repeating this pattern or we can step out of
>>>> denial and finally address this. I prefer the latter, which is why I am
>>>> now pushing this.
>>>>
>>>> --Kris
>>>>
>>>>
>>>> On Wed, Feb 29, 2012 at 2:46 PM, Matt Wilson <[email protected]> wrote:
>>>>
>>>> > I once pushed this hard for namespaces. Then, after years of it being
>>>> shot
>>>> > down, they did it.
>>>> >
>>>> > And now I'm sad. It didn't occur to me until after it had been
>>>> implemented
>>>> > how bad an idea it was for php. I think this is one of those times.
>>>> >
>>>> > Type hinting is wonderful, but i'm not sure you could really make it
>>>> fit
>>>> > in php without bastardizing the concept.
>>>> >
>>>> > The last time I looked at this discussion, I saw something about
>>>> call-time
>>>> > silent type conversion (essentially foo((int) $bar)) and if that's not
>>>> > bastardizing a concept...
>>>> >
>>>> > I think the community has spoken. And when the core devs put their
>>>> foot
>>>> > down, I think it's best to listen. If it's so important to you, then
>>>> by all
>>>> > means, fork. Or simply write a patch. Put it to a vote. But this is
>>>> beating
>>>> > a very dead horse.
>>>> >
>>>> > -M
>>>> >
>>>> > On Feb 29, 2012, at 4:36 PM, Kris Craig wrote:
>>>> >
>>>> > > I agree. I'm against strict type hinting as well. Of course,
>>>> nobody
>>>> > here
>>>> > > is suggesting that we should go with strict typing, so it's a moot
>>>> > question
>>>> > > anyway.
>>>> > >
>>>> > > --Kris
>>>> > >
>>>> > >
>>>> > > On Wed, Feb 29, 2012 at 2:35 PM, Arvids Godjuks <
>>>> > [email protected]>wrote:
>>>> > >
>>>> > >> Please.read my emails carefuly. What i said is last time the work
>>>> has
>>>> > been
>>>> > >> done, and two different patches have been developed and iterated.
>>>> But
>>>> > >> dificulties in implementation and strong resistance from the devs
>>>> and
>>>> > >> comunity got it killed. I actually had a post on our biggest
>>>> russian
>>>> > >> speaking IT resource and results shown that majority of comunity
>>>> was
>>>> > >> against strict type hinting - it does not fit PHP philosophy.
>>>> Simple as
>>>> > >> that.
>>>> > >> Thats all, if you cant unders
>>>> > >>
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>

> If it errors out or throws an exception, it's strict typing, regardless of naming.

Actually, for purposes of this discussion, "strict" is defined. It means "PHP complains about (function(int $n){})('1'), even though it could have easily converted it." The majority of arguments in the past, and especially those that have caused the typing discussions to fall apart, have centered around reasons why this sort of typing is bad. Strict, by this definition, is totally off the table in this discussion. Period.

With respect to E_RECOVERABLE_ERROR, nobody seems especially attached to this, except that it is consistent with current type hints, so it is the logical choice. A consistent alternative would be a new E_TYPE error (and convert existing type hints to use that), but that would be a BC break and expands the scope of the proposal more than I think some people are comfortable with (myself included).

> Are you essentially telling us we all have to waste our time again just because 6 months have passed?

No, we're discussing this again because for the first time we have a set of terminology that we can use to explain how this is different from the terror that has primarily been avoided in the past.

I'm in favor of moving the discussion elsewhere while details are fleshed out and carefully compared to the historical arguments, but so far there has been no consensus on where to move this.

I'll personally resist any attempt to submit anything that isn't substantially different from prior proposals and/or that doesn't include solutions to the problems previously identified.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> Hi, all
>
> What's next?
>
> I think the next step would be to write down a good Introduction,
> Requirement, Solution and Examples.
>
> As we had some discussions and ideas around here I think we came to a
> proper place where we could write the first draft and discuss it after
> writing it down in one place.
> I wont have the time tomorrow but I'll try my best to get it done at
> the weekend.
>
> If someone else has a good overview and wants to write the RFC, just
> go ahead and ping me when you've started.
>
> @Kris:
> I like the idea of having a second vote-level. The first level could
> be "Like / Dislike this feature" and the second one could be "Like
> Solution1 / Like Solution2 / Like Solution3"
>
> Bye
> Simon
>

An RFC would be WAY premature. We still haven't even consolidated the historical arguments. If you create an RFC blindly without carefully scrutinizing the prior analysis and measuring against prior arguments you'll be the next in a long line of failures.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> -----Original Message-----
> From: Kris Craig [mailto:[email protected]]
>
> @Richard I think you made a very good point. Should we treat a float => int mismatch the same as we would a string => int mismatch, or should the former fail more gracefully? I can see good arguments for both.
>
> --Kris

I'm beginning to think that the type hinting question is too closely related to the dirty secrets of type juggling to resolve them separately. You may have to either discard consistency, or else fix the problem of silent bizarre conversions at the same time ('foo'==0, '123abc'=123). Fixing the conversions is a BC break though.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

I was thinking something more along the lines of simply throwing an error
if, say, (int) $a != $a.... *if *$a is defined as an integer.

--Kris


On Wed, Feb 29, 2012 at 5:16 PM, John Crenshaw <[email protected]>wrote:

> > -----Original Message-----
> > From: Kris Craig [mailto:[email protected]]
> >
> > @Richard I think you made a very good point. Should we treat a float =>
> int mismatch the same as we would a string => int mismatch, or should the
> former fail more gracefully? I can see good arguments for both.
> >
> > --Kris
>
> I'm beginning to think that the type hinting question is too closely
> related to the dirty secrets of type juggling to resolve them separately.
> You may have to either discard consistency, or else fix the problem of
> silent bizarre conversions at the same time ('foo'==0, '123abc'=123).
> Fixing the conversions is a BC break though.
>
> John Crenshaw
> Priacta, Inc.
>

On Wed, Feb 29, 2012 at 8:46 PM, Kris Craig <[email protected]> wrote:

> I was thinking something more along the lines of simply throwing an error
> if, say, (int) $a != $a.... *if *$a is defined as an integer.
>
> --Kris
>
>
> On Wed, Feb 29, 2012 at 5:16 PM, John Crenshaw <[email protected]
> >wrote:
>
> > > -----Original Message-----
> > > From: Kris Craig [mailto:[email protected]]
> > >
> > > @Richard I think you made a very good point. Should we treat a float
> =>
> > int mismatch the same as we would a string => int mismatch, or should the
> > former fail more gracefully? I can see good arguments for both.
> > >
> > > --Kris
> >
> > I'm beginning to think that the type hinting question is too closely
> > related to the dirty secrets of type juggling to resolve them separately.
> > You may have to either discard consistency, or else fix the problem of
> > silent bizarre conversions at the same time ('foo'==0, '123abc'=123).
> > Fixing the conversions is a BC break though.
> >
> > John Crenshaw
> > Priacta, Inc.
> >
>

John raises some real concerns about the relation of hinting and juggling.
I'm wondering about allowing developers to declare type intentions (I'll
post an idea in a separate thread.)

Adam

On Wed, February 29, 2012 6:55 pm, Kris Craig wrote:
> If not, I'll go ahead and draft an RFC for these proposed amendments
> sometime today or tomorrow when I get a spare moment. If anyone has
> any
> thoughts on this, please share them! Thanks!

This is not an official answer. I don't have time to dig out references.

I believe the PHP community settled on the idea of having a single
simple pass / fail vote without the complexity of branches / options.

It was simply to hard to tally the votes once you open up the options,
because your support base ends up being split.

NOTE: See current US Republican Primaries for examples of how complex
it gets. :-)

There is nothing to stop one from drafting multiple proposals, with
alternative options, and each one getting vote upon, other than the
time available to the person drafting the proposals.

And, of course, a reasonable expectation that with TOO many proposals
of the same idea, the community would quickly turn into robo-voting,
both for and against, as that's just human nature.

Again, I say, I don't claim to speak for the whole community. This is
merely my interpretation from my faulty memory of past events.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

@Richard Yeah that sounds about right actually. That's probably exactly
the reasoning behind the current model being what it is.

However, it seems to me that, especially in complex proposals, the "should
we?" and the "how?" distinction becomes more and more difficult to avoid.
If everyone supports an idea, but there are a hundred different viable ways
to do it, having a hundred different competing proposals would be a
nightmare IMHO (especially if fifty of them passed and are directly
conflicting with one another lol).

That's why I'm thinking, if you split them into separate questions but keep
them in the same overall proposal, you can wind up with the best of both
worlds. The "primary" question is whether or not this should be done to
begin with; if it fails, then everything else is moot. If it passes, on
the other hand, then the plurality on any secondary question(s) would allow
us to simultaneously and efficiently decide *how* it should be implemented
without having to create separate proposals or cause the support vote to
become split (since your vote(s) to any secondary questions would have no
bearing on your primary question vote).

For example, let's time-travel ten years into the future. I wanted to
modify PHP 7.3's configure script to use a botnet I control to increase
PHP's processing power (as of PHP 7, PHP can exploit rootkits but it can't
control entire botnets). If enabled, the RFC argues, I'd be able to
increase my spam output tenfold and still have enough victim machines to
carry out a DoS attack against FaceGoo+ (yep, they merged) and silence my
many enemies. But then, there a serious problem surrounding this proposal
that someone raises: Should there be a switch to activate this or should
it simply be configure's default behavior? Also, should this include a
switch that instructs PHP to install a rootkit on vulnerable systems
automatically, and if so, should we integrate that with the main switch,
make it a separate switch, or just make it the default behavior as well?

Naturally, this would best be handled as a single RFC. The "primary"
question would be something along the lines of, "Should PHP's built-in
trojan management capabilities be expanded to allow for control of large
botnets (yes/no)?"

Then, there would be some secondary questions; for each one, the prefix "If
implemented...." is assumed: "Should the the switch be enabled by default
(yes/no)," "How should rootkit install toggling be handled (option on main
switch/separate switch/just make it default)," and, "Should we commit
another series of arsons at Semantic in order to slow the development of
new security patches that might hinder our supreme objective?"


Heh sorry, my examples tend to get a bit psychotic after a long day at
work. But you have the gist of it, at least. ;)

--Kris


On Wed, Feb 29, 2012 at 6:32 PM, Richard Lynch <[email protected]> wrote:

> On Wed, February 29, 2012 6:55 pm, Kris Craig wrote:
> > If not, I'll go ahead and draft an RFC for these proposed amendments
> > sometime today or tomorrow when I get a spare moment. If anyone has
> > any
> > thoughts on this, please share them! Thanks!
>
> This is not an official answer. I don't have time to dig out references.
>
> I believe the PHP community settled on the idea of having a single
> simple pass / fail vote without the complexity of branches / options.
>
> It was simply to hard to tally the votes once you open up the options,
> because your support base ends up being split.
>
> NOTE: See current US Republican Primaries for examples of how complex
> it gets. :-)
>
> There is nothing to stop one from drafting multiple proposals, with
> alternative options, and each one getting vote upon, other than the
> time available to the person drafting the proposals.
>
> And, of course, a reasonable expectation that with TOO many proposals
> of the same idea, the community would quickly turn into robo-voting,
> both for and against, as that's just human nature.
>
> Again, I say, I don't claim to speak for the whole community. This is
> merely my interpretation from my faulty memory of past events.
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
>
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> I'm beginning to think that the type hinting question is too closely
> related to the dirty secrets of type juggling to resolve them
> separately. You may have to either discard consistency, or else fix
> the problem of silent bizarre conversions at the same time ('foo'==0,
> '123abc'=123). Fixing the conversions is a BC break though.

[short version]
One man's "fixing" is another man's "feature" :-)

Old hands can now hit delete while I wax philosophical.

[long version]

PHP does the type juggling because HTTP data is all string. It's a
feature, because PHP's main purpose was to process HTTP input.
[Yes, I know you did not dispute this. It's just foreshadowing...]

Once one accepts the premise that automatic type-juggling is "good",
the idea that (int) "123 abc" turns into 123 may seem incredibly
"wrong" or "right" depending on how useful one has found it.

I have found it useful, and others have as well, to the point that we
don't consider it something to "fix" but a "feature"

Obviously, others disagree. And that's okay. We "get" that some
disagree, and even why some disagree. We've all coded in C, C++, C#,
Forth, Modula 2, Lisp, PL/1, and many more, collectively.

We choose PHP, at times, because it is the way it is, as "broken" as
it may seem to others. And they are legion. One only needs to review
blogs and mailing lists of fans of other strictly-typed languages to
see this.

But Breaking Compatibility with something so deeply ingrained in the
culture and language, which goes back consistently at least to PHP3,
and probably PHP/FI, is a non-starter.

There are probably literally millions of scripts that will break "out
there." That's simply unacceptable, and I trust you understand why
that is so.

You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the way.

It's duct tape and bailing wire. And we love it for that.

If the app is useful enough, it might even get cleaned up. Or just
more duct tape and bailing wire is applied, more likely. :-)

Even at a major release, PHP has, by and large, strived to remain
Backwards Compatible, unless a VERY compelling reason was presented.

A vocal minority, or even a majority, of developers does not qualify.
That's pretty much why the Core Devs' "veto" power exists.

Some of the proposals and ideas lately have adhered to that concept of
not breaking Backwards Compatibility. Others have not, and those are
just non-starters.

But PHP core has always had the mantra "Keep It Simple, Stupid"

If one wants a complex language, PHP is simply not going to be it, and
virtually all of these proposals do not fit the KISS principle, at a
fundamental level of "Any idiot can read halfway decent code and
puzzle out what it does in less than a day."

This is a Religious Issue, a personal preference, a philosophical
ideal, etc. Right or wrong, it is what it is, by choice, by the core
developers who have put years worth of effort into it.

Please don't read this as "go away" or a restatement of the arguments
that have been labeled as circular before. I am merely trying to
explain why PHP is the way it is, at a 10,000 foot level, and why so
many core devs are resistant to the changes being proposed.

I highly respect all the efforts and the alternative philosophical
differences, and even the guiding principles of Computer Science
driving them. PHP is just not the language for Computer Science types,
for the most part. It's for the masses.

Some CS types like it in certain situations, which is all to the good,
or it would be a total mess :-) We embrace its "flaws" and ugly hacks
because, like it or not, "it works" for what it's designed to do.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Bah and after all that, I went and misspelled *Symantec. *grumbles*

--Kris


On Wed, Feb 29, 2012 at 7:01 PM, Kris Craig <[email protected]> wrote:

> @Richard Yeah that sounds about right actually. That's probably exactly
> the reasoning behind the current model being what it is.
>
> However, it seems to me that, especially in complex proposals, the "should
> we?" and the "how?" distinction becomes more and more difficult to avoid.
> If everyone supports an idea, but there are a hundred different viable ways
> to do it, having a hundred different competing proposals would be a
> nightmare IMHO (especially if fifty of them passed and are directly
> conflicting with one another lol).
>
> That's why I'm thinking, if you split them into separate questions but
> keep them in the same overall proposal, you can wind up with the best of
> both worlds. The "primary" question is whether or not this should be done
> to begin with; if it fails, then everything else is moot. If it passes, on
> the other hand, then the plurality on any secondary question(s) would allow
> us to simultaneously and efficiently decide *how* it should be
> implemented without having to create separate proposals or cause the
> support vote to become split (since your vote(s) to any secondary questions
> would have no bearing on your primary question vote).
>
> For example, let's time-travel ten years into the future. I wanted to
> modify PHP 7.3's configure script to use a botnet I control to increase
> PHP's processing power (as of PHP 7, PHP can exploit rootkits but it can't
> control entire botnets). If enabled, the RFC argues, I'd be able to
> increase my spam output tenfold and still have enough victim machines to
> carry out a DoS attack against FaceGoo+ (yep, they merged) and silence my
> many enemies. But then, there a serious problem surrounding this proposal
> that someone raises: Should there be a switch to activate this or should
> it simply be configure's default behavior? Also, should this include a
> switch that instructs PHP to install a rootkit on vulnerable systems
> automatically, and if so, should we integrate that with the main switch,
> make it a separate switch, or just make it the default behavior as well?
>
> Naturally, this would best be handled as a single RFC. The "primary"
> question would be something along the lines of, "Should PHP's built-in
> trojan management capabilities be expanded to allow for control of large
> botnets (yes/no)?"
>
> Then, there would be some secondary questions; for each one, the prefix
> "If implemented...." is assumed: "Should the the switch be enabled by
> default (yes/no)," "How should rootkit install toggling be handled (option
> on main switch/separate switch/just make it default)," and, "Should we
> commit another series of arsons at Semantic in order to slow the
> development of new security patches that might hinder our supreme
> objective?"
>
>
> Heh sorry, my examples tend to get a bit psychotic after a long day at
> work. But you have the gist of it, at least. ;)
>
> --Kris
>
>
>
> On Wed, Feb 29, 2012 at 6:32 PM, Richard Lynch <[email protected]> wrote:
>
>> On Wed, February 29, 2012 6:55 pm, Kris Craig wrote:
>> > If not, I'll go ahead and draft an RFC for these proposed amendments
>> > sometime today or tomorrow when I get a spare moment. If anyone has
>> > any
>> > thoughts on this, please share them! Thanks!
>>
>> This is not an official answer. I don't have time to dig out references.
>>
>> I believe the PHP community settled on the idea of having a single
>> simple pass / fail vote without the complexity of branches / options.
>>
>> It was simply to hard to tally the votes once you open up the options,
>> because your support base ends up being split.
>>
>> NOTE: See current US Republican Primaries for examples of how complex
>> it gets. :-)
>>
>> There is nothing to stop one from drafting multiple proposals, with
>> alternative options, and each one getting vote upon, other than the
>> time available to the person drafting the proposals.
>>
>> And, of course, a reasonable expectation that with TOO many proposals
>> of the same idea, the community would quickly turn into robo-voting,
>> both for and against, as that's just human nature.
>>
>> Again, I say, I don't claim to speak for the whole community. This is
>> merely my interpretation from my faulty memory of past events.
>>
>> --
>> brain cancer update:
>> http://richardlynch.blogspot.com/search/label/brain%20tumor
>> Donate:
>>
>> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>

I agree with your well-thought-out remarks overall. However (and you knew
a "however" was coming lol), by making these types optional, we would be
allowing full backwards-compatibility without alienating non-CS developers,
since they would be able to continue writing the same code they do now.
Likewise, and I know I keep going back to this, PHP 5's stronger
implementation of OO did not break backwards compatibility or scare away
procedural developers who are not versed on OO concepts. I would cite that
as precedent for this; in that, if done correctly and with great care, this
can be implemented without trampling on PHP's KISS principles IMHO.

--Kris


On Wed, Feb 29, 2012 at 7:02 PM, Richard Lynch <[email protected]> wrote:

> On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> > I'm beginning to think that the type hinting question is too closely
> > related to the dirty secrets of type juggling to resolve them
> > separately. You may have to either discard consistency, or else fix
> > the problem of silent bizarre conversions at the same time ('foo'==0,
> > '123abc'=123). Fixing the conversions is a BC break though.
>
> [short version]
> One man's "fixing" is another man's "feature" :-)
>
> Old hands can now hit delete while I wax philosophical.
>
> [long version]
>
> PHP does the type juggling because HTTP data is all string. It's a
> feature, because PHP's main purpose was to process HTTP input.
> [Yes, I know you did not dispute this. It's just foreshadowing...]
>
> Once one accepts the premise that automatic type-juggling is "good",
> the idea that (int) "123 abc" turns into 123 may seem incredibly
> "wrong" or "right" depending on how useful one has found it.
>
> I have found it useful, and others have as well, to the point that we
> don't consider it something to "fix" but a "feature"
>
> Obviously, others disagree. And that's okay. We "get" that some
> disagree, and even why some disagree. We've all coded in C, C++, C#,
> Forth, Modula 2, Lisp, PL/1, and many more, collectively.
>
> We choose PHP, at times, because it is the way it is, as "broken" as
> it may seem to others. And they are legion. One only needs to review
> blogs and mailing lists of fans of other strictly-typed languages to
> see this.
>
> But Breaking Compatibility with something so deeply ingrained in the
> culture and language, which goes back consistently at least to PHP3,
> and probably PHP/FI, is a non-starter.
>
> There are probably literally millions of scripts that will break "out
> there." That's simply unacceptable, and I trust you understand why
> that is so.
>
> You might consider those scripts poor programming practice. We all do.
> But PHP is the language of the unwashed masses, and that was, and is,
> part of why it is hugely popular. Somebody who barely understands
> programming can pound away at the keyboard and write a bloody useful
> web application, breaking 10,000 Computer Science rules along the way.
>
> It's duct tape and bailing wire. And we love it for that.
>
> If the app is useful enough, it might even get cleaned up. Or just
> more duct tape and bailing wire is applied, more likely. :-)
>
> Even at a major release, PHP has, by and large, strived to remain
> Backwards Compatible, unless a VERY compelling reason was presented.
>
> A vocal minority, or even a majority, of developers does not qualify.
> That's pretty much why the Core Devs' "veto" power exists.
>
> Some of the proposals and ideas lately have adhered to that concept of
> not breaking Backwards Compatibility. Others have not, and those are
> just non-starters.
>
> But PHP core has always had the mantra "Keep It Simple, Stupid"
>
> If one wants a complex language, PHP is simply not going to be it, and
> virtually all of these proposals do not fit the KISS principle, at a
> fundamental level of "Any idiot can read halfway decent code and
> puzzle out what it does in less than a day."
>
> This is a Religious Issue, a personal preference, a philosophical
> ideal, etc. Right or wrong, it is what it is, by choice, by the core
> developers who have put years worth of effort into it.
>
> Please don't read this as "go away" or a restatement of the arguments
> that have been labeled as circular before. I am merely trying to
> explain why PHP is the way it is, at a 10,000 foot level, and why so
> many core devs are resistant to the changes being proposed.
>
> I highly respect all the efforts and the alternative philosophical
> differences, and even the guiding principles of Computer Science
> driving them. PHP is just not the language for Computer Science types,
> for the most part. It's for the masses.
>
> Some CS types like it in certain situations, which is all to the good,
> or it would be a total mess :-) We embrace its "flaws" and ugly hacks
> because, like it or not, "it works" for what it's designed to do.
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
>
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

> You might consider those scripts poor programming practice. We all do.
> But PHP is the language of the unwashed masses, and that was, and is,
> part of why it is hugely popular. Somebody who barely understands
> programming can pound away at the keyboard and write a bloody useful
> web application, breaking 10,000 Computer Science rules along the way.

And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the "unwashed masses" argument, and yet, the security geek in me sometimes questions how "good" this is.

(Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.)

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Secure code is not about the instrument, it's about how you write it.
Insecure spagetti code can be written in any language.

> From: Richard Lynch [mailto:[email protected]]
> On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> > I'm beginning to think that the type hinting question is too closely
> > related to the dirty secrets of type juggling to resolve them
> > separately. You may have to either discard consistency, or else fix
> > the problem of silent bizarre conversions at the same time ('foo'==0,
> > '123abc'=123). Fixing the conversions is a BC break though.
>
> [short version]
> One man's "fixing" is another man's "feature" :-)
>
> Old hands can now hit delete while I wax philosophical.

The operative word was "silent". The actual behavior is fine, but the silence is unexpected. For example, PHP happily accepts substr('foo', 'bar') with no complaint at all. From a purely philosophical perspective I think almost everyone would expect *at least* a strict notice.

On a practical level, we have a major barrier and we'll have to decide how to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC break)
3. Try to find a creative solution to be consistent without changing anything about the conversion behavior. (I'm not seeing a way to do this one, unless we redefine "consistent".)

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi, John

Just to add an idea to yours ..

Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.

Bye
Simon

2012/3/1 John Crenshaw <[email protected]>

> > From: Richard Lynch [mailto:[email protected]]
> > On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> > > I'm beginning to think that the type hinting question is too closely
> > > related to the dirty secrets of type juggling to resolve them
> > > separately. You may have to either discard consistency, or else fix
> > > the problem of silent bizarre conversions at the same time ('foo'==0,
> > > '123abc'=123). Fixing the conversions is a BC break though.
> >
> > [short version]
> > One man's "fixing" is another man's "feature" :-)
> >
> > Old hands can now hit delete while I wax philosophical.
>
> The operative word was "silent". The actual behavior is fine, but the
> silence is unexpected. For example, PHP happily accepts substr('foo',
> 'bar') with no complaint at all. From a purely philosophical perspective I
> think almost everyone would expect *at least* a strict notice.
>
> On a practical level, we have a major barrier and we'll have to decide how
> to handle it. As I see it we could do one of the following:
> 1. Discard consistency (!!)
> 2. Try to convince people to make these bizarre conversions not silent (BC
> break)
> 3. Try to find a creative solution to be consistent without changing
> anything about the conversion behavior. (I'm not seeing a way to do this
> one, unless we redefine "consistent".)
>
> John Crenshaw
> Priacta, Inc.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

From: Simon Schick [mailto:[email protected]]
>
> Hi, John
>
> Just to add an idea to yours ..
>
> Do you think it's a compatibility-break if we'd decide to send a E_NOTICE or E_WARNING if we f.e. try to give a string to a method that just allows integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed anyways.
>
> Bye
> Simon

That's what I was calling "inconsistent", specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent.

On the other hand if you add an error in the legacy case now that's a BC break. One might argue that it should always have given a notice, but it didn't, so it's a change, and a BC break. Pick your poison.

John Crenshaw
Priacta, Inc.

If any of you are interested in such change in PHP, please get
together and write a complete RFC. As I do not see any kind of
progress but, as you stated, some philosophical discussions. That's
all good but after 2 weeks, it is time to move forward (or stop).

Cheers,

On Thu, Mar 1, 2012 at 4:02 AM, Richard Lynch <[email protected]> wrote:
> On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
>> I'm beginning to think that the type hinting question is too closely
>> related to the dirty secrets of type juggling to resolve them
>> separately. You may have to either discard consistency, or else fix
>> the problem of silent bizarre conversions at the same time ('foo'==0,
>> '123abc'=123). Fixing the conversions is a BC break though.
>
> [short version]
> One man's "fixing" is another man's "feature" :-)
>
> Old hands can now hit delete while I wax philosophical.
>
> [long version]
>
> PHP does the type juggling because HTTP data is all string. It's a
> feature, because PHP's main purpose was to process HTTP input.
> [Yes, I know you did not dispute this. It's just foreshadowing...]
>
> Once one accepts the premise that automatic type-juggling is "good",
> the idea that (int) "123 abc" turns into 123 may seem incredibly
> "wrong" or "right" depending on how useful one has found it.
>
> I have found it useful, and others have as well, to the point that we
> don't consider it something to "fix" but a "feature"
>
> Obviously, others disagree.  And that's okay. We "get" that some
> disagree, and even why some disagree. We've all coded in C, C++, C#,
> Forth, Modula 2, Lisp, PL/1, and many more, collectively.
>
> We choose PHP, at times, because it is the way it is, as "broken" as
> it may seem to others. And they are legion. One only needs to review
> blogs and mailing lists of fans of other strictly-typed languages to
> see this.
>
> But Breaking Compatibility with something so deeply ingrained in the
> culture and language, which goes back consistently at least to PHP3,
> and probably PHP/FI, is a non-starter.
>
> There are probably literally millions of scripts that will break "out
> there." That's simply unacceptable, and I trust you understand why
> that is so.
>
> You might consider those scripts poor programming practice. We all do.
> But PHP is the language of the unwashed masses, and that was, and is,
> part of why it is hugely popular. Somebody who barely understands
> programming can pound away at the keyboard and write a bloody useful
> web application, breaking 10,000 Computer Science rules along the way.
>
> It's duct tape and bailing wire. And we love it for that.
>
> If the app is useful enough, it might even get cleaned up.  Or just
> more duct tape and bailing wire is applied, more likely. :-)
>
> Even at a major release, PHP has, by and large, strived to remain
> Backwards Compatible, unless a VERY compelling reason was presented.
>
> A vocal minority, or even a majority, of developers does not qualify.
> That's pretty much why the Core Devs' "veto" power exists.
>
> Some of the proposals and ideas lately have adhered to that concept of
> not breaking Backwards Compatibility. Others have not, and those are
> just non-starters.
>
> But PHP core has always had the mantra "Keep It Simple, Stupid"
>
> If one wants a complex language, PHP is simply not going to be it, and
> virtually all of these proposals do not fit the KISS principle, at a
> fundamental level of "Any idiot can read halfway decent code and
> puzzle out what it does in less than a day."
>
> This is a Religious Issue, a personal preference, a philosophical
> ideal, etc. Right or wrong, it is what it is, by choice, by the core
> developers who have put years worth of effort into it.
>
> Please don't read this as "go away" or a restatement of the arguments
> that have been labeled as circular before.  I am merely trying to
> explain why PHP is the way it is, at a 10,000 foot level, and why so
> many core devs are resistant to the changes being proposed.
>
> I highly respect all the efforts and the alternative philosophical
> differences, and even the guiding principles of Computer Science
> driving them. PHP is just not the language for Computer Science types,
> for the most part. It's for the masses.
>
> Some CS types like it in certain situations, which is all to the good,
> or it would be a total mess :-) We embrace its "flaws" and ugly hacks
> because, like it or not, "it works" for what it's designed to do.
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Kris Craig wrote:
> With all due respect, it's a logical fallacy to draw a direct comparison
> between these two simply because they both happen to be uphill battles.

There is a direct comparison between the two. Both provide something that a
large number of people did not or do not want anything to do with. Namespace was
forced on us in much the same way you are currently trying to force this on us.
Many people who were pursuaded that namespace was a good idea are now realising
that it wasn't and was the thin end of wedge which this discussion is once again
trying to force open. I have no objections to 'object orientated' as that is how
I have always used PHP, but the BULK of the data I am handling is simply strings
which 'magically' get converted to the format I need. I don't see any use for
'type hinting' in any form since I NEED to check if a string I get in has the
right data in before I store it in a database field. I don't need to throw some
random error which needs handling ... I just handle the errors in line as I
process the data. My framework helps to ensure what I get in is right in the
first place anyway, so even the in-line checks are probably redundant nowadays!

--
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//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> That's what I was calling "inconsistent", specifically because (int)'foo'
> == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an
> error of some sort. Behavior with respect to when an error is raised is
> inconsistent. In both cases there is a very lossy conversion, why is there
> an error in one case and not the other? Inconsistent.
>

+1

However, I would love to have int $a = 'foo' cast to 0 without any error.

New functionality without breaking BC.



Lazare INEPOLOGLOU
Ingénieur Logiciel


2012/3/1 John Crenshaw <[email protected]>

> From: Simon Schick [mailto:simonsi[email protected]]
> >
> > Hi, John
> >
> > Just to add an idea to yours ..
> >
> > Do you think it's a compatibility-break if we'd decide to send a
> E_NOTICE or E_WARNING if we f.e. try to give a string to a method that just
> allows integer for this argument?
> No break at all, just a E_NOTICE or E_WARNING as the script can succeed
> anyways.
> >
> > Bye
> > Simon
>
> That's what I was calling "inconsistent", specifically because (int)'foo'
> == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an
> error of some sort. Behavior with respect to when an error is raised is
> inconsistent. In both cases there is a very lossy conversion, why is there
> an error in one case and not the other? Inconsistent.
>
> On the other hand if you add an error in the legacy case now that's a BC
> break. One might argue that it should always have given a notice, but it
> didn't, so it's a change, and a BC break. Pick your poison.
>
> John Crenshaw
> Priacta, Inc.
>

On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick <[email protected]>wrote:

> Hi, John
>
> Just to add an idea to yours ..
>
> Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
> or E_WARNING if we f.e. try to give a string to a method that just allows
> integer for this argument?
> No break at all, just a E_NOTICE or E_WARNING as the script can succeed
> anyways.
>
> Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of "cleaner" programming.

Try substr('foo', 'bar'), in PHP >= 5.3 and you get a warning and the
function returns null.

Julien.P


> Bye
> Simon
>
> 2012/3/1 John Crenshaw <[email protected]>
>
> > > From: Richard Lynch [mailto:[email protected]]
> > > On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> > > > I'm beginning to think that the type hinting question is too closely
> > > > related to the dirty secrets of type juggling to resolve them
> > > > separately. You may have to either discard consistency, or else fix
> > > > the problem of silent bizarre conversions at the same time ('foo'==0,
> > > > '123abc'=123). Fixing the conversions is a BC break though.
> > >
> > > [short version]
> > > One man's "fixing" is another man's "feature" :-)
> > >
> > > Old hands can now hit delete while I wax philosophical.
> >
> > The operative word was "silent". The actual behavior is fine, but the
> > silence is unexpected. For example, PHP happily accepts substr('foo',
> > 'bar') with no complaint at all. From a purely philosophical perspective
> I
> > think almost everyone would expect *at least* a strict notice.
> >
> > On a practical level, we have a major barrier and we'll have to decide
> how
> > to handle it. As I see it we could do one of the following:
> > 1. Discard consistency (!!)
> > 2. Try to convince people to make these bizarre conversions not silent
> (BC
> > break)
> > 3. Try to find a creative solution to be consistent without changing
> > anything about the conversion behavior. (I'm not seeing a way to do this
> > one, unless we redefine "consistent".)
> >
> > John Crenshaw
> > Priacta, Inc.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

On Thu, Mar 1, 2012 at 9:00 AM, Lester Caine <[email protected]> wrote:

> Both provide something that a large number of people did not or do not
> want anything to do with.
>

I disagree - The majority of PHP developers I've discussed this with are
in favor of adding *something *like this. Do a majority want this? I have
no idea and, I honestly don't believe you do either.


> Namespace was forced on us in much the same way you are currently trying
> to force this on us.
>

Forced? Nobody is forcing anything. Discussions are happening, and possibly
a vote in the future. This is the farthest thing from being forced IMO.


> Many people who were pursuaded that namespace was a good idea are now
> realising that it wasn't and was the thin end of wedge which this
> discussion is once again trying to force open.
>

Many of the popular frameworks have made the changes, or are planning to
make the changes, needed to take advantage of namespaces. This, to me,
suggests a general acceptable of namespaces.

Also - I'm yet to hear a single complaint about namespaces
- although again, I've not talked to every PHP developer!

(Well.. No complaints other than the namespace separator being a '\' that
is)


> I have no objections to 'object orientated' as that is how I have always
> used PHP, but the BULK of the data I am handling is simply strings which
> 'magically' get converted to the format I need. I don't see any use for
> 'type hinting' in any form since I NEED to check if a string I get in has
> the right data in before I store it in a database field. I don't need to
> throw some random error which needs handling ... I just handle the errors
> in line as I process the data. My framework helps to ensure what I get in
> is right in the first place anyway, so even the in-line checks are probably
> redundant nowadays!
>

I can certainly agree with you here - have I ever absolutely NEEDED this?
Nope. Would it get it the way of writing code in certain situations? Yup.

But - Does that mean it's not generally useful? Nope!

Kiall

Here's one thing to consider. Right now casting/type-autoconversion
is inconsistent at best. Let me show you what I mean:

If I add 1 to a variable, the variable is converted based on the
standard http://us2.php.net/manual/en/language.types.type-juggling.php
type juggling rules, but the variable is attempted to be converted to
a numeric type if it is not already one (based on the string
conversion to numbers rules:
http://us2.php.net/manual/en/language.types.string.php#language.types.string.conversion
)... I will refer to this as "Numeric Type Juggling" as we go on.
Note that objects cannot be used in this manner today, as they do not
implement the get() object handler, so they are converted to int(1) in
this context (which is defined as undefined by documentation). Also
note, that the string is cast to a number destructively. So if you do
1 + "foo", you'll get 1 back without error or warning.

If I use a variable in a string context, the type juggling rules still
apply, but this time converting to a string if it is not already one.
This I think is the most straight forward (and sanest) of all the type
rules. I will refer to this as "String Type Juggling" as we go
forward. Note that object can be used in this context now, based on
the __toString method.

If I use a variable in a boolean context, the type juggling rules
still apply. So I can do if (array()), and the array will be
internally cast to a boolean to be evaluated. Let's call this
"Boolean Type Juggling"...

If I cast a variable to an array, it follows a standard conversion
policy which is documented here:
http://us2.php.net/manual/en/language.types.array.php#language.types.array.casting
I'll call this "Array Type Juggling"...

If I pass a variable to an internal function that expects a string
type, the "String Type Juggling" rules apply.

If I pass a variable to an internal function that expects a class, it
will convert the variable to a string, and then lookup the class to
see if it's valid. This is the same as String Type Juggling...

If I cast a variable to an object, it follows the documented casting
rules. Let's call this "Object Type Juggling".

If I pass a variable to an external function that expects a class,
let's call this "Object Hinted Type Juggling"...

If I pass a variable to an internal function that expects a callback,
it will try to see if it's a valid callback by running logic if it's a
String, Array or Object. Other types are ignored and error out.
Let's call this "Callback
That's where the sanity ends...

If I pass a variable to an internal function that expects an integer
or float, some weird things happen. If the argument is a float, it's
cast to an integer. If it's an integer, null, or boolean, it's
converted directly to an integer. But if it's an array, object or
resource, it causes an error. Up to now, it seems sane and right
inline with "Numeric Type Juggling". Except that strings behave
differently. If the string is numeric (passes the is_numeric() test),
then the string will be cast to an integer and proceed as expected.
But if it is not, a warning is thrown and the internal function errors
out. This is quite different than "Numeric Type Juggling", so I'll
call it "Numeric Internal Parameter Type Juggling".

If I pass a variable to an internal function that expects a boolean,
it sort-of works. I can pass integers, strings, floats, and booleans,
and have normal type conversion rules apply. But if I pass in an
array, object or resource, then it will error out. So the type
juggling rules work for primitives, but not for complex types, which
is different from "Boolean Type Juggling", so we'll call it "Boolean
Internal Parameter Type Juggling".

If I pass a variable to an internal function that expects an array, it
will error out if not. It will not even attempt a cast, which is
quite different from "Array Type Juggling". So let's call this "Array
Internal Parameter Type Juggling" (even though it doesn't juggle
anything)...

If I pass a variable to an internal function that expects a hash table
it can conditionally accept an object (as long as the hash table param
is defined as a capital H). This is even more different than arrays,
so "Hash Table Internal Parameter Type Jugging"...

If I pass a variable to an internal function that expects an object,
it will error if it's not an object with no casting attempt. Let's
call this "Object Internal Parameter Type Juggling".


So in reality, there are tons of different rules and cases on how this
happens.

But the odd thing is that while we can wrap internal functions, we
cannot use the same casting rules as they can. So writing a wrapper
for substr is non-trivial. You **HAVE** to:

function mysubstr($string, $from, $to = 0) {
if (!is_numeric($from)) {
throw new Exception('From Must Be Numeric');
}
if (!is_numeric($to)) {
throw new Exception('To Must Be Numeric');
}
return substr($string, $from, $to);
}

Otherwise your code will possibly throw errors.

So to bring consistency in, what I would like to do is have the
ability to add the same type hints (with the same casting rules) that
zend_parse_parameters has into userland code. So, have the ability to
do:

function (string $string, int $from, int $to = 0) {
}

And have the exact same functionality occur as happens with internal
functions. That will do two things: make internal code and user-land
code behave consistently when it comes to type juggling, and make it
easier to extend internal functionality transparently without tons of
boilerplate code...

Thoughts?

Anthony


On Thu, Mar 1, 2012 at 6:10 AM, Kiall Mac Innes <[email protected]> wrote:
> On Thu, Mar 1, 2012 at 9:00 AM, Lester Caine <[email protected]> wrote:
>
>> Both provide something that a large number of people did not or do not
>> want anything to do with.
>>
>
> I disagree - The majority of PHP developers I've discussed this with are
> in favor of adding *something *like this. Do a majority want this? I have
> no idea and, I honestly don't believe you do either.
>
>
>> Namespace was forced on us in much the same way you are currently trying
>> to force this on us.
>>
>
> Forced? Nobody is forcing anything. Discussions are happening, and possibly
> a vote in the future. This is the farthest thing from being forced IMO.
>
>
>> Many people who were pursuaded that namespace was a good idea are now
>> realising that it wasn't and was the thin end of wedge which this
>> discussion is once again trying to force open.
>>
>
> Many of the popular frameworks have made the changes, or are planning to
> make the changes, needed to take advantage of namespaces. This, to me,
> suggests a general acceptable of namespaces.
>
> Also - I'm yet to hear a single complaint about namespaces
> - although again, I've not talked to every PHP developer!
>
> (Well.. No complaints other than the namespace separator being a '\' that
> is)
>
>
>> I have no objections to 'object orientated' as that is how I have always
>> used PHP, but the BULK of the data I am handling is simply strings which
>> 'magically' get converted to the format I need. I don't see any use for
>> 'type hinting' in any form since I NEED to check if a string I get in has
>> the right data in before I store it in a database field. I don't need to
>> throw some random error which needs handling ... I just handle the errors
>> in line as I process the data. My framework helps to ensure what I get in
>> is right in the first place anyway, so even the in-line checks are probably
>> redundant nowadays!
>>
>
> I can certainly agree with you here - have I ever absolutely NEEDED this?
> Nope. Would it get it the way of writing code in certain situations? Yup.
>
> But - Does that mean it's not generally useful? Nope!
>
> Kiall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> > > From: Richard Lynch [mailto:[email protected]]
> > > On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> > > > I'm beginning to think that the type hinting question is too closely
> > > > related to the dirty secrets of type juggling to resolve them
> > > > separately. You may have to either discard consistency, or else fix
> > > > the problem of silent bizarre conversions at the same time ('foo'==0,
> > > > '123abc'=123). Fixing the conversions is a BC break though.
> > >
> > > [short version]
> > > One man's "fixing" is another man's "feature" :-)
> > >
> > > Old hands can now hit delete while I wax philosophical.
> >
> > The operative word was "silent". The actual behavior is fine, but the
> > silence is unexpected. For example, PHP happily accepts substr('foo',
> > 'bar') with no complaint at all. From a purely philosophical perspective I
> > think almost everyone would expect *at least* a strict notice.
> >
> > On a practical level, we have a major barrier and we'll have to decide how
> > to handle it. As I see it we could do one of the following:
> > 1. Discard consistency (!!)
> > 2. Try to convince people to make these bizarre conversions not silent (BC
> > break)
> > 3. Try to find a creative solution to be consistent without changing
> > anything about the conversion behavior. (I'm not seeing a way to do this
> > one, unless we redefine "consistent".)
> >
> > John Crenshaw
> > Priacta, Inc.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick <simo[email protected]> wrote:
> Hi, John
>
> Just to add an idea to yours ..
>
> Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
> or E_WARNING if we f.e. try to give a string to a method that just allows
> integer for this argument?
> No break at all, just a E_NOTICE or E_WARNING as the script can succeed
> anyways.
> Perhaps I missed something, but since 5.3, the new parameter parsing API
> throws a Warning when types are not strictly honored.
> This has been a major feature in favor of "cleaner" programming.
>
> Try substr('foo', 'bar'), in PHP >= 5.3 and you get a warning and the
> function returns null.
>
> Julien.P
>
> Bye
> Simon
>

Ah, didn't notice the *new* behavior. That simplifies things substantially.

I also had another realization today, which is that there's already strong precedent for treating parameter hints more aggressively than a type cast. For example, you can cast between arrays and objects, with no errors, but the type hints will still generate errors. I think this settles the consistency issue for me.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

@Lester Well there's another logical fallacy. How, exactly, am I trying to
"force" this on anyone? Last time I checked, the PHP community has a
voting process that requires a 2/3 majority for anything touching the
code. Also, last time I checked, there are numerous people who do want
this, so I would definitely dispute some of the claims that this is "dead
in the water" so-to-speak.

This has nothing whatsoever to do with implementing namespaces. That's a
non-sequitur. Drawing a comparison because they both happen to be
controversial ideas would be like me comparing you to Joseph Stalin because
you both happen to breathe oxygen. The fact alone that something is
controversial does not automatically mean it's a bad idea. Likewise, the
fact that namespaces turned out to have unanticipated results does not mean
that the same will happen with this.


--Kris


On Thu, Mar 1, 2012 at 10:06 AM, Anthony Ferrara <[email protected]>wrote:

> Here's one thing to consider. Right now casting/type-autoconversion
> is inconsistent at best. Let me show you what I mean:
>
> If I add 1 to a variable, the variable is converted based on the
> standard http://us2.php.net/manual/en/language.types.type-juggling.php
> type juggling rules, but the variable is attempted to be converted to
> a numeric type if it is not already one (based on the string
> conversion to numbers rules:
>
> http://us2.php.net/manual/en/language.types.string.php#language.types.string.conversion
> )... I will refer to this as "Numeric Type Juggling" as we go on.
> Note that objects cannot be used in this manner today, as they do not
> implement the get() object handler, so they are converted to int(1) in
> this context (which is defined as undefined by documentation). Also
> note, that the string is cast to a number destructively. So if you do
> 1 + "foo", you'll get 1 back without error or warning.
>
> If I use a variable in a string context, the type juggling rules still
> apply, but this time converting to a string if it is not already one.
> This I think is the most straight forward (and sanest) of all the type
> rules. I will refer to this as "String Type Juggling" as we go
> forward. Note that object can be used in this context now, based on
> the __toString method.
>
> If I use a variable in a boolean context, the type juggling rules
> still apply. So I can do if (array()), and the array will be
> internally cast to a boolean to be evaluated. Let's call this
> "Boolean Type Juggling"...
>
> If I cast a variable to an array, it follows a standard conversion
> policy which is documented here:
>
> http://us2.php.net/manual/en/language.types.array.php#language.types.array.casting
> I'll call this "Array Type Juggling"...
>
> If I pass a variable to an internal function that expects a string
> type, the "String Type Juggling" rules apply.
>
> If I pass a variable to an internal function that expects a class, it
> will convert the variable to a string, and then lookup the class to
> see if it's valid. This is the same as String Type Juggling...
>
> If I cast a variable to an object, it follows the documented casting
> rules. Let's call this "Object Type Juggling".
>
> If I pass a variable to an external function that expects a class,
> let's call this "Object Hinted Type Juggling"...
>
> If I pass a variable to an internal function that expects a callback,
> it will try to see if it's a valid callback by running logic if it's a
> String, Array or Object. Other types are ignored and error out.
> Let's call this "Callback
> That's where the sanity ends...
>
> If I pass a variable to an internal function that expects an integer
> or float, some weird things happen. If the argument is a float, it's
> cast to an integer. If it's an integer, null, or boolean, it's
> converted directly to an integer. But if it's an array, object or
> resource, it causes an error. Up to now, it seems sane and right
> inline with "Numeric Type Juggling". Except that strings behave
> differently. If the string is numeric (passes the is_numeric() test),
> then the string will be cast to an integer and proceed as expected.
> But if it is not, a warning is thrown and the internal function errors
> out. This is quite different than "Numeric Type Juggling", so I'll
> call it "Numeric Internal Parameter Type Juggling".
>
> If I pass a variable to an internal function that expects a boolean,
> it sort-of works. I can pass integers, strings, floats, and booleans,
> and have normal type conversion rules apply. But if I pass in an
> array, object or resource, then it will error out. So the type
> juggling rules work for primitives, but not for complex types, which
> is different from "Boolean Type Juggling", so we'll call it "Boolean
> Internal Parameter Type Juggling".
>
> If I pass a variable to an internal function that expects an array, it
> will error out if not. It will not even attempt a cast, which is
> quite different from "Array Type Juggling". So let's call this "Array
> Internal Parameter Type Juggling" (even though it doesn't juggle
> anything)...
>
> If I pass a variable to an internal function that expects a hash table
> it can conditionally accept an object (as long as the hash table param
> is defined as a capital H). This is even more different than arrays,
> so "Hash Table Internal Parameter Type Jugging"...
>
> If I pass a variable to an internal function that expects an object,
> it will error if it's not an object with no casting attempt. Let's
> call this "Object Internal Parameter Type Juggling".
>
>
> So in reality, there are tons of different rules and cases on how this
> happens.
>
> But the odd thing is that while we can wrap internal functions, we
> cannot use the same casting rules as they can. So writing a wrapper
> for substr is non-trivial. You **HAVE** to:
>
> function mysubstr($string, $from, $to = 0) {
> if (!is_numeric($from)) {
> throw new Exception('From Must Be Numeric');
> }
> if (!is_numeric($to)) {
> throw new Exception('To Must Be Numeric');
> }
> return substr($string, $from, $to);
> }
>
> Otherwise your code will possibly throw errors.
>
> So to bring consistency in, what I would like to do is have the
> ability to add the same type hints (with the same casting rules) that
> zend_parse_parameters has into userland code. So, have the ability to
> do:
>
> function (string $string, int $from, int $to = 0) {
> }
>
> And have the exact same functionality occur as happens with internal
> functions. That will do two things: make internal code and user-land
> code behave consistently when it comes to type juggling, and make it
> easier to extend internal functionality transparently without tons of
> boilerplate code...
>
> Thoughts?
>
> Anthony
>
>
> On Thu, Mar 1, 2012 at 6:10 AM, Kiall Mac Innes <[email protected]>
> wrote:
> > On Thu, Mar 1, 2012 at 9:00 AM, Lester Caine <[email protected]> wrote:
> >
> >> Both provide something that a large number of people did not or do not
> >> want anything to do with.
> >>
> >
> > I disagree - The majority of PHP developers I've discussed this with are
> > in favor of adding *something *like this. Do a majority want this? I have
> > no idea and, I honestly don't believe you do either.
> >
> >
> >> Namespace was forced on us in much the same way you are currently trying
> >> to force this on us.
> >>
> >
> > Forced? Nobody is forcing anything. Discussions are happening, and
> possibly
> > a vote in the future. This is the farthest thing from being forced IMO.
> >
> >
> >> Many people who were pursuaded that namespace was a good idea are now
> >> realising that it wasn't and was the thin end of wedge which this
> >> discussion is once again trying to force open.
> >>
> >
> > Many of the popular frameworks have made the changes, or are planning to
> > make the changes, needed to take advantage of namespaces. This, to me,
> > suggests a general acceptable of namespaces.
> >
> > Also - I'm yet to hear a single complaint about namespaces
> > - although again, I've not talked to every PHP developer!
> >
> > (Well.. No complaints other than the namespace separator being a '\' that
> > is)
> >
> >
> >> I have no objections to 'object orientated' as that is how I have always
> >> used PHP, but the BULK of the data I am handling is simply strings which
> >> 'magically' get converted to the format I need. I don't see any use for
> >> 'type hinting' in any form since I NEED to check if a string I get in
> has
> >> the right data in before I store it in a database field. I don't need to
> >> throw some random error which needs handling ... I just handle the
> errors
> >> in line as I process the data. My framework helps to ensure what I get
> in
> >> is right in the first place anyway, so even the in-line checks are
> probably
> >> redundant nowadays!
> >>
> >
> > I can certainly agree with you here - have I ever absolutely NEEDED this?
> > Nope. Would it get it the way of writing code in certain situations? Yup.
> >
> > But - Does that mean it's not generally useful? Nope!
> >
> > Kiall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

On Thu, 01 Mar 2012 20:51:17 +0100, Kris Craig <[email protected]>
wrote:

> @Lester Well there's another logical fallacy. How, exactly, am I trying
> to "force" this on anyone? Last time I checked, the PHP community has a
> voting process that requires a 2/3 majority for anything touching the
> code. Also, last time I checked, there are numerous people who do want
> this, so I would definitely dispute some of the claims that this is "dead
> in the water" so-to-speak.
>
> [...]

Seeing the same issues relitigated all over again in absurdly long threads
is annoying, but seeing these meta-discussions is exasperating (I've lost
the count of the number of e-mails just speculating about the likelihood
of success of such a proposal).

So please, by all means come up with an actual proposal (implementation
included) and take it to a vote, but stop these meta-discussions and avoid
recycling arguments just so you can have the last word.

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
>> You might consider those scripts poor programming practice. We all
>> do.
>> But PHP is the language of the unwashed masses, and that was, and
>> is,
>> part of why it is hugely popular. Somebody who barely understands
>> programming can pound away at the keyboard and write a bloody useful
>> web application, breaking 10,000 Computer Science rules along the
>> way.
>
> And in 20 minutes I can hack into that application 20 different ways.
> This isn't really PHP's fault...or is it? By deliberately catering to
> the lowest possible denominator is it possible that PHP itself
> contributes to the proliferation of wildly insecure web sites? I do
> understand the "unwashed masses" argument, and yet, the security geek
> in me sometimes questions how "good" this is.
>
> (Before someone flames me, I'm not really saying that we should scrap
> any foundational principles or tell basic users to go hang themselves.
> This is mostly philosophical musing.)

We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.

Even if all they understand is "Don't do this!" it's good enough for
most of them.

Other times the decision was made to just deprecate a "feature" and
provide a migration path, if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
[This is the bit where a LOT of scripted edumacation has to happen.)
PHP x+2.0 Feature is just gone.

People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much you can do without making life miserable for a
bazillion developers.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi, John

Therefore I think it would be easy to explain how a type-hint for scalar
could work.

You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:

function foo_one(scalar $bar) {}

function foo_two($bar) {
if (!is_scalar($bar))
trigger_error("Catchable fatal error: Argument ? passed to ? must be a
scalar, ? given,", E_RECOVERABLE_ERROR);
}

The error-message is just an example - but that would keep the three
type-hint possibilities in one and the same functionality - like just
allowing exactly this type.
You cannot even pass a class that extends* ArrayIterator *into a property
that requires an array. So I think we should also here (at least for
scalar) do a really strict thing.

Bye
Simon

2012/3/1 John Crenshaw <[email protected]>

> > > > From: Richard Lynch [mailto:[email protected]]
> > > > On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> > > > > I'm beginning to think that the type hinting question is too
> closely
> > > > > related to the dirty secrets of type juggling to resolve them
> > > > > separately. You may have to either discard consistency, or else fix
> > > > > the problem of silent bizarre conversions at the same time
> ('foo'==0,
> > > > > '123abc'=123). Fixing the conversions is a BC break though.
> > > >
> > > > [short version]
> > > > One man's "fixing" is another man's "feature" :-)
> > > >
> > > > Old hands can now hit delete while I wax philosophical.
> > >
> > > The operative word was "silent". The actual behavior is fine, but the
> > > silence is unexpected. For example, PHP happily accepts substr('foo',
> > > 'bar') with no complaint at all. From a purely philosophical
> perspective I
> > > think almost everyone would expect *at least* a strict notice.
> > >
> > > On a practical level, we have a major barrier and we'll have to decide
> how
> > > to handle it. As I see it we could do one of the following:
> > > 1. Discard consistency (!!)
> > > 2. Try to convince people to make these bizarre conversions not silent
> (BC
> > > break)
> > > 3. Try to find a creative solution to be consistent without changing
> > > anything about the conversion behavior. (I'm not seeing a way to do
> this
> > > one, unless we redefine "consistent".)
> > >
> > > John Crenshaw
> > > Priacta, Inc.
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
> > On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick <
> [email protected]> wrote:
> > Hi, John
> >
> > Just to add an idea to yours ..
> >
> > Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
> > or E_WARNING if we f.e. try to give a string to a method that just allows
> > integer for this argument?
> > No break at all, just a E_NOTICE or E_WARNING as the script can succeed
> > anyways.
> > Perhaps I missed something, but since 5.3, the new parameter parsing API
> > throws a Warning when types are not strictly honored.
> > This has been a major feature in favor of "cleaner" programming.
> >
> > Try substr('foo', 'bar'), in PHP >= 5.3 and you get a warning and the
> > function returns null.
> >
> > Julien.P
> >
> > Bye
> > Simon
> >
>
> Ah, didn't notice the *new* behavior. That simplifies things substantially.
>
> I also had another realization today, which is that there's already strong
> precedent for treating parameter hints more aggressively than a type cast.
> For example, you can cast between arrays and objects, with no errors, but
> the type hints will still generate errors. I think this settles the
> consistency issue for me.
>
> John Crenshaw
> Priacta, Inc.
>

From: Simon Schick [mailto:[email protected]]
>
> Hi, John
>
> Therefore I think it would be easy to explain how a type-hint for scalar could work.
>
> You can explain it as saying that the following two functions should be end up in exactly the same result, whatever you're pasting into:
>
> function foo_one(scalar $bar) {}
>
> function foo_two($bar) {
>  if (!is_scalar($bar))
>    trigger_error("Catchable fatal error: Argument ? passed to ? must be a scalar, ? given,", E_RECOVERABLE_ERROR);
> }

Type hints that only ensure that something is a scalar are a non-starter for me. I'm not going to waste my time on something like that. You're not going to get any better core support with this, and you'll alienate support from a majority of userland as well. The average function doesn't need "just a scalar, but any scalar will do". Most functions need something specific, like a string, or a number. sqrt('foo') doesn't make any sense, it needs a number, not just a scalar.

John Crenshaw
Priacta, Inc.

From: Richard Lynch [mailto:[email protected]]
> On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
> >> You might consider those scripts poor programming practice. We all
> >> do.
> >> But PHP is the language of the unwashed masses, and that was, and is,
> >> part of why it is hugely popular. Somebody who barely understands
> >> programming can pound away at the keyboard and write a bloody useful
> >> web application, breaking 10,000 Computer Science rules along the
> >> way.
> >
> > And in 20 minutes I can hack into that application 20 different ways.
> > This isn't really PHP's fault...or is it? By deliberately catering to
> > the lowest possible denominator is it possible that PHP itself
> > contributes to the proliferation of wildly insecure web sites? I do
> > understand the "unwashed masses" argument, and yet, the security geek
> > in me sometimes questions how "good" this is.
> >
> > (Before someone flames me, I'm not really saying that we should scrap
> > any foundational principles or tell basic users to go hang themselves.
> > This is mostly philosophical musing.)
>
> We make concerted efforts to educate scripters, by posting the same thing in all our blogs.
>
> Even if all they understand is "Don't do this!" it's good enough for most of them.
>
> Other times the decision was made to just deprecate a "feature" and provide a migration path,
> if suitable, but spread out over major
> releases:
> PHP x.0: Feature is bad, but there
> PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP) [This is the bit
> where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone.
>
> People who completely ignore docs or don't upgrade remain vulnerable, but there's not much
> you can do without making life miserable for a bazillion developers.

No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine.

This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the "unwashed masses" as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the "usefulness" test for most
people.

--Kris


On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw <[email protected]>wrote:

> From: Richard Lynch [mailto:[email protected]]
> > On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
> > >> You might consider those scripts poor programming practice. We all
> > >> do.
> > >> But PHP is the language of the unwashed masses, and that was, and is,
> > >> part of why it is hugely popular. Somebody who barely understands
> > >> programming can pound away at the keyboard and write a bloody useful
> > >> web application, breaking 10,000 Computer Science rules along the
> > >> way.
> > >
> > > And in 20 minutes I can hack into that application 20 different ways.
> > > This isn't really PHP's fault...or is it? By deliberately catering to
> > > the lowest possible denominator is it possible that PHP itself
> > > contributes to the proliferation of wildly insecure web sites? I do
> > > understand the "unwashed masses" argument, and yet, the security geek
> > > in me sometimes questions how "good" this is.
> > >
> > > (Before someone flames me, I'm not really saying that we should scrap
> > > any foundational principles or tell basic users to go hang themselves.
> > > This is mostly philosophical musing.)
> >
> > We make concerted efforts to educate scripters, by posting the same
> thing in all our blogs.
> >
> > Even if all they understand is "Don't do this!" it's good enough for
> most of them.
> >
> > Other times the decision was made to just deprecate a "feature" and
> provide a migration path,
> > if suitable, but spread out over major
> > releases:
> > PHP x.0: Feature is bad, but there
> > PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
> [This is the bit
> > where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is
> just gone.
> >
> > People who completely ignore docs or don't upgrade remain vulnerable,
> but there's not much
> > you can do without making life miserable for a bazillion developers.
>
> No, you've misunderstood. The average new not-really-a-developer has no
> concept of security. Every SQL query they write is vulnerable to injection.
> Every echo exposes their site to XSS vulnerabilities. Every form is
> vulnerable to CSRF. If they did anything with files in their script I may
> be able to read arbitrary files to their server and/or upload and execute
> arbitrary scripts. If they used eval() or system() I can probably execute
> arbitrary shell code and take control of the entire site. If their server
> is badly configured I could capture the entire machine.
>
> This isn't a question of keeping software updated and not using deprecated
> functions, this is a question of discipline that is completely missing
> among the "unwashed masses" as you call them. The intuitive way to handle
> many of the most common PHP tasks is also the completely insecure way.
> Philosophically, I wonder if we do a great disservice by encouraging these
> people to tinker with code at all. We do so knowing (or at least we should
> know) that anything they create will inevitably be hacked. We fuel the
> widespread security problems that currently plague the web.
>
> John Crenshaw
> Priacta, Inc.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>