Re: Scalar-type-hinting - which way is the best to go?
tl;dr: "strict type hinting" and "Boxing based type hinting" (the second
one with some changes).
Just read through it, and I was unaware there's still ideas to continue
working on type hinting in PHP.
That's good news, at least for me :)
I'm just lurking around here, but if my thoughts can help, here they are.
Here's a short mapping of considerations related to the various
implementations exposed on that blog post:
1. Strict type hinting (also aliased by me "YES please, yes!"):
- It enforces the developer to keep his code cleaner
- It helps framework devs in reducing the overhead caused by casting
within internal classes
- Unsure devs can always call foo((int) $bar); if they are unsure
of what their code produces. The loss of performance will be only because
of crap code.
- Documentation of return values will become somehow a must
- Throwing exceptions, yes please... Unsure what level anyway... I
like the E_CATCHABLE_FATAL way. That gives enough flexibility...
2.
Unenforced type hinting:
- If you have mixed types, then you just don't need type hinting. Lazy
devs can still avoid using it. Lazyness shouldn't really be
encouraged, so
providing some kind of "backwards compatibility" just makes the feature
useless :\
- This is not a feature, it's just better implicit documentation for
methods
3. Casting weak type hinting:
- This is just case (1) with implicit casting. In my opinion, developers
should do the casts themselves with foo((int) $bar).
- Implicit casting in method calls would lead to chaos in tracking
bugs (for me). Not to mention warnings in N-level hierarchies
where values
are pushed forward and backward. Let's throw the exception before it
becomes chaos!
- I am unsure if it also would degrade performance, but I know very
little of internals.
4. Strict weak type hinting:
I don't really see allowing any of [int, string, float] for any type
hint for int, string or float as a feature. That's a silent failure to my
eyes. An alternative could be throwing warnings if there's a type mismatch,
otherwise the feature doesn't (again) provide anything new to me... It
probably just makes it messier.
5. Boxing based type hinting:
This is unrealted to the other 4 points to me. What PHP could probably
do for us is to cast an object to a scalar when the object implements the
compatible magic method (like __toString).
Anyway, __toScalar() and __fromScalar($scalar) feels weak. I'd
prefer a strict, well defined list of possible magic methods for the
various internal types. Would that be a big performance issue?
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 17 March 2012 14:38, Simon Schick <[email protected]> wrote:
> Hi, all
>
> Today I read a post around that:
>
> http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think
>
> As some of us are leading to the 3rd and some to the 4th or other ways
> described in here (I think we can simply exclude the first one ...)
> Would it be an option (to get this moved forward) to let people vote
> which way they like most (or which comes closest to their
> best-solution)?
>
> I pretty much like the 3rd way ... the only thing I see that has not
> been discussed enough is how to handle integers on 64bit and 32bit
> installations.
>
> Bye
> Simon
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Thread (13 messages)