[PHP-DEV] Scalar type hinting

> int $a = "1"; // no error. 1 == "1" so who cares?
> int $a = 'House'; // error 0 != 'House', so this is a problem.

For the sake of consistency, please take into account this example, which
works in the current implementation of PHP:

$b = 1 + "1"; // no error, $b == 2
$b = 1 + "House"; // no error, $b == 1

So, I believe that, raising an error or not, is not a question of the new
RFC.

Should there be an error, then it has to be in every unsuccessful type
juggling, regardless of the final assignment to a type-locked variable.


Lazare INEPOLOGLOU
Ingénieur Logiciel


2012/2/29 Michael Morris <[email protected]>

> Agreed. If conversion can occur without data loss (that is, if the
> value being assigned is == the value that actually IS assigned) then
> no error should occur.
>
> So
>
> int $a = "1"; // no error. 1 == "1" so who cares?
> int $a = 'House'; // error 0 != 'House', so this is a problem.
>
> Again, errors should only raise if the final value != source value.
>
> On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer <[email protected]>
> wrote:
> > On 2/28/2012 2:58 PM, Kris Craig wrote:
> >
> >> strong int $a = "1"; // Converts to 1. May or may not throw an error
> (I'm
> >> still on the fence).
> >
> >
> > It this is an error, it is no longer PHP.
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:

Some cases I would find interesting to be explained:

(using 'streak' for strong and/or weak, feel free to separate the two)

streak int $i = 123.456; //Common idiom for floor()
streak int $i = "123.456"; //In contrast to previous
streak int $i = "1 "; //value="1 " is ridiculously common HTML

It's all well and good to say that any loss of data is "bad" and to
raise some E_* for it, but there are some idioms so common that feel
"wrong" as I consider them...

If everyone "for" the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I think

wrt E_RECOVERABLE_ERROR vs E_WARNING

If current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new "streak" with it.

I don't even object to using E_ERROR for the "strong" variant, if that
passes review, really, since "strong" is, errr, strong. :-)

Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue after E_ERROR is like
playing russian roulette...

--
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 the notion of typing in function arguments, though I'm not a
fan of this particular approach. Specifically, I don't like the idea of
"1aaa" throwing one kind of error (E_NOTICE) and array($whatever) throwing
another kind of error. They should both throw the same error because
they're both incompatible types; i.e. "1" == 1 but "1aaa" != 1. I don't
like the idea of saying that one incompatible type is "worse" than
another. I just don't see any value in that and it ultimately just makes
things more confusing and complicated than they need to be for the end-user.

Instead, they should both throw the same kind of error. Whether it's just
E_RECOVERABLE_ERROR or we give the developer a choice by having
strong/weak, I'm fine either way (though I think the second approach adds
more flexibility without any practical drawbacks).


And again, let's avoid using phrases like "most people". I'll let
Wikipedia elaborate on why:

http://en.wikipedia.org/wiki/Weasel_word

--Kris


On Wed, Feb 29, 2012 at 2:26 AM, Simon Schick
<[email protected]>wrote:

> Hi, Arvids
>
> I did not meant to putt all in one big RFC but more to think about the
> connection between these two while developing.
>
> Bye
> Simon
>
> 2012/2/29 Arvids Godjuks <[email protected]>
>
> > Combining different things into one big RFC is not a good idea. It's
> > hard to develop and test the work it it's in one big chunk.
> > Decomposition makes it much easier. Type hinting has to have it's own
> > RFC.
> > Besides - someone can be willing to do type hinting patch and don't
> > want to do the object_cast_magic one.
> >
> > And thanks for the support :)
> >
> > 2012/2/29 Simon Schick <[email protected]>:
> > > Hi,
> > >
> > > We could even combine this with the following RFC:
> > > https://wiki.php.net/rfc/object_cast_magic
> > >
> > > If an integer is required and you pass an object, it first checks if
> this
> > > object is castable to integer ;)
> > >
> > > Bye
> > > Simon
> > >
> > > 2012/2/29 Simon Schick <[email protected]>
> > >
> > >> Hi, John
> > >>
> > >> I personally do not care about weak or strong variables at all ... I
> > only
> > >> want what Arvids suggested last time:
> > >>
> > >>
> > >> > test(1, 2); // 2;
> > >> > test("1", 2); // 2
> > >> > test("1aaa", 2); // E_NOTICE or E_TYPE and result 2
> > >> > test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array
> type
> > >> hint now.
> > >> >
> > >> > It's really what the most people want. Simple, easy to pick up
> (object
> > >> > and array already have this) and is just optional.
> > >>
> > >> I count myself as a part of *most people* in this statement ;)
> > >> I'm also quite fine with the current type-hints as you'd anyways get
> an
> > >> error if you try something like this:
> > >>
> > >> function foo(SimpleClass $a) {
> > >> $a->getName();
> > >> }
> > >>
> > >> foo("Test");
> > >>
> > >> If you now get *method called from an non-object* or a message that
> you
> > >> have passed a value that's not compatible with *SimpleClass* ...
> > >>
> > >> I'd like to split this discussion in parts:
> > >>
> > >> - just type-hint in functions (as we have it with classes and
> arrays)
> > >> or bind a variable to a strict type?
> > >> - should it then also be possible bind variables to a specific
> > >> class or interface?
> > >> - should we go for weak or strong types?
> > >> - the type-hint is also weak in one way because it accepts all
> > >> that's compatible with the given type.
> > >>
> > >> Bye
> > >> Simon
> > >>
> > >>
> > >> 2012/2/29 John Crenshaw <[email protected]>
> > >>
> > >>> I would personally be inclined towards something simpler like
> E_NOTICE
> > or
> > >>> E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I
> > think we
> > >>> should be consistent, and the consistency argument may make the
> > difference.
> > >>>
> > >>> There may be a strong case for changing the error level on all type
> > hints
> > >>> to something simpler (or new, like E_TYPE), but I think that might be
> > >>> better to tackle that in a separate discussion.
> > >>>
> > >>> John Crenshaw
> > >>> Priacta, Inc.
> > >>>
> > >>> From: Kris Craig [mailto:[email protected]]
> > >>> Sent: Tuesday, February 28, 2012 8:40 PM
> > >>> To: John Crenshaw
> > >>> Cc: Rick WIdmer; internals@lists.php.net
> > >>> Subject: Re: [PHP-DEV] Scalar type hinting
> > >>>
> > >>> I wouldn't mind that, though I'm concerned that it may not be
> sellable
> > >>> because some people on here have expressed a strong opinion that this
> > >>> shouldn't throw anything more than a notice or a warning at most,
> > something
> > >>> that I and others strongly disagree with. The logical approach, to
> me
> > at
> > >>> least, is to follow the example of include() and require(); i.e.
> > they're
> > >>> both identical except that one throws a scary error while the other
> > one is
> > >>> just a warning.
> > >>>
> > >>> I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that
> may
> > >>> alienate too many people for us to be able to get this through.
> Though
> > >>> it's possible I might be overestimating that factor.
> > >>>
> > >>> --Kris
> > >>>
> > >>> On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw <
> > johncrenshaw@priacta.com
> > >>> <mailto:[email protected]>> wrote:
> > >>> > On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer <
> > vchkpw@developersdesk.com
> > >>> <mailto:[email protected]>>wrote:
> > >>> >
> > >>> > > On 2/28/2012 2:58 PM, Kris Craig wrote:
> > >>> > >
> > >>> > > strong int $a = "1"; // Converts to 1. May or may not throw an
> > error
> > >>> > > (I'm
> > >>> > >> still on the fence).
> > >>> > >>
> > >>> > >
> > >>> > > It this is an error, it is no longer PHP.
> > >>> > >
> > >>> >
> > >>> > @Rick Though I'm not sure I'd agree with the overly broad "it is no
> > >>> longer PHP" hyperbole, I think the basic point that it would be a
> > >>> significant departure from the current model has merit. So ok,
> you've
> > >>> convinced me.
> > >>> That example should not throw any errors. I'm officially no longer
> on
> > >>> the fence with that. =)
> > >>> >
> > >>> > --Kris
> > >>> OK, if we're all on the same page there, I think this means that
> there
> > is
> > >>> no significant difference between the "strong int" and "weak int" in
> > your
> > >>> proposal (the only remaining difference being the level of error
> raised
> > >>> when it cannot be converted, which IMO is not substantial enough to
> > deserve
> > >>> a keyword.) I'd prefer to just pick one error level to use
> > >>> (E_RECOVERABLE_ERROR would be the most consistent) and keep
> everything
> > >>> simple.
> > >>>
> > >>> John Crenshaw
> > >>> Priacta, Inc.
> > >>>
> > >>>
> > >>
> >
>

@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


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

> On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
>
> Some cases I would find interesting to be explained:
>
> (using 'streak' for strong and/or weak, feel free to separate the two)
>
> streak int $i = 123.456; //Common idiom for floor()
> streak int $i = "123.456"; //In contrast to previous
> streak int $i = "1 "; //value="1 " is ridiculously common HTML
>
> It's all well and good to say that any loss of data is "bad" and to
> raise some E_* for it, but there are some idioms so common that feel
> "wrong" as I consider them...
>
> If everyone "for" the new type hinting/forcing can reach consensus on
> these sorts of cases, it would help clarify any RFCs a bit, I think
>
> wrt E_RECOVERABLE_ERROR vs E_WARNING
>
> If current type hinting raises E_RECOVERABLE_ERROR, I have no
> objection to following that lead, with the explicit caveat that a
> change to the existing type-hinting to E_WARNING, as unlikely as that
> seems, would pull the new "streak" with it.
>
> I don't even object to using E_ERROR for the "strong" variant, if that
> passes review, really, since "strong" is, errr, strong. :-)
>
> Anybody who doesn't like the E_* can re-define them in a custom error
> handler anyway, though allowing PHP to continue after E_ERROR is like
> playing russian roulette...
>
> --
> 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
>
>

Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless of
what the incompatible type is. But in the case where a float might sneak
its way into an int, the developer might decide that going with a weak type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).

--Kris


On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig <[email protected]> wrote:

