Disclaimer: The following is direct (maybe brutally so). I'm not trying to hurt any feeling or attack, but I'm not pulling punches either. I don't have the energy right now to polish this and make it all nice and gentle, so I'm sorry in advance. I hope you'll look past the directness and be able to get some useful feedback.
> John, > > > Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote > > consent in this case. I actually basically stopped participating when it > > became apparent that people were determined to rush head first into > > creating a doomed RFC without any process to ensure that historical > > arguments were considered and addressed, with minimal attention to > > feedback, and with no concern for syntax (proposed syntax is as bad as the > > namespace syntax). > > Well, my take on it was that thinking out-loud in a thread is not going to > get us anywhere with nothing to base the conversation on. So I picked an > option and proposed it. As now, we can base the conversation around a real > implementation. Don't like the syntax? > Great! Let's find a better solution. But I felt that it was more important > to put a base for the conversation, rather than just letting it wander > aimlessly. > Yes, it was aimless discussion (though some would call it brainstorming). It was ready to move to the next level, which should have been gathering the constraints/requirements/problems into a coherent list to work from. What happened though was that this step was skipped entirely, so now there's been an attempt to write a preliminary spec without gathering the requirements first, which IMO is far worse than any amount of aimless discussion. > > I'm in favor of addressing the type hinting issue, but I'm opposed to this > > RFC. It is crippled, confusing, and has a plethora of unaddressed issues. > > Then point out the issues. Help improve it and make it something that *should* go in the core. That's why it's still in draft mode. I didn't propose it, or put it for discussion, I put it in draft for that very reason. > A good number of issues with the current proposal were raised during the discussion on the mailing list. I don't feel like digging them all up right now, but off the top of my head I remember the following being raised and never saw any consensus for how to resolve them: - inconsistent syntax (one syntax for scalars, a different one for classes) - conflicting syntax (I.E. array vs. (array), RFC simply "allows" this, and ignores the confusion that this will create for users.) - different from the syntax used in the docs - lack of sufficient function to justify a core change - chaos surrounding null (to accept and if so to cast or not? Creates a conflict between consistency and implications of the syntax) - conflicts with references (RFC tries to address this by simply disallowing references, which IMO just ignores the need that would have caused this sort of code in the first place.) There were others, but I'm not making an exhaustive list. > As far as it being crippled, I'm not sure what you mean, just because it's > only doing casting? > Yes, casting is barely better than doing nothing. If I want a dumb typecast I can do that already. What I can't do without massive boilerplate everywhere is an intelligent conversion that accepts safe conversions and gives a warning or error on unsafe conversions. > As far as confusing, it is? I thought this was actually one of the more > straight forward proposals, since it re-used so much from the core (meaning > that it doesn't add new behavior, it re-uses existing behavior). > Yes, the syntax has some critical issues that create conflicting expectations. Look at the prior discussion. The current proposal doesn't really fix most of this. > As far as having a plethora of unadressed issues, I'm absolutely sure it > does. But I haven't seen a single one put out there so that it can be > fixed... > Again, look at the prior discussion of this syntax. Plenty of issues raised. > > The object cast has similar problems, and although I recognize the value of > > this sort of functionality, the current proposal seems to mostly ignore a > > number of critical problems that were raised when it was discussed on the > > mailing list. > > Which were? The critical problems that I saw on the list were mostly related > to the original proposal wrapping set() with __assign() (which this proposal > removed). The only known issues that I know of that remains is with the > __toScalar() part (which in worst case can be removed from the proposal). > The biggest one that comes to mind is behavior with respect to operators. __toScalar() in your spec is an attempt to handle this, but IMO it really doesn't cut it. Off the top of my head problems with this solution include: - This will lead to duplicated code - Thinking about my own code, I have almost no idea how I would actually write a robust __toScalar() implementation. It's still going to be returning a string, or an integer. Very confusing. > > > These are RFCs. I am (as their author) explicitly asking for your comments > and contribution. They are not set in stone in the least... > In fact, the only way they would get to the point where I would propose them > is with enough input and overview that it was mature. They are not mature now. > > Can we make them mature? > > Thanks, > > Anthony Well, the big issue for me is that I think the type casting hints starts from a fundamentally bad foundation. The premise here is based on a syntax that is ugly and strange, and the syntax opens a bunch of new problems that I don't see a way to resolve. The reason for selecting this syntax was to avoid a BC break from reserving some new keywords. I don't really see this as a good trade. As for the automatic casting functions, I like the concept, but some serious problems were raised in the discussions and many were never resolved very well. To some extent I'm not really seeing good solutions either. If I think of a solution I'll be sure to mention it, but right now this looks very much like a dead end to me. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
