On Tue, Oct 13, 2015 at 6:40 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> All, > > On Tue, Oct 13, 2015 at 9:56 AM, Rowan Collins <rowan.coll...@gmail.com> > wrote: > > Andrea Faulds wrote on 13/10/2015 12:00: > >> > >> Hi Michael, > >> > >> Michael Wallner wrote: > >>> > >>> On 12/10/15 21:23, Andrea Faulds wrote: > >>>> > >>>> Even if we can't reserve the names, I hope we can do the two other > >>>> suggestions in time for release. > >>> > >>> > >>> Additionally, we could say "instance of class ...". > >>> > >> > >> We could do that, though it's already 'instance of'. Not sure on this > one. > > > > > > > > It's not necessarily a class you're requiring an instance of, it could > (and > > according to some design disciplines "should") be an interface. I think > the > > "did you mean..." is more useful if we don't make everything alias. > > > > Regards, > > -- > > Rowan Collins > > [IMSoP] > > > > > I think it's important to clean up these error messages and make it > easier to find the root problem. > > With that said, I strongly believe that adding new reserved classes is > the wrong way to do that. Part of the problem is inconsistency around > what we call types in the first place. This leads to confusion around > what types people expect and how they expect them. > > An example is the fact that types are different all over the place. > Cast tokens, the return of gettype(), documentation, etc. > > Everything is inconsistent. And reserving extra types because of this > inconsistency does nothing to actually fix the problem. > > Instead, my suggestion would be to double-down on clarifying that > "int"/"float"/"bool"/etc are the canonical correct versions, and > everything else is an alias. In future versions (likely 8, but > possibly earlier) we could deprecate the aliases, to keep things far > more consistent. > > Reserving more classes now (both 7.0 and this late in the RC process) > is IMHO not a great idea. Either side sucks (whichever we do we're > wrong), but at least not reserving gives us a path towards cleaning it > up rather than making it worse. > > I like Derick's suggestion (though removing "class"): > > Fatal error: Uncaught TypeError: Return value of foo() must be an > instance of boolean, scalar boolean returned > I also don't like reserving new class names or limiting their use. The message above looks clear and it shouldn't be a big problem to implement the fix. This fix shouldn't change anything except error message, so it'll make minimal risk for 7.0 release process. Thanks. Dmitry. > > The "instance" says it's an object. > > The rest of it becomes a documentation problem. We're already mostly > consistent in the docs (all of the signatures use the correct tokens), > so it shouldn't be hard to finish that off... > > My $0.02 at least. > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
