Hi!
And in those cases, they would continue to use the keyword "function"
and be considered unknown as they are today.
Taking the most common case and ignoring it and saying "ok, then don't
use it" is not a good way to design a feature in a general-purpose
language that would be used by literally millions.
I don't compare PHP to ruby, python or JavaScript. Do I suggest
features that I find useful in other languages like C# or Java or even
in any of the ones you listed? Absolutely.
C# and Java, again, are fully statically typed compiled languages. PHP
is not. That means that the benefits of strict type system that are
available to programmers in C# or Java will not be available to PHP
programmers, while the downsides of it (and inflexibility that such
system leads to) will still be there and will actually be multiplied by
the fact that you wouldn't know about the problem with your typing
system until your application starts crashing.
add overhead, just as parameters do (arguably more). But it is a
feature that is very valuable to many. Those who wish not to use it
can continue to do so.
Sorry, again, "don't use it" is not a valid response for a core feature
in a widely used language. It would be OK for a PECL module - if you
don't like mongoDB, don't use it, nobody objects to having mongodb
extension because it is not fit for some scenarios. However, designing
core language features that change the nature of the language - making
it from non-typed to strictly typed - have bigger requirements. You can
not just "not use" core feature - because others will be using it and
you'd have to leave with it and interface with their code.
Don't forget that while return checks are runtime, interface
definition and implementations are compile time.
Nothing is compile time in PHP, PHP has no compile time (at least if we
don't consider projects like HipHop, which is totally irrelevant here)
like C# or Java does. That's not how PHP code works. In C# and Java, you
can take the code and know in advance the type of any piece of data in
any place (maybe not precisely but at least base type). In PHP, you can
not.
Because null is a standard already set by parameter type hints. I do
> not want to sway away from that as it works well. It is common for
I'm not sure what you're talking about as a "standard". Yes, input
parameters strict typing allows nulls because it was another frequently
used scenario that strict typing does not support. Fortunately, it
could be fit into "default value" syntax, even though it doesn't really
means that (so we actually have a syntax that means two different things
now, not a great idea). But with return types and value strict types
(which would inevitably be asked for next) it wouldn't be that easy.
There's no syntax for "default return value" and the case of returning
false - one of the most common - can not be covered. And, on top of
that, I still do not see any benefit of it as you'd still have to check
the return value anyway!
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
