Alban wrote:
I don't understand why you focus on " Strict / Weak " question.
For me it's very simple, it's not obligatory use Type Hiting. Developpers
wants to write a weak code, they'll just have to not use Type Hiting and
developpers wants wrote a stric code they'll have to use it.
After, choosing use or not Type Hinting when writing a librairy /
framework, this is not a php.internal problem.
It's a developper, designer, marketing choice ! Use or not use Type
hiting can help to chose a user target. And if you want be just between
weak and strict, " numeric " and " scalar " type hiting seems to be a
very good middle point.
+1 for Strict type hiting. (weak type hiting very similar to no type
hiting).
I was just going to send something like this. Big +1 to this comment.
Just add type hinting (strict) and type casting (weak). It is up to the
developer to use either or none.
Strict should be strict, if the user wants float, the user get's float.
That's the way class/array type hinting works now.. Use the type casting
option if they want int to float. Things such as "is_numeric" or just
"numeric" would be nice but could be added later if need be.
Weak does have some questions around it, no argument there. But IMO just
make it work simplistically for now and add additional features later.
Some things won't work at the beginning so just document that. Ex: an
object can't be casted to anything other than string at this point. And
cast an object to another object.. Couple features would be a nice
addition to support this, __cast() and __box() __unbox(), but I doubt it
will be added at the same time. Unless effort is put forward for
everything in a 5.4 release, or wait for 6.0 (way to far out though).
Error handling I'm not sure about though. Should it be a error or
exception, not sure. I'd say if possible, if a function an error would
work, if a class method throw an exception. Just don't know though.
As far as the discussion about "if it's added then everyone will have to
use the feature, no choice, it'll show up at some point". That is up to
the projects code guidelines. If you're that concerned then it's up to
the manager to enforce the no use of the feature. /End
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
