On Dec 22, 2011, at 7:55 PM, Stas Malyshev wrote:
> 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.
The feature isn't designed around "only those who use it." In fact, as per the
RFC, the keyword "function" will be used to serve as a mixed return type.
There are cases where I don't want to type hint my return value from a method
and will continue to use this. All scalar values will be forced to use this
way anyway. Namespaces, interfaces, abstracts, closures, traits..... the list
goes on with features that were built to give developers additional tools to
use. Are any of them required to use? No. It's general purpose - just like
the feature offered here. How many features are built into PHP that are meant
to force a user to use it, or even break BC? Why would you suggest this is
doing any different? Can you provide an example where this feature is doing
that?
>
>> 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.
Are you saying parameter type hinting isn't in PHP?
>
>> 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.
Sorry, again, look at what I said above. Namespaces, interfaces, abstracts,
closures, traits, parameter type hints, even classes are core features that
users aren't forced to use. Please tell me what makes them different. It is
an optional feature - just like all those I listed. If others are using it,
that's the point. Can you walk into existing code that you must interface with
today that has a type hinted parameter and decide not to use it? No. Why?
Because the company/developer who developed that solution made the decision
that it was a feature they found useful. What you're suggesting is that we
design features around those who do not want to use it.
>
>> 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.
So Java's bytecode, which requires a VM (interpreter), isn't comparable to
PHP's "compile"? Are you saying compile is only when code is converted into
machine code? Moving PHP code through a lexical analyzer, syntax parser,
intermediate code generator/opcode isn't a form of compilation? Considering
the verification of interfaces is done during the syntax parser, in a file
called zend_compile.c, before the code is actually executed, I'm pretty
comfortable calling this transformation "compiled."
>
>> 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!
public function blah(SomeClass $class = null)
{
if ($class)
{
// code here
}
}
What I'm calling a "standard" is something already in the language. If I had
written this to allow "false" to be returned instead of null, the complaints
would be much greater. Why? Because we're used to the type hinting allowing
that.
I want to make it clear that my goal with this RFC *isn't* to offer a compile
time feature for the sake of having it. Because PHP is interpreted and we have
our on minds, we can make decisions such as the frequently used scenario you
mentioned above. If the general consensus is that you *must* return the type
declared, then I'm game for it. In fact, code execution would actually be
faster. But what will end up happening is this:
public array getArray()
{
// Uh oh, I'll have to return an empty array
return array();
}
$array_value = $obj->getArray();
if (!empty($array_value))
This is why I decided on the null option.
> --
> 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