> @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
>
>
>
> On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch <[email protected]> wrote:
>
>> On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
>>
>> Some cases I would find interesting to be explained:
>>
>> (using 'streak' for strong and/or weak, feel free to separate the two)
>>
>> streak int $i = 123.456; //Common idiom for floor()
>> streak int $i = "123.456"; //In contrast to previous
>> streak int $i = "1 "; //value="1 " is ridiculously common HTML
>>
>> It's all well and good to say that any loss of data is "bad" and to
>> raise some E_* for it, but there are some idioms so common that feel
>> "wrong" as I consider them...
>>
>> If everyone "for" the new type hinting/forcing can reach consensus on
>> these sorts of cases, it would help clarify any RFCs a bit, I think
>>
>> wrt E_RECOVERABLE_ERROR vs E_WARNING
>>
>> If current type hinting raises E_RECOVERABLE_ERROR, I have no
>> objection to following that lead, with the explicit caveat that a
>> change to the existing type-hinting to E_WARNING, as unlikely as that
>> seems, would pull the new "streak" with it.
>>
>> I don't even object to using E_ERROR for the "strong" variant, if that
>> passes review, really, since "strong" is, errr, strong. :-)
>>
>> Anybody who doesn't like the E_* can re-define them in a custom error
>> handler anyway, though allowing PHP to continue after E_ERROR is like
>> playing russian roulette...
>>
>> --
>> 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, Kris

I don't think we have to care about scripts that are written right now if
we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.

I personally would keep the error-messages for classes and arrays as they
are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into the
other data-type.

Lets have an example:

function foo(integer $i) {
// do something
}

foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo("1"); // wont throw an error because the transformation into an integer
is loose-less
foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
integer is required here.
foo("horse"); // Throws an E_RECOVERABLE_ERROR because if you transform
"horse" into a float, it's 1 and that's not equal to the string anymore.

I personally would treat float - int miss matches the same way as all other
stuff, because it cannot be converted loose-less.

And if the Object-cast-stuff comes through, we have to think about this in
addition:
https://wiki.php.net/rfc/object_cast_magic

class MyInteger {
public function __castTo(string $type) {
if ($type === "integer")
return 5;
}
}

function foo(integer $i) {
// do something
}

foo(new MyInteger()); // Even if this is an object - it's cast-able to an
integer and therefore should be valid

But this is just in case the RFC gets through ;) We don't have to think
that much about it now - just keep it in mind.

Bye
Simon

2012/2/29 Kris Craig <[email protected]>

> Now that I think of it, this would probably be a good argument for
> differentiating between strong and weak. Looking back to my previous
> comment, it probably would be best to have it behave the same regardless of
> what the incompatible type is. But in the case where a float might sneak
> its way into an int, the developer might decide that going with a weak type
> would make it more flexible (though if it was me, I'd just do a round or
> leave it a mixed type lol).
>
> --Kris
>
>
> On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig <[email protected]> wrote:
>
> > @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
> >
> >
> >
> > On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch <[email protected]> wrote:
> >
> >> On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
> >>
> >> Some cases I would find interesting to be explained:
> >>
> >> (using 'streak' for strong and/or weak, feel free to separate the two)
> >>
> >> streak int $i = 123.456; //Common idiom for floor()
> >> streak int $i = "123.456"; //In contrast to previous
> >> streak int $i = "1 "; //value="1 " is ridiculously common HTML
> >>
> >> It's all well and good to say that any loss of data is "bad" and to
> >> raise some E_* for it, but there are some idioms so common that feel
> >> "wrong" as I consider them...
> >>
> >> If everyone "for" the new type hinting/forcing can reach consensus on
> >> these sorts of cases, it would help clarify any RFCs a bit, I think
> >>
> >> wrt E_RECOVERABLE_ERROR vs E_WARNING
> >>
> >> If current type hinting raises E_RECOVERABLE_ERROR, I have no
> >> objection to following that lead, with the explicit caveat that a
> >> change to the existing type-hinting to E_WARNING, as unlikely as that
> >> seems, would pull the new "streak" with it.
> >>
> >> I don't even object to using E_ERROR for the "strong" variant, if that
> >> passes review, really, since "strong" is, errr, strong. :-)
> >>
> >> Anybody who doesn't like the E_* can re-define them in a custom error
> >> handler anyway, though allowing PHP to continue after E_ERROR is like
> >> playing russian roulette...
> >>
> >> --
> >> 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
> >>
> >>
> >
>

@Simon Agreed. That's pretty much what I'm thinking it should look like.

With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.


I think we're getting pretty close to having enough to write an RFC for
this. I'll go ahead and create one after a little more discussion goes
around.

--Kris


On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick
<[email protected]>wrote:

> Hi, Kris
>
> I don't think we have to care about scripts that are written right now if
> we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
> this feature is completely new. But I like the idea to have all type-hint
> failures ending up the same way.
>
> I personally would keep the error-messages for classes and arrays as they
> are right now and do the same error in case the given value is not
> compatible to the expected type.
> Not compatible means that data gets lost after converting the data into
> the other data-type.
>
> Lets have an example:
>
> function foo(integer $i) {
> // do something
> }
>
> foo(true); // Even if Boolean is a lower type than int, it can be easily
> casted to an int. It's equivalent to 1.
> foo("1"); // wont throw an error because the transformation into an
> integer is loose-less
> foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
> integer is required here.
> foo("horse"); // Throws an E_RECOVERABLE_ERROR because if you transform
> "horse" into a float, it's 1 and that's not equal to the string anymore.
>
> I personally would treat float - int miss matches the same way as all
> other stuff, because it cannot be converted loose-less.
>
> And if the Object-cast-stuff comes through, we have to think about this in
> addition:
> https://wiki.php.net/rfc/object_cast_magic
>
> class MyInteger {
> public function __castTo(string $type) {
> if ($type === "integer")
> return 5;
> }
> }
>
> function foo(integer $i) {
> // do something
> }
>
> foo(new MyInteger()); // Even if this is an object - it's cast-able to an
> integer and therefore should be valid
>
> But this is just in case the RFC gets through ;) We don't have to think
> that much about it now - just keep it in mind.
>
> Bye
> Simon
>
>
> 2012/2/29 Kris Craig <[email protected]>
>
>> Now that I think of it, this would probably be a good argument for
>> differentiating between strong and weak. Looking back to my previous
>> comment, it probably would be best to have it behave the same regardless
>> of
>> what the incompatible type is. But in the case where a float might sneak
>> its way into an int, the developer might decide that going with a weak
>> type
>> would make it more flexible (though if it was me, I'd just do a round or
>> leave it a mixed type lol).
>>
>> --Kris
>>
>>
>> On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig <[email protected]>
>> wrote:
>>
>> > @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
>> >
>> >
>> >
>> > On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch <[email protected]> wrote:
>> >
>> >> On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
>> >>
>> >> Some cases I would find interesting to be explained:
>> >>
>> >> (using 'streak' for strong and/or weak, feel free to separate the two)
>> >>
>> >> streak int $i = 123.456; //Common idiom for floor()
>> >> streak int $i = "123.456"; //In contrast to previous
>> >> streak int $i = "1 "; //value="1 " is ridiculously common HTML
>> >>
>> >> It's all well and good to say that any loss of data is "bad" and to
>> >> raise some E_* for it, but there are some idioms so common that feel
>> >> "wrong" as I consider them...
>> >>
>> >> If everyone "for" the new type hinting/forcing can reach consensus on
>> >> these sorts of cases, it would help clarify any RFCs a bit, I think
>> >>
>> >> wrt E_RECOVERABLE_ERROR vs E_WARNING
>> >>
>> >> If current type hinting raises E_RECOVERABLE_ERROR, I have no
>> >> objection to following that lead, with the explicit caveat that a
>> >> change to the existing type-hinting to E_WARNING, as unlikely as that
>> >> seems, would pull the new "streak" with it.
>> >>
>> >> I don't even object to using E_ERROR for the "strong" variant, if that
>> >> passes review, really, since "strong" is, errr, strong. :-)
>> >>
>> >> Anybody who doesn't like the E_* can re-define them in a custom error
>> >> handler anyway, though allowing PHP to continue after E_ERROR is like
>> >> playing russian roulette...
>> >>
>> >> --
>> >> 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
>> >>
>> >>
>> >
>>
>
>

And here's a thought: I could structure the RFC so that the voting will
have 3 choices: Yes with strong/weak differentiation, yes without
strong/weak, or no. However, the voting RFC doesn't cover how the tally
should be calculated in such a circumstance. For example, let's say we had
8 votes yes with differentiation, 2 votes yes without differentiation, and
5 votes no. If we tally the two "yes" columns, it's 10 - 5, which would be
the required 2/3 majority. However, how would we calculate the mandate on
differentiation? Among those who voted yes, there's a clear 8 - 2 (80%)
majority in favor of it. But if you count the no votes as being no to
differentiation and add them to the total, it suddenly becomes 8 - 7, which
falls short of the 2/3 majority. An argument could be made that these
people who voted no would not want differentiation, but another argument
could be made that; while they don't like the idea, if it does happen
they'd rather have it differentiated than not. In other words, determining
voter intent from that group would be difficult and thus only tallying
among the yes votes would make sense. Both arguments would have about
equal merit I think

The voting RFC does allow for different "options" in the vote, but it does
not elaborate on this. We could break the "no" group into two as well,
though that could make things a bit too confusing.


Since there's presently no clear procedure on this (at least none that I'm
aware of), what are your thoughts on this? I do believe the two should be
in the same vote since they're pretty integral to one another, but I'm not
sure how best to do that while maintaining accurate results without making
it too complicated.

--Kris


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

