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 <kris.cr...@gmail.com> > @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 <simonsimc...@googlemail.com > > 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 <kris.cr...@gmail.com> >> >>> 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 <sha...@gmail.com> 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 < >>> > arvids.godj...@gmail.com>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 >>> > >> >>> > >>> > >>> >> >> >
