[PHP-DEV] Scalar type hinting

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Ronald Chmara — Fri, 02 Mar 2012 12:20:33 +0100

On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw wrote:
> 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.
>

PHP is as vulnerable as you make it,

> 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

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Simon Schick — Fri, 02 Mar 2012 11:40:03 +0100

Hi, All

Let me update my last functions as I got an inspiration from Anthony and
his proof-of-concept:

foo( (boolean) $b, (integer) $i, (float) $f, (string) $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;

// your code
}

Now here a rule I thought could be acceptable to differ between the
type-hint for classes and arrays and this notation:
If the type is wrapped in parentheses, the system will try to convert the
given value. Otherwise it will handle it strict.

Strict is currently only available for classes and arrays, and I don't want
to get more things in this list (excepted by resources, what is the last
what would make sense here).
Dynamic (the one with the parentheses) could then well be something like
boolean, integer, float, string and array. Array is also in this list as I
would like to have an option to give an object in here that implements all
interfaces that makes an object accessible as an array - for example
ArrayIterator.

Bye
Simon

2012/3/2 Simon Schick

> Hi, Kris
>
> I have to confirm that that's not really what I wanted.
> But many people were now talking about type-hint to scalar, but that was
> maybe in another thread in this list :)
>
> To get more to the point what were discussing about want:
> Why not always (at least try) to transform the data?
>
> In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
> * Changed silent conversion of array to string to produce a notice.
> * Changed silent casting of null/''/false into an Object when adding a
> property into a warning.
>
> I would suppose to add a type-hint for the following types:
> * Boolean
> * integer
> * float
> * string
>
> Here's the last state what I thought about these type-hints ...
> Both of the given examples here should give the same result:
>
> foo(boolean $b, integer $i, float $f, string $s) {
> // your code
> }
> foo2($b, $i, $f, $s) {
> $b = (boolean)$b;
> $i = (integer)$i;
> $f = (float)$f;
> $s = (string)$s;
>
> // your code
> }
>
> If you view it from that site - you can't get an array to do what you can
> do with an object. Therefore I think it's quite OK to break the script
> there, but here, as you can transform the values, I'd (at least try to)
> transform the given data into the expected format.
> The only thing I'm quite unsure about - should we trigger a E_WARNING or
> E_NOTICE if we have data-loose in this transformation? Just let it pass as
> it's transformable, but trigger some error ...
> If you want to get a warning or notice in the function *foo2* then open a
> new thread, as I think that should not be discussed here. It affects much
> more than just the function-call.
>
> p.s. What about adding another type-hint for resources?
> That's something we could check by *is_resource()* and it would make
> sense (at least to me).
>
> Bye
> Simon
>
>
> 2012/3/2 Kris Craig
>
>> 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 >> >wrote:
>>
>> > From: Richard Lynch [mailto:ceo@l-i-e.com]
>> > > 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
>> >
>> >
>>
>
>

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Simon Schick — Fri, 02 Mar 2012 10:11:08 +0100

Hi, Kris

I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)

To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?

In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
* Changed silent conversion of array to string to produce a notice.
* Changed silent casting of null/''/false into an Object when adding a
property into a warning.

I would suppose to add a type-hint for the following types:
* Boolean
* integer
* float
* string

Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:

foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;

// your code
}

If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger a E_WARNING or
E_NOTICE if we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function *foo2* then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.

p.s. What about adding another type-hint for resources?
That's something we could check by *is_resource()* and it would make sense
(at least to me).

Bye
Simon

2012/3/2 Kris Craig

> 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 > >wrote:
>
> > From: Richard Lynch [mailto:ceo@l-i-e.com]
> > > 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
> >
> >
>

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Kris Craig — Fri, 02 Mar 2012 02:30:46 +0100

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 wrote:

> From: Richard Lynch [mailto:ceo@l-i-e.com]
> > 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
>
>

RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

John Crenshaw — Fri, 02 Mar 2012 01:21:18 +0100

From: Richard Lynch [mailto:ceo@l-i-e.com]
> 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

RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

John Crenshaw — Fri, 02 Mar 2012 01:21:18 +0100

From: Simon Schick [mailto:simonsimcity@googlemail.com]
>
> 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.

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Simon Schick — Fri, 02 Mar 2012 00:40:31 +0100

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

