Dear list,
I've always been bothered by the fact that we call type declarations
'hints', as if they aren't enforced. They have always been enforced
and we don't have an option to turn them off.
I'm wondering if we want to move away from that name to something
else. I have two RFCs already that deal with types and need to know if
there would be support for changing it, because that influences
internal and external names.
Here's an example: the return types RFC creates a struct that is
currently called zend_type_decl. This struct is only used for return
types at present, but could be unified with arginfo to work with
parameter type declarations as well. I'd prefer not to call it
zend_type_hint or zend_typehint, because they aren't 'hints'.
This also manifests itself to users because of reflection as well.
HHVM internally calls them TypeAnnotations, but since we've had RFC
proposals about something "annotations" which are something else I'd
prefer to stay away from that.
Can anyone come up with a better name than hints? Maybe type declarations? Or should we just stick with hints?
What do you guys think?
Hi!
Here are my thoughts.
The general concept should be called Optional Type Declarations, to replace “Type Hinting". They are type declarations, and they are optional. Thus the name. For the things themselves, they’re just Type Declarations, to replace “Type Hints". So, for example:
“I am a big fan of optional type declarations. I am always sure to use a type declaration for my functions’ parameters and return type. I would very much like to see type declarations for scalar types added, but realise this is unlikely to happen in the near future.”
For the return type case specifically, it would be a “Return Type Declaration”.
Does that sound reasonable?
Thanks!
Andrea Faulds
http://ajf.me/
Hi!
Here are my thoughts.
The general concept should be called Optional Type Declarations, to replace “Type Hinting". They are type declarations, and they are optional. Thus the name. For the things themselves, they’re just Type Declarations, to replace “Type Hints".
My worry about "optional type declarations" is that once a type is
present it isn't optional anymore. Could be confusing and I am unsure
if that's any better than a "type hint".
If we change it, maybe just call them "type declarations". I think
just referring to them as "types" could be too ambiguous.
The general concept should be called Optional Type Declarations, to replace “Type Hinting". They are type declarations, and they are optional. Thus the name. For the things themselves, they’re just Type Declarations, to replace “Type Hints".
My worry about "optional type declarations" is that once a type is
present it isn't optional anymore. Could be confusing and I am unsure
if that's any better than a "type hint".If we change it, maybe just call them "type declarations". I think
just referring to them as "types" could be too ambiguous.
I agree. Let’s just call them “Type Declarations” then.
Andrea Faulds
http://ajf.me/
-----Ursprüngliche Nachricht-----
Von: Andrea Faulds [mailto:ajf@ajf.me]
Gesendet: Dienstag, 16. September 2014 17:26
An: Levi Morrison
Cc: internals
Betreff: Re: [PHP-DEV] Renaming type-hints to something else?The general concept should be called Optional Type Declarations, to
replace Type Hinting". They are type declarations,
and they are optional. Thus the name. For the things themselves, theyre
just Type Declarations, to replace Type Hints".My worry about "optional type declarations" is that once a type is
present it isn't optional anymore. Could be confusing and I am unsure
if that's any better than a "type hint".If we change it, maybe just call them "type declarations". I think
just referring to them as "types" could be too ambiguous.I agree. Lets just call them Type Declarations then.
I would argue "type declaration" is wrong as well since it is not a type
declaration as it is known in other languages where the type declaration is
binding. IMO it is more a "type check". Consider the following
function foo(Bar $b){
$b = 1; //$b is not a Bar at all
}
Robert Stoll wrote (on 16/09/2014):
I would argue "type declaration" is wrong as well since it is not a type
declaration as it is known in other languages where the type declaration is
binding. IMO it is more a "type check". Consider the followingfunction foo(Bar $b){
$b = 1; //$b is not a Bar at all
}
I tend to think of them as "type assertions", since this:
function foo(Bar $b){
// do stuff
}
is kind of equivalent to this:
function foo($b){
assert($b instanceOf Bar);
// do stuff
}
i.e. it's a runtime-enforced check
-----Ursprüngliche Nachricht-----
Von: Rowan Collins [mailto:rowan.collins@gmail.com]
Gesendet: Mittwoch, 17. September 2014 18:01
An: internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Renaming type-hints to something else?Robert Stoll wrote (on 16/09/2014):
I would argue "type declaration" is wrong as well since it is not a
type declaration as it is known in other languages where the type
declaration is binding. IMO it is more a "type check". Consider the
followingfunction foo(Bar $b){
$b = 1; //$b is not a Bar at all
}I tend to think of them as "type assertions", since this:
function foo(Bar $b){
// do stuff
}is kind of equivalent to this:
function foo($b){
assert($b instanceOf Bar);
// do stuff
}i.e. it's a runtime-enforced check
I would prefer "type assertions" over "type check". Yet, I agree that changing the naming might cause more confusion
than it is helpful. Nevertheless, if we think the naming will cause harm in the future then we should consider to slowly
change it. Make "type hint" somewhat deprecated and change it in the doc but leave a notice. Something like "type
assertion (in older days called type hint)". And at some point we can remove the notices.
Hi!
The general concept should be called Optional Type Declarations, to
replace “Type Hinting". They are type declarations, and they are
optional. Thus the name. For the things themselves, they’re just Type
Declarations, to replace “Type Hints". So, for example:
I'd just call it type declarations, the fact that they are optional is
not part of their function, there are many optional things in PHP - e.g.
visibility declaration for class members is optional, but we don't call
it "optional visibility specification", or default values for parameters
are optional, but we don't call them "optional default values". The fact
that they are optional is kind of obvious anyway for anybody who have
seen PHP code since most of PHP function parameters do not have them :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
What do you guys think?
Has the ship not already sailed on this one? The php.net web site (
http://php.net/manual/en/language.oop5.typehinting.php), and userland
developers, have been calling them type hints for years now, I'd imagine
whatever new name comes up will largely be ignored outside of the internals
group.
Can anyone come up with a better name than
hints? Maybetype declarations? Or should we just stick withhints?
My general feeling is to leave it alone. I agree that it's a misnomer, but as has been mentioned, it's a well established misnomer. I don't see a big gain from it apart from academic purity.
That, said, while I don't support a yes vote, I wouldn't bother voting against it.
I do worry about a small class of extensions which inspect type hints. They'll need to ifdef around the API version to keep working. But I'll be honest, there's probably very few of those, and I probably wrote a sizable portion of them out of boredom. Even if they're more common than I imagine, the work-arounds are easy and reasonable, and anyone with a lick of C knowledge can manage it in a few minutes.
As for Hint versus Declaration/Decl or Annotation or whatever... My second choice (since staying with hint is my first) is probably decl(aration). Despite my HHVM loyalties, I'm not fond of using "annotation" here anyway. There's a reasonable argument in this thread for "check", but that feels clumsy from the user side.
-Sara (My .02 USD)
As for Hint versus Declaration/Decl or Annotation or whatever... My second choice (since staying with hint is my first) is probably decl(aration). Despite my HHVM loyalties, I'm not fond of using "annotation" here anyway. There's a reasonable argument in this thread for "check", but that feels clumsy from the user side.
I still can't help feeling we have conflicting 'requirements' here and
that depends on how you are targeting running your software. Obviously
compiling a project will give the fastest most compact code, while
running the raw scripts 'unadulterated' will be the slowest route. Using
intermediate caching has worked nicely for many years and my
eaccelerator stuff still works fine. To that end, I still view
Reflections and annotation bloat as an extra load that was not required
when using docblock annotation which most good IDE's happily run with.
This is all stripped in the caching and just as we 'min' css and
javascript we can 'min' the script files without actually compiling them
to reduce loading time. Not as relevant as it once was, bu still much
more in the spirit of flexibility that PHP used to have ...
I can see an advantage in a 'hint' where the code flow expects a scalar
value, but it SHOULD only be a hint not a 'crash if not' declaration and
in many cases again, a good IDE checking the code during development is
much more useful than adding a lot more secondary checking in the core
code flow? If the wrong type gets passed, the problem in the code is
elsewhere anyway?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Sara Golemon wrote (on 17/09/2014):
My general feeling is to leave it alone. I agree that it's a misnomer, but as has been mentioned, it's a well established misnomer. I don't see a big gain from it apart from academic purity.
I guess in that way it's similar to "overloading", which has a rather
odd meaning in PHP, as the manual page notes:
http://php.net/manual/en/language.oop5.overloading.php
Anyone else have an opinion they want to voice on this?
Am 19.09.2014 15:21, schrieb Levi Morrison:
Anyone else have an opinion they want to voice on this?
What's about "Typed Arguments"?
Am 19.09.2014 15:21, schrieb Levi Morrison:
Anyone else have an opinion they want to voice on this?
What's about "Typed Arguments"?
I am proposing return types which are not arguments, so that would be
too narrow.
Am 20.09.2014 um 15:05 schrieb Levi Morrison:
What's about "Typed Arguments"?
I am proposing return types which are not arguments, so that would be
too narrow.
Sorry, I have mistaken that related to the recently
discussion about return types.
Otherwise I think this two concepts should be denoted consistently
like "Argument types" and "Return Types" instead of refering to
"Hints" or "Hinting" which are rather misleading to me.
This also manifests itself to users because of reflection as well.
I think maybe writing out a few possible class/method names might be helpful:
Using Hint:
class ReflectionTypeHint
Methods:
ReflectionFunction::hasReturnTypeHint
ReflectionFunction::getReturnTypeHint
ReflectionParameter::hasTypeHint
ReflectionParameter::getTypeHint
Using Decl:
class ReflectionTypeDecl
Methods:
ReflectionFunction::hasReturnTypeDecl
ReflectionFunction::getReturnTypeDecl
ReflectionParameter::hasTypeDecl
ReflectionParameter::getTypeDecl
Using Declaration:
class ReflectionTypeDeclaration
Methods:
ReflectionFunction::hasReturnTypeDeclaration
ReflectionFunction::getReturnTypeDeclaration
ReflectionParameter::hasTypeDeclaration
ReflectionParameter::getTypeDeclaration
Dropping the suffix:
class ReflectionType
Methods:
ReflectionFunction::hasReturnType
ReflectionFunction::getReturnType
ReflectionParameter::hasType
ReflectionParameter::getType
Dropping the suffix:
class ReflectionType
Methods:
ReflectionFunction::hasReturnType
ReflectionFunction::getReturnType
ReflectionParameter::hasType
ReflectionParameter::getType
This seems to be the cleanest. Perhaps we should just call these “parameter types” and “return types”, or “type declarations” in full?
Andrea Faulds
http://ajf.me/
Am 17.09.2014 um 16:43 schrieb Levi Morrison:
class ReflectionType
Methods:
ReflectionFunction::hasReturnType
ReflectionFunction::getReturnType
ReflectionParameter::hasType
ReflectionParameter::getType
This looks most straightforward to me while I dont
see any benefit by adding some suffix like Hint,
Decl or Declaration.
Also I don't like the term "Type Hinting" already
used in the documentation.
Despite the change of a well known (but somwhat misleading)
term i think it would be more descriptive to call this two
concepts "Parameter Types" and "Return Types".