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 <simonsimc...@googlemail.com>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 <kris.cr...@gmail.com> > >> 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 <kris.cr...@gmail.com>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 < >>> simonsimc...@googlemail.com> 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 <kris.cr...@gmail.com> >>>> >>>>> 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.cr...@gmail.com> >>>>> 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 <c...@l-i-e.com> >>>>> 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 >>>>> >> >>>>> >> >>>>> > >>>>> >>>> >>>> >>> >> >