> @Simon Agreed. That's pretty much what I'm thinking it should look like.
>
> With booleans, I think you have a good point. If 1 or 0 is passed to a
> bool, I'd say that should be fine without an error. If you were to pass a
> 2, though (you insolent bastard!), then it would throw the error.
>
>
> I think we're getting pretty close to having enough to write an RFC for
> this. I'll go ahead and create one after a little more discussion goes
> around.
>
> --Kris
>
>
>
> On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick <
> [email protected]> wrote:
>
>> Hi, Kris
>>
>> I don't think we have to care about scripts that are written right now if
>> we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
>> this feature is completely new. But I like the idea to have all type-hint
>> failures ending up the same way.
>>
>> I personally would keep the error-messages for classes and arrays as they
>> are right now and do the same error in case the given value is not
>> compatible to the expected type.
>> Not compatible means that data gets lost after converting the data into
>> the other data-type.
>>
>> Lets have an example:
>>
>> function foo(integer $i) {
>> // do something
>> }
>>
>> foo(true); // Even if Boolean is a lower type than int, it can be easily
>> casted to an int. It's equivalent to 1.
>> foo("1"); // wont throw an error because the transformation into an
>> integer is loose-less
>> foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
>> integer is required here.
>> foo("horse"); // Throws an E_RECOVERABLE_ERROR because if you transform
>> "horse" into a float, it's 1 and that's not equal to the string anymore.
>>
>> I personally would treat float - int miss matches the same way as all
>> other stuff, because it cannot be converted loose-less.
>>
>> And if the Object-cast-stuff comes through, we have to think about this
>> in addition:
>> https://wiki.php.net/rfc/object_cast_magic
>>
>> class MyInteger {
>> public function __castTo(string $type) {
>> if ($type === "integer")
>> return 5;
>> }
>> }
>>
>> function foo(integer $i) {
>> // do something
>> }
>>
>> foo(new MyInteger()); // Even if this is an object - it's cast-able to
>> an integer and therefore should be valid
>>
>> But this is just in case the RFC gets through ;) We don't have to think
>> that much about it now - just keep it in mind.
>>
>> Bye
>> Simon
>>
>>
>> 2012/2/29 Kris Craig <[email protected]>
>>
>>> Now that I think of it, this would probably be a good argument for
>>> differentiating between strong and weak. Looking back to my previous
>>> comment, it probably would be best to have it behave the same regardless
>>> of
>>> what the incompatible type is. But in the case where a float might sneak
>>> its way into an int, the developer might decide that going with a weak
>>> type
>>> would make it more flexible (though if it was me, I'd just do a round or
>>> leave it a mixed type lol).
>>>
>>> --Kris
>>>
>>>
>>> On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig <[email protected]>
>>> wrote:
>>>
>>> > @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
>>> >
>>> >
>>> >
>>> > On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch <[email protected]> wrote:
>>> >
>>> >> On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
>>> >>
>>> >> Some cases I would find interesting to be explained:
>>> >>
>>> >> (using 'streak' for strong and/or weak, feel free to separate the two)
>>> >>
>>> >> streak int $i = 123.456; //Common idiom for floor()
>>> >> streak int $i = "123.456"; //In contrast to previous
>>> >> streak int $i = "1 "; //value="1 " is ridiculously common HTML
>>> >>
>>> >> It's all well and good to say that any loss of data is "bad" and to
>>> >> raise some E_* for it, but there are some idioms so common that feel
>>> >> "wrong" as I consider them...
>>> >>
>>> >> If everyone "for" the new type hinting/forcing can reach consensus on
>>> >> these sorts of cases, it would help clarify any RFCs a bit, I think
>>> >>
>>> >> wrt E_RECOVERABLE_ERROR vs E_WARNING
>>> >>
>>> >> If current type hinting raises E_RECOVERABLE_ERROR, I have no
>>> >> objection to following that lead, with the explicit caveat that a
>>> >> change to the existing type-hinting to E_WARNING, as unlikely as that
>>> >> seems, would pull the new "streak" with it.
>>> >>
>>> >> I don't even object to using E_ERROR for the "strong" variant, if that
>>> >> passes review, really, since "strong" is, errr, strong. :-)
>>> >>
>>> >> Anybody who doesn't like the E_* can re-define them in a custom error
>>> >> handler anyway, though allowing PHP to continue after E_ERROR is like
>>> >> playing russian roulette...
>>> >>
>>> >> --
>>> >> 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, Kris

As we have some RFCs around that we should update them I think.

In my opinion we should split them up into 3 RFCs (and one grouping RFC):

Weak and strong type-checks (whatever that in detail means) should be
discussed in one single RFC. The option1 in the existing one is pretty
close to what I expect it to be - but why should f.e. "12abc" be a valid
integer? As said - we should update that.
https://wiki.php.net/rfc/typecheckingstrictandweak

Split the following RFC into two RFCs. Parameter type-hint and return
type-hint:
https://wiki.php.net/rfc/typehint

Until now we have two RFCs for return type-hint that should also be
combined. Add the information from the last mentioned here as well:
https://wiki.php.net/rfc/returntypehint2
https://wiki.php.net/rfc/returntypehint

And finally update the grouping-RFC:
https://wiki.php.net/rfc/typechecking

The RFCs for parameter- and return-type-hint should not contain the
definition of strict or weak type-hints.
After all three RFCs have been voted by a bunch of people we can write down
a RFC for a combination - f.e. how it should look like to have weak
function type-hinting or strong return type-hinting.

So .. here's quite a lot of work to do to gather the people who wrote these
RFCs and let their ideas float into one specific definition with several
options how to implement them.

Bye
Simon

2012/2/29 Kris Craig <[email protected]>

> And here's a thought: I could structure the RFC so that the voting will
> have 3 choices: Yes with strong/weak differentiation, yes without
> strong/weak, or no. However, the voting RFC doesn't cover how the tally
> should be calculated in such a circumstance. For example, let's say we had
> 8 votes yes with differentiation, 2 votes yes without differentiation, and
> 5 votes no. If we tally the two "yes" columns, it's 10 - 5, which would be
> the required 2/3 majority. However, how would we calculate the mandate on
> differentiation? Among those who voted yes, there's a clear 8 - 2 (80%)
> majority in favor of it. But if you count the no votes as being no to
> differentiation and add them to the total, it suddenly becomes 8 - 7, which
> falls short of the 2/3 majority. An argument could be made that these
> people who voted no would not want differentiation, but another argument
> could be made that; while they don't like the idea, if it does happen
> they'd rather have it differentiated than not. In other words, determining
> voter intent from that group would be difficult and thus only tallying
> among the yes votes would make sense. Both arguments would have about
> equal merit I think
>
> The voting RFC does allow for different "options" in the vote, but it does
> not elaborate on this. We could break the "no" group into two as well,
> though that could make things a bit too confusing.
>
>
> Since there's presently no clear procedure on this (at least none that I'm
> aware of), what are your thoughts on this? I do believe the two should be
> in the same vote since they're pretty integral to one another, but I'm not
> sure how best to do that while maintaining accurate results without making
> it too complicated.
>
> --Kris
>
>
>
> On Wed, Feb 29, 2012 at 12:18 PM, Kris Craig <[email protected]> wrote:
>
>> @Simon Agreed. That's pretty much what I'm thinking it should look like.
>>
>> With booleans, I think you have a good point. If 1 or 0 is passed to a
>> bool, I'd say that should be fine without an error. If you were to pass a
>> 2, though (you insolent bastard!), then it would throw the error.
>>
>>
>> I think we're getting pretty close to having enough to write an RFC for
>> this. I'll go ahead and create one after a little more discussion goes
>> around.
>>
>> --Kris
>>
>>
>>
>> On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick <
>> [email protected]> wrote:
>>
>>> Hi, Kris
>>>
>>> I don't think we have to care about scripts that are written right now
>>> if we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
>>> this feature is completely new. But I like the idea to have all type-hint
>>> failures ending up the same way.
>>>
>>> I personally would keep the error-messages for classes and arrays as
>>> they are right now and do the same error in case the given value is not
>>> compatible to the expected type.
>>> Not compatible means that data gets lost after converting the data into
>>> the other data-type.
>>>
>>> Lets have an example:
>>>
>>> function foo(integer $i) {
>>> // do something
>>> }
>>>
>>> foo(true); // Even if Boolean is a lower type than int, it can be easily
>>> casted to an int. It's equivalent to 1.
>>> foo("1"); // wont throw an error because the transformation into an
>>> integer is loose-less
>>> foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
>>> integer is required here.
>>> foo("horse"); // Throws an E_RECOVERABLE_ERROR because if you transform
>>> "horse" into a float, it's 1 and that's not equal to the string anymore.
>>>
>>> I personally would treat float - int miss matches the same way as all
>>> other stuff, because it cannot be converted loose-less.
>>>
>>> And if the Object-cast-stuff comes through, we have to think about this
>>> in addition:
>>> https://wiki.php.net/rfc/object_cast_magic
>>>
>>> class MyInteger {
>>> public function __castTo(string $type) {
>>> if ($type === "integer")
>>> return 5;
>>> }
>>> }
>>>
>>> function foo(integer $i) {
>>> // do something
>>> }
>>>
>>> foo(new MyInteger()); // Even if this is an object - it's cast-able to
>>> an integer and therefore should be valid
>>>
>>> But this is just in case the RFC gets through ;) We don't have to think
>>> that much about it now - just keep it in mind.
>>>
>>> Bye
>>> Simon
>>>
>>>
>>> 2012/2/29 Kris Craig <[email protected]>
>>>
>>>> Now that I think of it, this would probably be a good argument for
>>>> differentiating between strong and weak. Looking back to my previous
>>>> comment, it probably would be best to have it behave the same
>>>> regardless of
>>>> what the incompatible type is. But in the case where a float might
>>>> sneak
>>>> its way into an int, the developer might decide that going with a weak
>>>> type
>>>> would make it more flexible (though if it was me, I'd just do a round or
>>>> leave it a mixed type lol).
>>>>
>>>> --Kris
>>>>
>>>>
>>>> On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig <[email protected]>
>>>> wrote:
>>>>
>>>> > @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
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch <[email protected]>
>>>> wrote:
>>>> >
>>>> >> On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
>>>> >>
>>>> >> Some cases I would find interesting to be explained:
>>>> >>
>>>> >> (using 'streak' for strong and/or weak, feel free to separate the
>>>> two)
>>>> >>
>>>> >> streak int $i = 123.456; //Common idiom for floor()
>>>> >> streak int $i = "123.456"; //In contrast to previous
>>>> >> streak int $i = "1 "; //value="1 " is ridiculously common HTML
>>>> >>
>>>> >> It's all well and good to say that any loss of data is "bad" and to
>>>> >> raise some E_* for it, but there are some idioms so common that feel
>>>> >> "wrong" as I consider them...
>>>> >>
>>>> >> If everyone "for" the new type hinting/forcing can reach consensus on
>>>> >> these sorts of cases, it would help clarify any RFCs a bit, I think
>>>> >>
>>>> >> wrt E_RECOVERABLE_ERROR vs E_WARNING
>>>> >>
>>>> >> If current type hinting raises E_RECOVERABLE_ERROR, I have no
>>>> >> objection to following that lead, with the explicit caveat that a
>>>> >> change to the existing type-hinting to E_WARNING, as unlikely as that
>>>> >> seems, would pull the new "streak" with it.
>>>> >>
>>>> >> I don't even object to using E_ERROR for the "strong" variant, if
>>>> that
>>>> >> passes review, really, since "strong" is, errr, strong. :-)
>>>> >>
>>>> >> Anybody who doesn't like the E_* can re-define them in a custom error
>>>> >> handler anyway, though allowing PHP to continue after E_ERROR is like
>>>> >> playing russian roulette...
>>>> >>
>>>> >> --
>>>> >> 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
>>>> >>
>>>> >>
>>>> >
>>>>
>>>
>>>
>>
>

