On Thu, Feb 12, 2015 at 1:45 PM, Andrea Faulds <a...@ajf.me> wrote:
> Hi Pavel,
>
> C# also doesn’t have dynamic typing. Plus, adding overloading to an existing
> language is more difficult.
>
C# does have dynamic typing.
Adding method overloading to an existing language may be more
difficult than creating a new language from ground up, but I'd guess
it's definitely not impossible (I can't say for sure, because I do not
know C and PHP's internals).
>> Overloading on scalar types - unpredictable how? Even with weak calls,
>> the best candidate could be chosen?
>
> Still likely to cause chaos. If you can overload based on scalar types, then
> foobar($a / 2) could call any of *three* different functions.
>
Sorry, but if you create functions foobar(int $x) and foobar(float $y)
which do totally different things, I'd argue that you brought the
chaos upon yourself. About the third option for called function, I'll
have to admit that I do not know of any other possible signature of a
function that the call could lead to, if we go by "choose the best
candidate" strategy for resolving.
>> Of course, sometimes there will be
>> an abmbiguous call, but as long as there would be a way to define
>> which call you want, it shouldn't be a problem as well?
>
> “A way to define which call you want”? Sounds like a hacky workaround to me.
>
Scratch that, I was thinking about something else while writing this.
Error on an ambiguous call is probably the best way to handle this.
>> Poor API - for useland code or in PHP's functions itself? But I don't
>> think this should be considered as a real problem, because in userland
>> code, developers are able to create a poor API even with the current
>> versions of PHP.
>
> That doesn’t mean we should make it any easier.
>
I just don't believe that method overloading would suddenly make
everyone write poor programs. Also, they can do the same poor coding
with tons of ifs and elses in one method without typehint and
declaring multiple types in phpDoc (createFrom($a) and @param X|Y|Z in
phpDoc), or they have to create multiple methods which have some
suffix (createFromX, createFromY, createFromZ).
>> If someone wants to shoot himself in the foot, he
>> will do it in one way or another. And at the same time, polymorphism
>> via method overloading can lead to a cleaner APIs, if it's used well.
>
> I don’t see how. The main things it enables are optional parameters (which we
> already support) and polymorphism (which we already support). So you’d have
> to explain what overloading brings to the table beyond those two things.
>
It brings cleaner declarations of methods and functions. Also, it
brings the possibility of having operator overloading in user classes
someday in the future (yes, this can be abused as well, but it also
has legitimate use cases - like class for representing Money and being
able to do +, - , / or * operations on them). Is the option of omiting
type hints and having optional parameters really a good enough
replacement for method overloading polymorphism for you? Because for
me, it unfortunately is not. :(
>> Well, about "number" type hint. How this would work, in combination
>> with strict types?
>>
>> function bar(float $f) {
>> return $f * 1.23;
>> }
>>
>> function foo(number $x) {
>> return bar($x);
>> }
>>
>> foo(1);
>>
>> From my understanding, it wouldn’t?
>
> It would accept an integer or a float, because both subclass number:
>
> function foobar(): number {
> return 1.0; // okay
> return 1; // okay
> }
>
> function foo(number $x) {}
> foo(1.0); // okay
> foo(1); // okay
>
> I don’t see why it “wouldn’t work”.
Read the example once more, please - the issue I see with it is that
bar() requires float, but foo() just number and doesn't convert it to
the required type. The most unpredictable thing is that it will work
half of the time and half of the time it will just throw errors. Sure,
the blame in this case is on all 3 "participants" - strict typing (and
no int -> float conversion), programmer itself and "number" typehint
(it just doesn't work well with the strict typing) - but as you said,
should you make writing poor programs easier? Just kidding with the
last sentence :) ... but honestly, I do find method overloading and
implicit conversions from int to float a better way to solve the
usecases for "number" typehint.
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
