Hi,
Last evening I put together a quick proposal for a weak and strict
checking approach, since I felt that things were being concluded a bit
prematurely. More importantly I detailed the issues I see with a pure
strict type checking only approach.
I am publishing it a bit prematurely imho, but its not without merit
at this stage either and since I will be busy playing frisbee all
weekend, I thought I get it out there for people to comment right now:
http://wiki.php.net/rfc/typecheckingstrictandweak
As Paul insisted that my initial proposal did not sufficiently high
light the fact that there are other proposals, I moved my original
proposal to the above location so that we can have a disambiguation
page that lists all the various related proposals:
http://wiki.php.net/rfc/typechecking
Most of that is in there has been said/proposed on the list, so I am
just pasting the key section on why I think strict checking is
dangerous:
Strict type checking does have the advantage that subtle bugs will be
noticed more quickly and that function/method signatures will become
yet more self documenting and therefore more expressive. Also doing
these type checks based on the signature also means less code and
better performance over having to hand code the validation
Proponents of only providing strict type checking say that for the
most part variables are defined with the proper type unless they come
from an outside source, which usually requires validation anyways,
which is a perfect opportunity to type cast.
That is to define a variable that contains a boolean, developer will
probably do “$is_foo = true” and not “$is_foo = 0”. While this may be
true, it does means that developers using such strict type checking
API's now require that users understand data types, which currently
beginning developers do not necessarily need to.
Furthermore quite often developers need to parse content out of
strings and pass this to other methods. With strict type checking one
is now forced to explicitly type cast. While its certainly doable, its
also additional work that needs to be done while writing the code
(“$foo_int = (int)substr($bar, 3, 10)”). Then again some might argue
that this makes the code clearer.
It also means that users of such strict typed API's will tend to
simply cast and due to laziness (PHP is used for rapid development
after all) might forgo validating first if the content is really what
they expected. Without type checking the burden would be with the
developer providing the API. Since its usually expected that an API is
fairly often, it seems illogic to move this burden to the API users.
More over due to this, a new kind of bug will be introduced due to
over use of cast instead of hand coded parameter validation as is
currently necessary. This could lead to even higher bug rates.
As for outside sources needing validation. This is not always the case
as most people do trust that the data returned from a database is in
the expected format, even though for most RDBMS it will always be
returned as string. Same applies to configuration files, which if
defined in something else than PHP code will most likely only return
strings, but who's values will usually not be validated.
regards
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