Guys,

I've followed this thread silently so far, and I'm wondering what changed over the last ~1.5years that warrants a new discussion into that matter.
I think the previous discussion ended with a pretty clear directive that strict typing has no place in PHP. Rasmus said about the proposal back then "They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP." - which put in one sentence what several others (myself included) put in many more words. So the 'strong'/'firm'/'strict'/whatnot version of what is being discussed here, should probably not be discussed at all. We've been through it, and rejected it.

Back when we rejected strict typing, we also 'killed' the other RFC[*] that was born out of that old discussion - the 'weak' auto-conversion RFC. If I recall correctly, it was for two reasons - one was that the proponents of the strict typing said they'll firmly object weak typing, and the other is that this RFC still had some issues that didn't seem obvious to hammer out (main one I recall is that sticking to PHP's standard type juggling rules meant that feature wasn't very useful, and we didn't feel very comfortable introducing brand new type juggling rules just for that feature). If you want to revive that discussion, I suggest you take a look at that RFC - confine yourselves to only work on stuff that stands a chance to get accepted (no strict typing) - and try to come up with good answers to the open questions. No point in redoing the whole discussion from scratch.

Zeev

[*]https://wiki.php.net/rfc/typecheckingstrictandweak

> -----Original Message-----
> From: Kris Craig [mailto:[email protected]]
> Sent: Tuesday, February 28, 2012 11:58 PM
> To: John Crenshaw
> Cc: Richard Lynch; internals@lists.php.net
> Subject: Re: [PHP-DEV] Scalar type hinting
>
> Err sorry yes John is correct. I wasn't paying close enough attention.
>
> Here's *my* vision of how that progression would look:
>
> $a = "1"; // Current kosher unchanged.
> weak int $a = "1"; // Converts to 1. No error thrown.
> strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm still on
> the fence).
>
> $a = "blah"; // Current kosher unchanged.
> weak int $a = "blah"; // Throws E_x error level.
> strong int $a = "blah"; // Throws E_y error level.
>
>
> Where E_y > E_x.
>
> --Kris
>
>
> On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
> <[email protected]>wrote:
>
> > No, In the example given there's an error on int $a = "1". There
> > should be no error because this juggles fine.
> >
> > John Crenshaw
> > Priacta, inc.
> >
> > -----Original Message-----
> > From: Kris Craig [mailto:[email protected]]
> > Sent: Tuesday, February 28, 2012 4:47 PM
> > To: Richard Lynch
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Scalar type hinting
> >
> > @Richard That's fairly close to what I'm thinking, yes. But there
> > seems to be a diverse range of ideas bouncing around right now, so at
> > present it's all in flux.
> >
> > --Kris
> >
> >
> > On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch <[email protected]> wrote:
> >
> > > On Mon, February 27, 2012 4:34 pm, Kris Craig wrote:
> > > > I think this is the main reason for differentiating between "strong"
> > > > (or
> > > > whatever word is appropriate) and "weak." The developer may very
> > > > well want their script to blow-up in such a case.
> > >
> > > I believe I actually "get it" now...
> > >
> > > You want 3 layers:
> > >
> > > $a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
> > > error level strong int $a = "1"; // some E_y error level where E_y >
> > > E_x
> > >
> > > Is that a correct summation?
> > >
> > > --
> > > 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
> > > =F
> > > S9NLTNEEKWBE
> > >
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > > visit: http://www.php.net/unsub.php
> > >
> > >
> >

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

.....Aaaaaand here we go again. Every few days it seems, somebody jumps
into this thread and reminds us that strict typing is a bad idea, despite
the fact that we've already all agreed on that point about a gazillion
times.

As for past RFC's, I would recommend you review the voting procedure. If
an RFC is rejected, the policy does allow it to be re-introduced after 6
months. While we're not actually reviving a previously rejected RFC since
we're discussing a different approach, even if you were to apply that to
the broader conceptual level, this discussion is still perfectly kosher
since, as you said, that rejection happened 1.5 years ago (3 times the
required period).


Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed
at this repetitive pattern by now. We start finding common ground and
making progress, then somebody new makes a post about the evils of strict
typing and questioning why we're talking about this, obviously completely
ignoring the fact that we've already addressed this *numerous* times. So
Zeev, while I appreciate your interest and welcome you to participate,
please take another look at the previous posts in this thread, because we
have already addressed your concerns ad nauseum and have since moved-on. I
do not want us to get dragged back into grinding our wheels in the mud on
that. Thank you for your understanding.

--Kris


On Wed, Feb 29, 2012 at 1:09 PM, Zeev Suraski <[email protected]> wrote:

> Guys,
>
> I've followed this thread silently so far, and I'm wondering what changed
> over the last ~1.5years that warrants a new discussion into that matter.
> I think the previous discussion ended with a pretty clear directive that
> strict typing has no place in PHP. Rasmus said about the proposal back
> then "They aren't hints. It is strict typing and in its current form I
> would ask you guys not to call the 5.4 release PHP." - which put in one
> sentence what several others (myself included) put in many more words. So
> the 'strong'/'firm'/'strict'/whatnot version of what is being discussed
> here, should probably not be discussed at all. We've been through it, and
> rejected it.
>
> Back when we rejected strict typing, we also 'killed' the other RFC[*]
> that was born out of that old discussion - the 'weak' auto-conversion RFC.
> If I recall correctly, it was for two reasons - one was that the
> proponents of the strict typing said they'll firmly object weak typing, and
> the other is that this RFC still had some issues that didn't seem obvious
> to hammer out (main one I recall is that sticking to PHP's standard type
> juggling rules meant that feature wasn't very useful, and we didn't feel
> very comfortable introducing brand new type juggling rules just for that
> feature). If you want to revive that discussion, I suggest you take a look
> at that RFC - confine yourselves to only work on stuff that stands a chance
> to get accepted (no strict typing) - and try to come up with good answers
> to the open questions. No point in redoing the whole discussion from
> scratch.
>
> Zeev
>
> [*]https://wiki.php.net/rfc/typecheckingstrictandweak
>
> > -----Original Message-----
> > From: Kris Craig [mailto:[email protected]]
> > Sent: Tuesday, February 28, 2012 11:58 PM
> > To: John Crenshaw
> > Cc: Richard Lynch; internals@lists.php.net
> > Subject: Re: [PHP-DEV] Scalar type hinting
> >
> > Err sorry yes John is correct. I wasn't paying close enough attention.
> >
> > Here's *my* vision of how that progression would look:
> >
> > $a = "1"; // Current kosher unchanged.
> > weak int $a = "1"; // Converts to 1. No error thrown.
> > strong int $a = "1"; // Converts to 1. May or may not throw an error
> (I'm still on
> > the fence).
> >
> > $a = "blah"; // Current kosher unchanged.
> > weak int $a = "blah"; // Throws E_x error level.
> > strong int $a = "blah"; // Throws E_y error level.
> >
> >
> > Where E_y > E_x.
> >
> > --Kris
> >
> >
> > On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
> > <[email protected]>wrote:
> >
> > > No, In the example given there's an error on int $a = "1". There
> > > should be no error because this juggles fine.
> > >
> > > John Crenshaw
> > > Priacta, inc.
> > >
> > > -----Original Message-----
> > > From: Kris Craig [mailto:[email protected]]
> > > Sent: Tuesday, February 28, 2012 4:47 PM
> > > To: Richard Lynch
> > > Cc: internals@lists.php.net
> > > Subject: Re: [PHP-DEV] Scalar type hinting
> > >
> > > @Richard That's fairly close to what I'm thinking, yes. But there
> > > seems to be a diverse range of ideas bouncing around right now, so at
> > > present it's all in flux.
> > >
> > > --Kris
> > >
> > >
> > > On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch <[email protected]> wrote:
> > >
> > > > On Mon, February 27, 2012 4:34 pm, Kris Craig wrote:
> > > > > I think this is the main reason for differentiating between
> "strong"
> > > > > (or
> > > > > whatever word is appropriate) and "weak." The developer may very
> > > > > well want their script to blow-up in such a case.
> > > >
> > > > I believe I actually "get it" now...
> > > >
> > > > You want 3 layers:
> > > >
> > > > $a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
> > > > error level strong int $a = "1"; // some E_y error level where E_y >
> > > > E_x
> > > >
> > > > Is that a correct summation?
> > > >
> > > > --
> > > > 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
> > > > =F
> > > > S9NLTNEEKWBE
> > > >
> > > >
> > > >
> > > > --
> > > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > > > visit: http://www.php.net/unsub.php
> > > >
> > > >
> > >
>

Personally, while I see the value in recycling what's already there, I
think that would just make things WAY more confusing than they need to be.
Some of these RFC's are years old and appear to have since been abandoned.
I think it would be better to have a procedure for removing "dead" RFC's
after a certain period of inactivity (like 6 months).

In any case, given the complexity involved, I think it would make much more
sense to create an RFC from scratch. Since the strong/weak question is
integral to this, having them in separate RFC's wouldn't work I don't
think. For example, what if the strong/weak one passed, but the one about
type hinting failed? I think that would just set a bad precedent for the
RFC process, since currently we don't have a system for having "RFC
dependencies."

Hence why I think the most sensible approach is to do this in one single
vote. The question is, how should that vote be structured?


I think what we need to do is amend the voting process before tackling
this, because there's just no good way to handle this right now without
arbitrarily creating a majority standard that doesn't currently exist.

So, here's what I'm thinking: An RFC can contain one "primary" question
and zero or more "secondary" questions. The primary question would be the
way it's setup now; all those rules would be unchanged. However, what if
there are multiple approaches to *how* this RFC can be implemented? It
stands to reason that, for example, a clear 2/3 majority can agree that
this should be implemented, but there is no clear majority with regard to
which method should be used. The more options there are, the more likely
it is that the vote will be perpetually split, essentially preventing that
feature from moving forward despite having supermajority support.

