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.