My suggestion was to introduce type hinting gradually. First of all
type hints, would be just that, hints. A suggestion as to the
recommended type. If hints are used and the types do not agree, then
this is an E_NOTICE. If you are using hints then you are expecting the
types to be right. If you don't use hints, then nothing extra. The
notice would be present simply because it is an advisary notice.
Nothing is enforced. No type conversion would take place, but it would
mean you could see which methods/functions are getting values which
may need converting. Maybe this could be E_STRICT. By using hints, you
are implying strict coding. I could go with that.
The next stage could be to allow automatic conversion based upon the
normal type juggling rules OR to use a type conversion table which
would use the same PHP functions that would be used in userland to do
the conversion manually. In some cases this is just casting, but in
other cases the conversion of 'december' to a number (for example)
should result in NULL. I do agree (having re-read my own post) that a
failed conversion is an E_ERROR (or E_STRICT again). Again, if you are
using type hinting and are using automatic conversion, you have to
obey the rules. It may be that you could supply your own conversion
rules. A potentially useful feature would be to allow for a user
defined automatic type conversion table. So, a user could effectively
wrap the parameters to their own type and use their own type
conversion logic. This does allow for the creation of user defined
types (which I suppose are classes ... )
The final stage would be to apply a strict mode and that type hinting
is actually type enforcement. If a function or a method says it ways
an int, it must have an int. If not, then then this is a fatal error.
No automatic conversion.
If this is combined with filtering, I think you should actually have a
fewer type conversions. You get the data as a string from a user form.
You know that the 3 columns representing a DOB are actually numeric.
You use a filter to force them to numeric types. From that point on,
why do you need to know that they are strings? You pass the values
around as integers. If you pass them to a mktimt() function, they are
in the correct type already. This SHOULD mean less type conversions.
WIBNI - a very old acronym for Wouldn't It Be Nice If.
MH - the opposite to a WIBNI, a Must Have.
The introduction of type hints for scalars is under discussion. I'm
strongly in favour of them. It may be that I don't need them once I
start using the standard input filtering (I use my a mechanism
described by Marco Tabini in php|Architect - Poka-Yoke).
I think this comes down to a set of choices.
You can do everything yourself. No hints, no automatic filtering, etc.
You can restrict what you want to do. Using enforced typing, using
automatic filtering, etc.
I've come from an environment where each method/function is defined by
the interface and the types. If I supply the wrong type the code
wouldn't compile or worse. If PHP uses type hinting/enforcement, then
for all the CURRENT PHP code out there, nothing would change.
Of course all of this can be avoided if you didn't use scalars but had
all variables as objects (Eek! It would work - I think - but eek).
On 07/11/06, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Tue, November 7, 2006 4:19 am, Ron Korving wrote:
> I wouldn't like E_NOTICE. I agree that the result should be a NULL
> value if
> a conversion fails,
Assume, for the sake of argument, that someday one's type-hint could be:
function foo ([NULL | int] $bar){
}
Also assume the paramter passed to $bar is '42'
Then is converting to NULL really the right answer?...
I don't have a BETTER answer, mind you...
Seems to me, though, that if you're willing to turn on type-hinting,
and you restrict your function to accept only [NULL | int], then I'd
be more happy with PHP throwing something bigger than E_NOTICE and
converting the input to NULL and carrying on...
Seems to me, that once you commit to the type-hinting, a failed
conversion oughta be E_ERROR...
> I don't see a point in a hint called "mixed" either. You might as well
> not
> use a hint for that particular function parameter.
You may need [mixed] if the PHP Manual under-documents what return
values occur in the case of errors (which is the current
state-of-the-art, really) and you don't know for sure what is going to
come back, but you want something there, just so you know it's "not
right yet"
>> Sometime after that the facility to make the hints become enforcers.
>> There would be a published list of conversion mechanisms (the
>> equivalent PHP function in effect). You could potentially allow user
>> defined conversions for user defined types though I would see this
>> as
>> a WIBNI, rather than a MH.
WIBNI?
MH?
[shrug]
I get the gist from context, but may be missing details... :-)
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
