Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37126
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.171 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=inkuA0GkqfaKt8yRziGIWIokeYDxQpYLSP9arZX9aW5G33aLziFHxVX4Oej7YM38bU6/jtJu53T+q0Pc4N0PyXk/X36sPArbOWlAn6E60KcV3oi1Ii9FekEC3YviKTRUWnkoOoFsjhr/TnH6nOwvrZEVVWa0B22mijxhdLyUGbs=
Message-ID: <9b3df6a50804180043s69ebac4bk53d757c80cfe5b1f@mail.gmail.com>
Date: Fri, 18 Apr 2008 10:43:11 +0300
To: "Lukas Kahwe Smith" <mls@pooteeweet.org>
Cc: "Lars Strojny" <lars@strojny.net>, "Felipe Pena" <felipensp@gmail.com>, 
	internals@lists.php.net
In-Reply-To: <D3575E90-4ED9-44E2-BF5B-100C9440A8A9@pooteeweet.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_5784_23298914.1208504591626"
References: <46ccd1ab0804170742g142ed562t4f03339da549a820@mail.gmail.com>
	 <1208466868.4430.10.camel@localhost> <1208478266.5763.14.camel@pena>
	 <1208500782.4430.14.camel@localhost>
	 <D3575E90-4ED9-44E2-BF5B-100C9440A8A9@pooteeweet.org>
Subject: Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
From: arvids.godjuks@gmail.com ("Arvids Godjuks")

------=_Part_5784_23298914.1208504591626
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

2008/4/18, Lukas Kahwe Smith <mls@pooteeweet.org>:
>
> Hello All,
>
> I just want to bring in a different perception on the proposed feature. I
> think people are very focused on what I call "library code". This is the
> kind of code that should in theory be worked on less, than the glue code
> that you write in every project to finish up the applications your customers
> have requested.
>
> IMHO type hinting and more importantly strict type hinting is very focused
> with making the life of library developers easier. They can just easily
> discard anything that doesnt match their expectations 100%. That this is not
> how PHP has traditionally worked has been mentioned quite often in this
> thread. But I want to direct peoples attention to the code that calls
> strictly typed libraries.
>
> Suddenly I need to ensure that all my variables have the proper types. So
> what will people do? They will start forcing type juggeling manually before
> they call the library in question. Since this is the glue code, its the kind
> of code you have to write day in day out. So maybe an "(int)" here or there
> is not so much more code to type, but you can already see that code you safe
> on one end, you have to start adding on the other, the one which you write
> more often. More importantly, in some cases simple type juggeling with
> "(int)" will not be sufficient, you might have to do some minor checks etc.
> In the past library authors did this as part of the code that the strict
> type hinting camp is now hoping to remove. So again more code in my glue
> code.
>
> Furthermore people over estimate the usefulness of automated errors. They
> tend to include very minimal context information. So when in the past people
> had to write out the parameter checking code manually, they had the
> opportunity to very easily add important context information to whatever
> error they raised. This will no longer be the case with strict type hinting.
> There it will be the responsibility for the caller to make sense of the
> error and know whatever context is relevant for this error condition.
>
> I guess the reply I can expect from this mail is that I do not have to use
> it, that I do not have to use libraries that use strict type hinting or that
> good developers will pick and choose when to use strict type hinting. While
> this may be true, we do not live in a perfect world. So again I want to
> remind people that as we develop the language, we need to pick and choose
> what features come in that will ensure that PHP remains at least as
> productive has it has been in the past for its users.
>
> As such I want to again bring up that a loose type hinting with types like
> "scalar" and "numeric" are much less risky, since they are a much wider
> filter. Its quite easy to figure out why a function that is documented to
> not operate on arrays to come back with an error when I pass it an array.
> However it will be a bit confusing to get an error when I pass '1' to a
> method that then comes back to complain I did not pass an integer.
>
> regards,
> Lukas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I think that this functionality can work for numeric types like this:

if we have one of the numeric types hinted for function arg then we need to
check if it is_numeric and if it is - we can convert it. If we have a string
witch can't be converted to regular numeric type without loosing information
(strings like "45s", "asdf32325" etc) - rase a recoverable error (or
exception - that way user can catch it and display it's own error text or do
some actions about it).
That way I think we won't lose the flexebility of PHP's dynamic type
conversions but we will make it a little bit more strict on what we are
passing to function (realy, if it is possible that string will be passed to
function where you have to have integer - don't you check it anyway for
correct type and value? Mostly on that check result is an error
triger_error/exit/die/etc.).

------=_Part_5784_23298914.1208504591626--