Therefore, a "secondary" question would be defined as a question that does
not materially affect *anything* outside the immediate scope of the primary
question and does not contain any voting options that would prevent the
primary question from being implemented. As such, since the secondary
question can have a theoretical infinite number of possible answers, the
standard for passage would be a simple plurality; i.e. whichever option has
the most votes would be the one used to implement the primary question, if
passed (if the primary question fails, then the secondary question is
meaningless). In the event of a tie, I would say extend the voting period
until someone breaks the tie.


What do you think? I believe this would not only be helpful to us now, but
would also improve the RFC voting process overall by making it much more
flexible. I can write an RFC for this if anyone thinks it has merit.

--Kris


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

> Hi, Kris
>
> As we have some RFCs around that we should update them I think.
>
> In my opinion we should split them up into 3 RFCs (and one grouping RFC):
>
> Weak and strong type-checks (whatever that in detail means) should be
> discussed in one single RFC. The option1 in the existing one is pretty
> close to what I expect it to be - but why should f.e. "12abc" be a valid
> integer? As said - we should update that.
> https://wiki.php.net/rfc/typecheckingstrictandweak
>
> Split the following RFC into two RFCs. Parameter type-hint and return
> type-hint:
> https://wiki.php.net/rfc/typehint
>
> Until now we have two RFCs for return type-hint that should also be
> combined. Add the information from the last mentioned here as well:
> https://wiki.php.net/rfc/returntypehint2
> https://wiki.php.net/rfc/returntypehint
>
> And finally update the grouping-RFC:
> https://wiki.php.net/rfc/typechecking
>
> The RFCs for parameter- and return-type-hint should not contain the
> definition of strict or weak type-hints.
> After all three RFCs have been voted by a bunch of people we can write
> down a RFC for a combination - f.e. how it should look like to have weak
> function type-hinting or strong return type-hinting.
>
> So .. here's quite a lot of work to do to gather the people who wrote
> these RFCs and let their ideas float into one specific definition with
> several options how to implement them.
>
>
> Bye
> Simon
>
> 2012/2/29 Kris Craig <[email protected]>
>
>> And here's a thought: I could structure the RFC so that the voting will
>> have 3 choices: Yes with strong/weak differentiation, yes without
>> strong/weak, or no. However, the voting RFC doesn't cover how the tally
>> should be calculated in such a circumstance. For example, let's say we had
>> 8 votes yes with differentiation, 2 votes yes without differentiation, and
>> 5 votes no. If we tally the two "yes" columns, it's 10 - 5, which would be
>> the required 2/3 majority. However, how would we calculate the mandate on
>> differentiation? Among those who voted yes, there's a clear 8 - 2 (80%)
>> majority in favor of it. But if you count the no votes as being no to
>> differentiation and add them to the total, it suddenly becomes 8 - 7, which
>> falls short of the 2/3 majority. An argument could be made that these
>> people who voted no would not want differentiation, but another argument
>> could be made that; while they don't like the idea, if it does happen
>> they'd rather have it differentiated than not. In other words, determining
>> voter intent from that group would be difficult and thus only tallying
>> among the yes votes would make sense. Both arguments would have about
>> equal merit I think
>>
>> The voting RFC does allow for different "options" in the vote, but it
>> does not elaborate on this. We could break the "no" group into two as
>> well, though that could make things a bit too confusing.
>>
>>
>> Since there's presently no clear procedure on this (at least none that
>> I'm aware of), what are your thoughts on this? I do believe the two should
>> be in the same vote since they're pretty integral to one another, but I'm
>> not sure how best to do that while maintaining accurate results without
>> making it too complicated.
>>
>> --Kris
>>
>>
>>
>> On Wed, Feb 29, 2012 at 12:18 PM, Kris Craig <[email protected]>wrote:
>>
>>> @Simon Agreed. That's pretty much what I'm thinking it should look like.
>>>
>>> With booleans, I think you have a good point. If 1 or 0 is passed to a
>>> bool, I'd say that should be fine without an error. If you were to pass a
>>> 2, though (you insolent bastard!), then it would throw the error.
>>>
>>>
>>> I think we're getting pretty close to having enough to write an RFC for
>>> this. I'll go ahead and create one after a little more discussion goes
>>> around.
>>>
>>> --Kris
>>>
>>>
>>>
>>> On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick <
>>> [email protected]> wrote:
>>>
>>>> Hi, Kris
>>>>
>>>> I don't think we have to care about scripts that are written right now
>>>> if we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
>>>> this feature is completely new. But I like the idea to have all type-hint
>>>> failures ending up the same way.
>>>>
>>>> I personally would keep the error-messages for classes and arrays as
>>>> they are right now and do the same error in case the given value is not
>>>> compatible to the expected type.
>>>> Not compatible means that data gets lost after converting the data into
>>>> the other data-type.
>>>>
>>>> Lets have an example:
>>>>
>>>> function foo(integer $i) {
>>>> // do something
>>>> }
>>>>
>>>> foo(true); // Even if Boolean is a lower type than int, it can be
>>>> easily casted to an int. It's equivalent to 1.
>>>> foo("1"); // wont throw an error because the transformation into an
>>>> integer is loose-less
>>>> foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
>>>> integer is required here.
>>>> foo("horse"); // Throws an E_RECOVERABLE_ERROR because if you transform
>>>> "horse" into a float, it's 1 and that's not equal to the string anymore.
>>>>
>>>> I personally would treat float - int miss matches the same way as all
>>>> other stuff, because it cannot be converted loose-less.
>>>>
>>>> And if the Object-cast-stuff comes through, we have to think about this
>>>> in addition:
>>>> https://wiki.php.net/rfc/object_cast_magic
>>>>
>>>> class MyInteger {
>>>> public function __castTo(string $type) {
>>>> if ($type === "integer")
>>>> return 5;
>>>> }
>>>> }
>>>>
>>>> function foo(integer $i) {
>>>> // do something
>>>> }
>>>>
>>>> foo(new MyInteger()); // Even if this is an object - it's cast-able to
>>>> an integer and therefore should be valid
>>>>
>>>> But this is just in case the RFC gets through ;) We don't have to think
>>>> that much about it now - just keep it in mind.
>>>>
>>>> Bye
>>>> Simon
>>>>
>>>>
>>>> 2012/2/29 Kris Craig <[email protected]>
>>>>
>>>>> Now that I think of it, this would probably be a good argument for
>>>>> differentiating between strong and weak. Looking back to my previous
>>>>> comment, it probably would be best to have it behave the same
>>>>> regardless of
>>>>> what the incompatible type is. But in the case where a float might
>>>>> sneak
>>>>> its way into an int, the developer might decide that going with a weak
>>>>> type
>>>>> would make it more flexible (though if it was me, I'd just do a round
>>>>> or
>>>>> leave it a mixed type lol).
>>>>>
>>>>> --Kris
>>>>>
>>>>>
>>>>> On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig <kris.craig@gmail.c[email protected]>
>>>>> wrote:
>>>>>
>>>>> > @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
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch <[email protected]>
>>>>> wrote:
>>>>> >
>>>>> >> On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
>>>>> >>
>>>>> >> Some cases I would find interesting to be explained:
>>>>> >>
>>>>> >> (using 'streak' for strong and/or weak, feel free to separate the
>>>>> two)
>>>>> >>
>>>>> >> streak int $i = 123.456; //Common idiom for floor()
>>>>> >> streak int $i = "123.456"; //In contrast to previous
>>>>> >> streak int $i = "1 "; //value="1 " is ridiculously common HTML
>>>>> >>
>>>>> >> It's all well and good to say that any loss of data is "bad" and to
>>>>> >> raise some E_* for it, but there are some idioms so common that feel
>>>>> >> "wrong" as I consider them...
>>>>> >>
>>>>> >> If everyone "for" the new type hinting/forcing can reach consensus
>>>>> on
>>>>> >> these sorts of cases, it would help clarify any RFCs a bit, I think
>>>>> >>
>>>>> >> wrt E_RECOVERABLE_ERROR vs E_WARNING
>>>>> >>
>>>>> >> If current type hinting raises E_RECOVERABLE_ERROR, I have no
>>>>> >> objection to following that lead, with the explicit caveat that a
>>>>> >> change to the existing type-hinting to E_WARNING, as unlikely as
>>>>> that
>>>>> >> seems, would pull the new "streak" with it.
>>>>> >>
>>>>> >> I don't even object to using E_ERROR for the "strong" variant, if
>>>>> that
>>>>> >> passes review, really, since "strong" is, errr, strong. :-)
>>>>> >>
>>>>> >> Anybody who doesn't like the E_* can re-define them in a custom
>>>>> error
>>>>> >> handler anyway, though allowing PHP to continue after E_ERROR is
>>>>> like
>>>>> >> playing russian roulette...
>>>>> >>
>>>>> >> --
>>>>> >> 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
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>

Kris,

If we've agreed that strict typing is bad, why is it even showing on the discussion here? Calling it 'firm' or 'strong' doesn't make a difference. If it errors out or throws an exception (which BTW is out of the question for a language feature), it's strict typing, regardless of naming.

Thanks for pointing me to the voting procedure that I helped author. Are you essentially telling us we all have to waste our time again just because 6 months have passed? That alone might be reason enough to turn the OR in there into an AND and shut down that loophole. The rationale behind that time period was to allow for cases where there was an 'almost' majority. Here, the proposal stands no chance. The only reason you're not seeing anybody from the core devs responding is because they're tired of the Nth incarnation of the same discussion happening again with zero new ideas.

If you can show why it makes sense to revive the discussion based on the 2nd bullet, that is:
The author(s) make substantial changes to the proposal. While it's impossible to put clear definitions on what constitutes 'substantial' changes, they should be material enough so that they'll significantly effect the outcome of another vote.

.... then it's worth discussing. Nothing I saw in this thread falls under that category, as far as I can tell.

Let's put it to rest.

Zeev

From: Kris Craig [mailto:[email protected]]
Sent: Wednesday, February 29, 2012 11:18 PM
To: Zeev Suraski
Cc: John Crenshaw; Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting

.....Aaaaaand here we go again. Every few days it seems, somebody jumps into this thread and reminds us that strict typing is a bad idea, despite the fact that we've already all agreed on that point about a gazillion times.

