On Sat, Jan 31, 2015 at 8:27 PM, Andrea Faulds <a...@ajf.me> wrote: > >> On 1 Feb 2015, at 01:23, Dan Ackroyd <dan...@basereality.com> wrote: >> >> On 31 January 2015 at 17:31, Philip Sturgeon <pjsturg...@gmail.com> wrote: >>> On Sat, Jan 31, 2015 at 3:12 AM, Matteo Beccati <p...@beccati.com> wrote: >>>> >>>> 2) There's a tiny bit of overlap with "scalar type hints", >>> >>> 2) There might be some overlap in the scalar type hint stuff kinda, >>> but I'd like to think there isn't. getClassName() is just >>> getClass()->name >> >> >> I think Matteo's point is that if any scalar type RFC passes, a >> type-hint for a parameter would not always be the name of a class, so >> the method name 'getClassName()' would be misleading. >> >> It would be good to choose a better name to avoid that problem. > > We already have that problem (array, callable). > > I think the more important issue is the conflict with the > ReflectionTypeAnnotation RFC, which proposes something similar to what was > originally part of the Return Types RFC: > > https://wiki.php.net/rfc/reflectionparameter.typehint > > Thanks. > > -- > Andrea Faulds > http://ajf.me/ > > > >
Hey, missed a few replies. 1. There is no conflict with scalar types at all. The class name is not a scalar type :) We already have getClass(), this is just getting the name of that class without loading it. > a type-hint for a parameter would not always be the name of a class, so the method name 'getClassName()' would be misleading. This wont be a problem Dan. getClass() wouldn't work if you call it on a `foo(string $bar)`, and this will fall over too. The test and RFC both show that. So, are we good to vote? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
