Re: Scalar Type Hinting

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. > 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. As far as it being crippled, I'm not sure what you mean, just because it's only doing casting? 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). 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... > 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). 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