As for past RFC's, I would recommend you review the voting procedure. If an RFC is rejected, the policy does allow it to be re-introduced after 6 months. While we're not actually reviving a previously rejected RFC since we're discussing a different approach, even if you were to apply that to the broader conceptual level, this discussion is still perfectly kosher since, as you said, that rejection happened 1.5 years ago (3 times the required period).


Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed at this repetitive pattern by now. We start finding common ground and making progress, then somebody new makes a post about the evils of strict typing and questioning why we're talking about this, obviously completely ignoring the fact that we've already addressed this numerous times. So Zeev, while I appreciate your interest and welcome you to participate, please take another look at the previous posts in this thread, because we have already addressed your concerns ad nauseum and have since moved-on. I do not want us to get dragged back into grinding our wheels in the mud on that. Thank you for your understanding.

--Kris

On Wed, Feb 29, 2012 at 1:09 PM, Zeev Suraski <[email protected]<mailto:[email protected]>> wrote:
Guys,

I've followed this thread silently so far, and I'm wondering what changed over the last ~1.5years that warrants a new discussion into that matter.
I think the previous discussion ended with a pretty clear directive that strict typing has no place in PHP. Rasmus said about the proposal back then "They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP." - which put in one sentence what several others (myself included) put in many more words. So the 'strong'/'firm'/'strict'/whatnot version of what is being discussed here, should probably not be discussed at all. We've been through it, and rejected it.

Back when we rejected strict typing, we also 'killed' the other RFC[*] that was born out of that old discussion - the 'weak' auto-conversion RFC. If I recall correctly, it was for two reasons - one was that the proponents of the strict typing said they'll firmly object weak typing, and the other is that this RFC still had some issues that didn't seem obvious to hammer out (main one I recall is that sticking to PHP's standard type juggling rules meant that feature wasn't very useful, and we didn't feel very comfortable introducing brand new type juggling rules just for that feature). If you want to revive that discussion, I suggest you take a look at that RFC - confine yourselves to only work on stuff that stands a chance to get accepted (no strict typing) - and try to come up with good answers to the open questions. No point in redoing the whole discussion from scratch.

Zeev

[*]https://wiki.php.net/rfc/typecheckingstrictandweak

> -----Original Message-----
> From: Kris Craig [mailto:[email protected]<mailto:[email protected]>]
> Sent: Tuesday, February 28, 2012 11:58 PM
> To: John Crenshaw
> Cc: Richard Lynch; internals@lists.php.net<mailto:[email protected]>
> Subject: Re: [PHP-DEV] Scalar type hinting
>
> Err sorry yes John is correct. I wasn't paying close enough attention.
>
> Here's *my* vision of how that progression would look:
>
> $a = "1"; // Current kosher unchanged.
> weak int $a = "1"; // Converts to 1. No error thrown.
> strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm still on
> the fence).
>
> $a = "blah"; // Current kosher unchanged.
> weak int $a = "blah"; // Throws E_x error level.
> strong int $a = "blah"; // Throws E_y error level.
>
>
> Where E_y > E_x.
>
> --Kris
>
>
> On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
> <[email protected]<mailto:[email protected]>>wrote:
>
> > No, In the example given there's an error on int $a = "1". There
> > should be no error because this juggles fine.
> >
> > John Crenshaw
> > Priacta, inc.
> >
> > -----Original Message-----
> > From: Kris Craig [mailto:[email protected]<mailto:[email protected]>]
> > Sent: Tuesday, February 28, 2012 4:47 PM
> > To: Richard Lynch
> > Cc: internals@lists.php.net<mailto:[email protected]>
> > Subject: Re: [PHP-DEV] Scalar type hinting
> >
> > @Richard That's fairly close to what I'm thinking, yes. But there
> > seems to be a diverse range of ideas bouncing around right now, so at
> > present it's all in flux.
> >
> > --Kris
> >
> >
> > On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch <[email protected]<mailto:[email protected]>> wrote:
> >
> > > On Mon, February 27, 2012 4:34 pm, Kris Craig wrote:
> > > > I think this is the main reason for differentiating between "strong"
> > > > (or
> > > > whatever word is appropriate) and "weak." The developer may very
> > > > well want their script to blow-up in such a case.
> > >
> > > I believe I actually "get it" now...
> > >
> > > You want 3 layers:
> > >
> > > $a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
> > > error level strong int $a = "1"; // some E_y error level where E_y >
> > > E_x
> > >
> > > Is that a correct summation?
> > >
> > > --
> > > 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
> > > =F
> > > S9NLTNEEKWBE
> > >
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > > visit: http://www.php.net/unsub.php
> > >
> > >
> >

Kris Craig wrote:
> With booleans, I think you have a good point. If 1 or 0 is passed to a
> bool, I'd say that should be fine without an error. If you were to pass a
> 2, though (you insolent bastard!), then it would throw the error.

I have to complain about that. There is nothing wrong in my book with assuming
that a returned value is true while an empty return is false. Having to check
for a number greater than zero rather than just 'true' is complicating things
again. If it returned some values from the DB query it's 'not false' and we can
go on.

But my main concern/complaint here is that I am more than happy with my IDE
doing all of the type hinting that I need, so there is no need to load down the
runtime engine with this. Perhaps now is the time to make a formal request that
a lot of this 'compiler' like construction show have an overall 'off' switch so
we can run scripts faster? PHPEclipse picks up the phpdoc comment blocks and
gives a hint popup that has served me well for years.

I know that there are always those say 'you do not have to use it', but with
these extensions starting to be applied to the very libraries we rely on, then
we are forced to learn about things that we do not actually need in production,
and once again we are wasting time on 'keeping up' when all we want is a
reliable stable base we can rely on.

I'm being forced to accept Smarty3 because 'that is the supported version' when
converting several years worth of Smarty2 templates is totally impractical. And
libraries like Smarty3 tend to include the very constructs you are discussing
'because they are the modern way'. Perhaps it is about time us old fuddy duddys
started to support a frozen stable version of PHP and it's libraries that just
get essential security updates and let you 'modern guys' get on with your own
branch .....

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

Guys, you probably are too deep into the discussion that you haven't
noticed an elephant Zeev has put into the room. When the RFC procces was
put in place there was a rule outlined - if core devs decide to reject,
it's rejected. And as Zeev said last time core dev team decided that there
will be no strict typing in PHP, period (btw, Zeev thanks for reminding
that). It's open source - if you want it badly, fork, patch and have your
party with black jack and girls.

Zeev i have just have one question - is it worth trying to get the type
hinting "the PHP way" (that converting thing that errors only on really bad
missmatches like asking for int and getting an array or object)? I
understand the argument that if rules of conversion are not changed, then
basically not much is changed. But from the code writing prespective it
becomes easier, because with converting type hint you do not need to make
explict conversions all over the code - it's done at calll time and that
simplifies things, sometimes a lot. Second - the reflection then does not
rely on phpdoc to get the types (and i remember there was an issue with
opcode caching and phpdoc being stripped and so not avaliable).
It good to have array and object hints, but i miss the
integer/string/boolean/double hints more times than i want to admit really
:-)

Responses inline.

--Kris


On Wed, Feb 29, 2012 at 1:49 PM, Zeev Suraski <[email protected]> wrote:

> Kris,****
>
> ** **
>
> If we’ve agreed that strict typing is bad, why is it even showing on the
> discussion here? Calling it ‘firm’ or ‘strong’ doesn’t make a difference.
> If it errors out or throws an exception (which BTW is out of the question
> for a language feature), it’s strict typing, regardless of naming.
>

That is a form of cognitive dissonance, a logical fallacy. More
colloquially known as an "either or argument."

Everyone agrees that strict C-like typing is not tenable. We've moved past
that and what's being proposed now does not rise to that level.


> ****
>
> ** **
>
> Thanks for pointing me to the voting procedure that I helped author.
>

You're welcome.


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

Yes. Though given how many people have shown an interest in this thread, I
would challenge your assertion that it is a waste of time. If you feel as
though it's a waste of *your* time, then don't waste your time. But that
doesn't give you the right to demand that we cease talking about it just
because *you* don't think it's a worthy discussion.


> That alone might be reason enough to turn the OR in there into an AND
> and shut down that loophole.
>

You're free to introduce a new RFC for that, but don't be surprised when I
and probably a number of others campaign heavily and tirelessly against
it. I don't think most people would agree with such a totalitarian
approach designed to silence dissenting views from being introduced and
discussed.

The rationale behind that time period was to allow for cases where there
> was an ‘almost’ majority. Here, the proposal stands no chance. The only
> reason you’re not seeing anybody from the core devs responding is because
> they’re tired of the Nth incarnation of the same discussion happening again
> with zero new ideas.
>

Please refer to the Wikipedia link I posted above pertaining to "weasel
words."

Just because a conceptually similar proposal failed two years ago doesn't
mean the discussion we're having now won't have any support.


> ****
>
> ** **
>
> If you can show why it makes sense to revive the discussion based on the 2
> nd bullet, that is:****
>
> The author(s) make substantial changes to the proposal. While it's
> impossible to put clear definitions on what constitutes 'substantial'
> changes, they should be material enough so that they'll significantly
> effect the outcome of another vote.****
>
> ** **
>
> … then it’s worth discussing. Nothing I saw in this thread falls under
> that category, as far as I can tell.
>

I disagree. A number of ideas have been put forth that differ from
previous proposals. Just because *you* don't think they differ enough does
not mean you can unilaterally declare that this discussion must end.
Besides, as you said, such a standard would be completely arbitrary and
open to interpretation. It would ultimately be something that would have
to come down to a vote (unless you're planning on being the one who gets to
decide for the rest of us what's substantial and what's not), which would
render the whole argument pointless anyway, since it would essentially be a
vote on whether or not we should have a vote. That's how the United States
Congress typically operates, and we all know how effective they are....

****
>
> ** **
>
> Let’s put it to rest.
>

This issue isn't going away. Again, we've already addressed this in
previous posts. You may not want to discuss it, and there may be people
who share your sentiment, but that does not give you the authority to shut
down this conversation or declare that you're going to change the RFC rules
so that we can't vote on this. If that's not what you were proposing, then
please accept my apologies for the misunderstanding. Either way, I've
already promised to push back hard against any efforts to silence the
discussion this time around, and I intend to honor that promise.

I am still in favor of ultimately moving this conversation to a separate
location if people like Zeev are just tired of having this in their
inboxes. Plus it would give those of us who are actually interested in
this a place to brainstorm without old fear tactics periodically being
reintroduced in an effort to derail the conversation. I'll investigate
such options as soon as I have some spare moments. It's been a busy week.
=)