> > > > From: Richard Lynch [mailto:ceo@l-i-e.com]
> > > > 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 <
> simonsimcity@googlemail.com> 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.
>

RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Richard Lynch — Thu, 01 Mar 2012 22:50:19 +0100

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

Re: [PHP-DEV] Scalar type hinting

Gustavo Lopes — Thu, 01 Mar 2012 21:12:00 +0100

On Thu, 01 Mar 2012 20:51:17 +0100, Kris Craig
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

Re: [PHP-DEV] Scalar type hinting

Kris Craig — Thu, 01 Mar 2012 21:00:24 +0100

@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 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
> wrote:
> > On Thu, Mar 1, 2012 at 9:00 AM, Lester Caine 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
>
>

RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

John Crenshaw — Thu, 01 Mar 2012 20:45:05 +0100

> > > From: Richard Lynch [mailto:ceo@l-i-e.com]
> > > 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 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

Re: [PHP-DEV] Scalar type hinting

Anthony Ferrara — Thu, 01 Mar 2012 19:11:12 +0100

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 wrote:
> On Thu, Mar 1, 2012 at 9:00 AM, Lester Caine 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

Re: [PHP-DEV] Scalar type hinting

Kiall Mac Innes — Thu, 01 Mar 2012 12:20:53 +0100

On Thu, Mar 1, 2012 at 9:00 AM, Lester Caine 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

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

jpauli — Thu, 01 Mar 2012 12:10:35 +0100

On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick 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
>
> > > From: Richard Lynch [mailto:ceo@l-i-e.com]
> > > 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
> >
> >
>

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Lazare Inepologlou — Thu, 01 Mar 2012 10:12:01 +0100

> 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

> From: Simon Schick [mailto:simonsimcity@googlemail.com]
> >
> > 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.
>

Re: [PHP-DEV] Scalar type hinting

Lester Caine — Thu, 01 Mar 2012 10:12:00 +0100

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

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Pierre Joye — Thu, 01 Mar 2012 10:12:00 +0100

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 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

RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

John Crenshaw — Thu, 01 Mar 2012 10:12:00 +0100

From: Simon Schick [mailto:simonsimcity@googlemail.com]
>
> 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.

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Simon Schick — Thu, 01 Mar 2012 10:00:20 +0100

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

> > From: Richard Lynch [mailto:ceo@l-i-e.com]
> > 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
>
>

RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

John Crenshaw — Thu, 01 Mar 2012 09:50:50 +0100

> From: Richard Lynch [mailto:ceo@l-i-e.com]
> 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

RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Arvids Godjuks — Thu, 01 Mar 2012 09:50:50 +0100

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

RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

John Crenshaw — Thu, 01 Mar 2012 09:40:08 +0100

> 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

Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Kris Craig — Thu, 01 Mar 2012 04:20:25 +0100

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 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
>
>

Re: [PHP-DEV] Scalar type hinting

Kris Craig — Thu, 01 Mar 2012 04:20:24 +0100

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

--Kris

On Wed, Feb 29, 2012 at 7:01 PM, Kris Craig 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 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
>>
>>
>

[PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

Richard Lynch — Thu, 01 Mar 2012 04:20:24 +0100

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

Re: [PHP-DEV] Scalar type hinting

Kris Craig — Thu, 01 Mar 2012 04:20:24 +0100

@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 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
>
>

Re: [PHP-DEV] Scalar type hinting

Richard Lynch — Thu, 01 Mar 2012 03:41:24 +0100

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

Re: [PHP-DEV] Scalar type hinting

Adam Jon Richardson — Thu, 01 Mar 2012 03:00:43 +0100

On Wed, Feb 29, 2012 at 8:46 PM, Kris Craig 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 > >wrote:
>
> > > -----Original Message-----
> > > From: Kris Craig [mailto:kris.craig@gmail.com]
> > >
> > > @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

Re: [PHP-DEV] Scalar type hinting

Kris Craig — Thu, 01 Mar 2012 02:50:27 +0100

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 wrote:

> > -----Original Message-----
> > From: Kris Craig [mailto:kris.craig@gmail.com]
> >
> > @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.
>

RE: [PHP-DEV] Scalar type hinting

John Crenshaw — Thu, 01 Mar 2012 02:21:24 +0100

> -----Original Message-----
> From: Kris Craig [mailto:kris.craig@gmail.com]
>
> @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