****
>
> ** **
>
> Zeev****
>
> ****
>
> ** **
>
> *From:* Kris Craig [mailto:[email protected]]
> *Sent:* Wednesday, February 29, 2012 11:18 PM
> *To:* Zeev Suraski
> *Cc:* John Crenshaw; Richard Lynch; internals@lists.php.net
>
> *Subject:* Re: [PHP-DEV] Scalar type hinting****
>
> ** **
>
> ....Aaaaaand here we go again. Every few days it seems, somebody jumps
> into this thread and reminds us that strict typing is a bad idea, despite
> the fact that we've already all agreed on that point about a gazillion
> times.
>
> As for past RFC's, I would recommend you review the voting procedure. If
> an RFC is rejected, the policy does allow it to be re-introduced after 6
> months. While we're not actually reviving a previously rejected RFC since
> we're discussing a different approach, even if you were to apply that to
> the broader conceptual level, this discussion is still perfectly kosher
> since, as you said, that rejection happened 1.5 years ago (3 times the
> required period).
>
>
> Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed
> at this repetitive pattern by now. We start finding common ground and
> making progress, then somebody new makes a post about the evils of strict
> typing and questioning why we're talking about this, obviously completely
> ignoring the fact that we've already addressed this *numerous* times. So
> Zeev, while I appreciate your interest and welcome you to participate,
> please take another look at the previous posts in this thread, because we
> have already addressed your concerns ad nauseum and have since moved-on. I
> do not want us to get dragged back into grinding our wheels in the mud on
> that. Thank you for your understanding.
>
> --Kris
>
> ****
>
> On Wed, Feb 29, 2012 at 1:09 PM, Zeev Suraski <[email protected]> wrote:****
>
> Guys,
>
> I've followed this thread silently so far, and I'm wondering what changed
> over the last ~1.5years that warrants a new discussion into that matter.
> I think the previous discussion ended with a pretty clear directive that
> strict typing has no place in PHP. Rasmus said about the proposal back
> then "They aren't hints. It is strict typing and in its current form I
> would ask you guys not to call the 5.4 release PHP." - which put in one
> sentence what several others (myself included) put in many more words. So
> the 'strong'/'firm'/'strict'/whatnot version of what is being discussed
> here, should probably not be discussed at all. We've been through it, and
> rejected it.
>
> Back when we rejected strict typing, we also 'killed' the other RFC[*]
> that was born out of that old discussion - the 'weak' auto-conversion RFC..
> If I recall correctly, it was for two reasons - one was that the
> proponents of the strict typing said they'll firmly object weak typing, and
> the other is that this RFC still had some issues that didn't seem obvious
> to hammer out (main one I recall is that sticking to PHP's standard type
> juggling rules meant that feature wasn't very useful, and we didn't feel
> very comfortable introducing brand new type juggling rules just for that
> feature). If you want to revive that discussion, I suggest you take a look
> at that RFC - confine yourselves to only work on stuff that stands a chance
> to get accepted (no strict typing) - and try to come up with good answers
> to the open questions. No point in redoing the whole discussion from
> scratch.
>
> Zeev
>
> [*]https://wiki.php.net/rfc/typecheckingstrictandweak****
>
>
> > -----Original Message-----
> > From: Kris Craig [mailto:[email protected]]****
>
> > Sent: Tuesday, February 28, 2012 11:58 PM
> > To: John Crenshaw****
>
> > Cc: Richard Lynch; internals@lists.php.net
> > Subject: Re: [PHP-DEV] Scalar type hinting
> >****
>
> > Err sorry yes John is correct. I wasn't paying close enough attention.
> >
> > Here's *my* vision of how that progression would look:
> >
> > $a = "1"; // Current kosher unchanged.
> > weak int $a = "1"; // Converts to 1. No error thrown.****
>
> > strong int $a = "1"; // Converts to 1. May or may not throw an error
> (I'm still on
> > the fence).
> >****
>
> > $a = "blah"; // Current kosher unchanged.
> > weak int $a = "blah"; // Throws E_x error level.
> > strong int $a = "blah"; // Throws E_y error level.
> >
> >
> > Where E_y > E_x.
> >
> > --Kris
> >
> >
> > On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
> > <[email protected]>wrote:
> >
> > > No, In the example given there's an error on int $a = "1". There
> > > should be no error because this juggles fine.
> > >
> > > John Crenshaw
> > > Priacta, inc.****
>
> > >
> > > -----Original Message-----
> > > From: Kris Craig [mailto:[email protected]]****
>
> > > Sent: Tuesday, February 28, 2012 4:47 PM
> > > To: Richard Lynch
> > > Cc: internals@lists.php.net
> > > Subject: Re: [PHP-DEV] Scalar type hinting
> > >****
>
> > > @Richard That's fairly close to what I'm thinking, yes. But there
> > > seems to be a diverse range of ideas bouncing around right now, so at
> > > present it's all in flux.
> > >
> > > --Kris
> > >
> > >
> > > On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch <[email protected]> wrote:
> > >
> > > > On Mon, February 27, 2012 4:34 pm, Kris Craig wrote:
> > > > > I think this is the main reason for differentiating between
> "strong"
> > > > > (or
> > > > > whatever word is appropriate) and "weak." The developer may very
> > > > > well want their script to blow-up in such a case.
> > > >
> > > > I believe I actually "get it" now...
> > > >
> > > > You want 3 layers:
> > > >
> > > > $a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
> > > > error level strong int $a = "1"; // some E_y error level where E_y >
> > > > E_x
> > > >
> > > > Is that a correct summation?****
>
> > > >
> > > > --
> > > > 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
> > > > =F
> > > > S9NLTNEEKWBE
> > > >
> > > >
> > > >
> > > > --
> > > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > > > visit: http://www.php.net/unsub.php
> > > >
> > > >
> > >****
>
> ** **
>

Kris i have a question for you - who will implement a test patch? Previous
tries failed not because no one wanted, but because it was damn hard and
tricky. And ofcourse there was resistance against strict type hinting. Mine
included. I doubt any of the last timeinvolved will be willing to do that
again. So that is it: who has the skill, knowlage and will to do that
knowing there is very big chance it will be rejected?

In other words: "I'm not gonna respond to your arguments because you're a
troll. None of us smart people agree with you. Nyah nyah nyah I can't
hear you nyah nyah nyah!"

My response: *sticks tongue out*.... So there. ;P


Now that that's settled, where were we?....

Ok, looks like we left off at Lester expressing concern over integers >1
throwing an error on booleans. If checking for that would be problematic
then I have no problem letting it fail gracefully, though in an ideal world
my preference would be to see something thrown in such an event.

--Kris


On Wed, Feb 29, 2012 at 2:26 PM, Zeev Suraski <[email protected]> wrote:

> Kris,****
>
> ** **
>
> Responses aren’t inline. I’ll go back to the mode that most other core
> devs are employing right now and ignore it for the waste of time that it
> is. I won’t ignore it if it ever comes to a vote, nor will the others.***
> *
>
> ** **
>
> Troll away.****
>
> ** **
>
> Zeev****
>
> ** **
>
> ** **
>
> *From:* Kris Craig [mailto:[email protected]]
> *Sent:* Thursday, March 01, 2012 12:16 AM
>
> *To:* Zeev Suraski
> *Cc:* John Crenshaw; Richard Lynch; internals@lists.php.net
> *Subject:* Re: [PHP-DEV] Scalar type hinting****
>
> ** **
>
> Responses inline.
>
> --Kris
>
> ****
>
> On Wed, Feb 29, 2012 at 1:49 PM, Zeev Suraski <[email protected]> wrote:****
>
> Kris,****
>
> ****
>
> If we’ve agreed that strict typing is bad, why is it even showing on the
> discussion here? Calling it ‘firm’ or ‘strong’ doesn’t make a difference.
> If it errors out or throws an exception (which BTW is out of the question
> for a language feature), it’s strict typing, regardless of naming.****
>
>
> That is a form of cognitive dissonance, a logical fallacy. More
> colloquially known as an "either or argument."
>
> Everyone agrees that strict C-like typing is not tenable. We've moved
> past that and what's being proposed now does not rise to that level.
> ****
>
> ****
>
> Thanks for pointing me to the voting procedure that I helped author. ****
>
>
> You're welcome.
> ****
>
> Are you essentially telling us we all have to waste our time again just
> because 6 months have passed?****
>
>
> Yes. Though given how many people have shown an interest in this thread,
> I would challenge your assertion that it is a waste of time. If you feel
> as though it's a waste of *your* time, then don't waste your time. But
> that doesn't give you the right to demand that we cease talking about it
> just because *you* don't think it's a worthy discussion.
> ****
>
> That alone might be reason enough to turn the OR in there into an AND
> and shut down that loophole.****
>
>
> You're free to introduce a new RFC for that, but don't be surprised when I
> and probably a number of others campaign heavily and tirelessly against
> it. I don't think most people would agree with such a totalitarian
> approach designed to silence dissenting views from being introduced and
> discussed.****
>
> The rationale behind that time period was to allow for cases where
> there was an ‘almost’ majority. Here, the proposal stands no chance. The
> only reason you’re not seeing anybody from the core devs responding is
> because they’re tired of the Nth incarnation of the same discussion
> happening again with zero new ideas.****
>
>
> Please refer to the Wikipedia link I posted above pertaining to "weasel
> words."
>
> Just because a conceptually similar proposal failed two years ago doesn't
> mean the discussion we're having now won't have any support.
> ****
>
> ****
>
> If you can show why it makes sense to revive the discussion based on the 2
> nd bullet, that is:****
>
> The author(s) make substantial changes to the proposal. While it's
> impossible to put clear definitions on what constitutes 'substantial'
> changes, they should be material enough so that they'll significantly
> effect the outcome of another vote.****
>
> ****
>
> … then it’s worth discussing. Nothing I saw in this thread falls under
> that category, as far as I can tell.****
>
>
> I disagree. A number of ideas have been put forth that differ from
> previous proposals. Just because *you* don't think they differ enough
> does not mean you can unilaterally declare that this discussion must end.
> Besides, as you said, such a standard would be completely arbitrary and
> open to interpretation. It would ultimately be something that would have
> to come down to a vote (unless you're planning on being the one who gets to
> decide for the rest of us what's substantial and what's not), which would
> render the whole argument pointless anyway, since it would essentially be a
> vote on whether or not we should have a vote. That's how the United States
> Congress typically operates, and we all know how effective they are....***
> *
>
> ****
>
> Let’s put it to rest.****
>
>
> This issue isn't going away. Again, we've already addressed this in
> previous posts. You may not want to discuss it, and there may be people
> who share your sentiment, but that does not give you the authority to shut
> down this conversation or declare that you're going to change the RFC rules
> so that we can't vote on this. If that's not what you were proposing, then
> please accept my apologies for the misunderstanding. Either way, I've
> already promised to push back hard against any efforts to silence the
> discussion this time around, and I intend to honor that promise.
>
> I am still in favor of ultimately moving this conversation to a separate
> location if people like Zeev are just tired of having this in their
> inboxes. Plus it would give those of us who are actually interested in
> this a place to brainstorm without old fear tactics periodically being
> reintroduced in an effort to derail the conversation. I'll investigate
> such options as soon as I have some spare moments. It's been a busy week..
> =)****
>
> ****
>
> Zeev****
>
> ****
>
> *From:* Kris Craig [mailto:[email protected]]
> *Sent:* Wednesday, February 29, 2012 11:18 PM
> *To:* Zeev Suraski
> *Cc:* John Crenshaw; Richard Lynch; internals@lists.php.net****
>
>
> *Subject:* Re: [PHP-DEV] Scalar type hinting****
>
> ****
>
> ....Aaaaaand here we go again. Every few days it seems, somebody jumps
> into this thread and reminds us that strict typing is a bad idea, despite
> the fact that we've already all agreed on that point about a gazillion
> times.
>
> As for past RFC's, I would recommend you review the voting procedure. If
> an RFC is rejected, the policy does allow it to be re-introduced after 6
> months. While we're not actually reviving a previously rejected RFC since
> we're discussing a different approach, even if you were to apply that to
> the broader conceptual level, this discussion is still perfectly kosher
> since, as you said, that rejection happened 1.5 years ago (3 times the
> required period).
>
>
> Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed
> at this repetitive pattern by now. We start finding common ground and
> making progress, then somebody new makes a post about the evils of strict
> typing and questioning why we're talking about this, obviously completely
> ignoring the fact that we've already addressed this *numerous* times. So
> Zeev, while I appreciate your interest and welcome you to participate,
> please take another look at the previous posts in this thread, because we
> have already addressed your concerns ad nauseum and have since moved-on. I
> do not want us to get dragged back into grinding our wheels in the mud on
> that. Thank you for your understanding.
>
> --Kris****
>
> On Wed, Feb 29, 2012 at 1:09 PM, Zeev Suraski <[email protected]> wrote:****
>
> Guys,
>
> I've followed this thread silently so far, and I'm wondering what changed
> over the last ~1.5years that warrants a new discussion into that matter.
> I think the previous discussion ended with a pretty clear directive that
> strict typing has no place in PHP. Rasmus said about the proposal back
> then "They aren't hints. It is strict typing and in its current form I
> would ask you guys not to call the 5.4 release PHP." - which put in one
> sentence what several others (myself included) put in many more words. So
> the 'strong'/'firm'/'strict'/whatnot version of what is being discussed
> here, should probably not be discussed at all. We've been through it, and
> rejected it.
>
> Back when we rejected strict typing, we also 'killed' the other RFC[*]
> that was born out of that old discussion - the 'weak' auto-conversion RFC..
> If I recall correctly, it was for two reasons - one was that the
> proponents of the strict typing said they'll firmly object weak typing, and
> the other is that this RFC still had some issues that didn't seem obvious
> to hammer out (main one I recall is that sticking to PHP's standard type
> juggling rules meant that feature wasn't very useful, and we didn't feel
> very comfortable introducing brand new type juggling rules just for that
> feature). If you want to revive that discussion, I suggest you take a look
> at that RFC - confine yourselves to only work on stuff that stands a chance
> to get accepted (no strict typing) - and try to come up with good answers
> to the open questions. No point in redoing the whole discussion from
> scratch.
>
> Zeev
>
> [*]https://wiki.php.net/rfc/typecheckingstrictandweak****
>
>
> > -----Original Message-----
> > From: Kris Craig [mailto:[email protected]]****
>
> > Sent: Tuesday, February 28, 2012 11:58 PM
> > To: John Crenshaw****
>
> > Cc: Richard Lynch; internals@lists.php.net
> > Subject: Re: [PHP-DEV] Scalar type hinting
> >****
>
> > Err sorry yes John is correct. I wasn't paying close enough attention.
> >
> > Here's *my* vision of how that progression would look:
> >
> > $a = "1"; // Current kosher unchanged.
> > weak int $a = "1"; // Converts to 1. No error thrown.****
>
> > strong int $a = "1"; // Converts to 1. May or may not throw an error
> (I'm still on
> > the fence).
> >****
>
> > $a = "blah"; // Current kosher unchanged.
> > weak int $a = "blah"; // Throws E_x error level.
> > strong int $a = "blah"; // Throws E_y error level.
> >
> >
> > Where E_y > E_x.
> >
> > --Kris
> >
> >
> > On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
> > <[email protected]>wrote:
> >
> > > No, In the example given there's an error on int $a = "1". There
> > > should be no error because this juggles fine.
> > >
> > > John Crenshaw
> > > Priacta, inc.****
>
> > >
> > > -----Original Message-----
> > > From: Kris Craig [mailto:[email protected]]****
>
> > > Sent: Tuesday, February 28, 2012 4:47 PM
> > > To: Richard Lynch
> > > Cc: internals@lists.php.net
> > > Subject: Re: [PHP-DEV] Scalar type hinting
> > >****
>
> > > @Richard That's fairly close to what I'm thinking, yes. But there
> > > seems to be a diverse range of ideas bouncing around right now, so at
> > > present it's all in flux.
> > >
> > > --Kris
> > >
> > >
> > > On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch <[email protected]> wrote:
> > >
> > > > On Mon, February 27, 2012 4:34 pm, Kris Craig wrote:
> > > > > I think this is the main reason for differentiating between
> "strong"
> > > > > (or
> > > > > whatever word is appropriate) and "weak." The developer may very
> > > > > well want their script to blow-up in such a case.
> > > >
> > > > I believe I actually "get it" now...
> > > >
> > > > You want 3 layers:
> > > >
> > > > $a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
> > > > error level strong int $a = "1"; // some E_y error level where E_y >
> > > > E_x
> > > >
> > > > Is that a correct summation?****
>
> > > >
> > > > --
> > > > 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
> > > > =F
> > > > S9NLTNEEKWBE
> > > >
> > > >
> > > >
> > > > --
> > > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > > > visit: http://www.php.net/unsub.php
> > > >
> > > >
> > >****
>
> ****
>
> ** **
>

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

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
>

On Wed, Feb 29, 2012 at 4:49 PM, Zeev Suraski <[email protected]> wrote:

> Kris,
>
> If we've agreed that strict typing is bad, why is it even showing on the
> discussion here? Calling it 'firm' or 'strong' doesn't make a difference.
> If it errors out or throws an exception (which BTW is out of the question
> for a language feature), it's strict typing, regardless of naming.
>

Can someone point to what they perceive to be an appropriate definition of
strict typing is (online or in a CS book?) It's one thing to say strict
typing is bad, but I'm not confident that everyone is talking about the
same thing.

My books on programming language design don't specifically speak to
"strict" typing (e.g., Language Implementation Patterns, Programming
Language Pragmatics, etc.) I've found some Actionscript-specific writings
and a few discussions involving Ruby (although my books on Ruby don't speak
of "strict" typing), and discussions on variable levels of type checking:
http://en.wikipedia.org/wiki/Type_system#Variable_levels_of_type_checking

What is the operationalized definition that the core developers want
utilized?

Thank you very much,

Adam

--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com

Zeev Suraski <[email protected]> wrote:

> I'll go back to the mode that most other
> core devs are employing right now and ignore it for the waste of time
> that it is. I won't ignore it if it ever comes to a vote, nor will
> the others.
Quite right. Even though I'd like some form of typehints it makes no sense to talk about it every six months. Back to lurking and ready to vote against if it shows up.

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

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


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

If you think it's a good idea, then why vote against it? Seems kinda
strange to me.

This issue isn't going to go away. If you really want it to stop coming up
every 6 months because people are *constantly* requesting it, maybe we
should find a way to implement something that would appease this concern,
since the "be a dismissive prick" strategy obviously isn't working (that
last part wasn't directed at you personally, Derick). =)

--Kris


On Wed, Feb 29, 2012 at 2:44 PM, Derick Rethans <[email protected]> wrote:

> Zeev Suraski <[email protected]> wrote:
>
> > I'll go back to the mode that most other
> > core devs are employing right now and ignore it for the waste of time
> > that it is. I won't ignore it if it ever comes to a vote, nor will
> > the others.
> Quite right. Even though I'd like some form of typehints it makes no sense
> to talk about it every six months. Back to lurking and ready to vote
> against if it shows up.
>

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

I'm a bit like Matt in that I might see something useful in this, but
worry that it just might not really work as initially intended.

Zeev actually gave a pretty explanatory reply (albeit a bit hostile
and condescending, come on dude!) as to why it doesn't fit into the
language paradigm.

Made me hate him a little bit, but I have to say I'm satisfied with
that reply. :)

Best regards,
Daniel Macedo

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

I respectfully disagree. We've already covered this actually. The same
argument could have been (and probably was) made that stricter adherence to
OO standards in PHP 5 would break the PHP paradigm. Instead, it made PHP
considerably better and opened it up to a much wider audience. People are
still able to write procedural code if they so choose. Likewise, these
types would be optional, so people would still be able to write strictly
dynamic code if they so choose. If existing code will work exactly the
same as before and all this does is add a new feature layer to the next
major version, how can anyone reasonably claim that this "breaks" PHP?
Gimmie a break.

--Kris


On Wed, Feb 29, 2012 at 3:42 PM, Daniel Macedo <[email protected]> wrote:

> I'm a bit like Matt in that I might see something useful in this, but
> worry that it just might not really work as initially intended.
>
> Zeev actually gave a pretty explanatory reply (albeit a bit hostile
> and condescending, come on dude!) as to why it doesn't fit into the
> language paradigm.
>
> Made me hate him a little bit, but I have to say I'm satisfied with
> that reply. :)
>
> Best regards,
> Daniel Macedo
>

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

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

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