The problem is that, as was pointed out, strict typing is not optional.
The minute I am using one library that is built with strict typing,
all of my interaction with it from my code must be strict. That means
either:
1) My application needs to be strictly typed throughout (assuming I even
understand the concept; really how many developers not on this list even
know what a zval is?).
2) I need to build a wrapper layer around that library that handles all
of the type conversion for me in context-insensitive ways (which means
bugs), which could be extremely difficult if not impossible if it's a
large library with a big surface area.
Imagine if Zend Framework went strict typing. It would be essentially
unusable for anyone who wasn't also doing strict typing everywhere. How
does this benefit anyone?
--Larry Garfield
On 5/27/10 6:02 AM, Ilia Alshanetsky wrote:
Brian,
What we are talking about here is an **optional** feature for user-land
function that allow the author to implement really cheap input-validation to
facilitate ensuring that the correct input is supplied. Additionally it also
allows for better language interrogation for auto-generation of things like
SOAP WSDL and alike.
On Wed, May 26, 2010 at 6:02 PM, Brian Moon<br...@moonspot.net> wrote:
I like the idea of type hinting a lot. (See:
http://marc.info/?l=zend-engine2&m=102421231114377&w=2) I suggested it in
2001 when ZE2 was being designed. Somehow my idea was bastardized into only
classes and arrays. Guess it was the mad OOP craze of the time.
Anyhow, I would like to use it. And, as much as I appreciate Derick and
Ilia's work in getting a change in, I likely won't use it. Mainly because
the web is a bunch of strings. Casting data from MySQL every time I want to
use it does not interest me at all. Its a number in string form, treat it
like one. If you use filter, you still have to worry with casting. There is
no way to always get an int back from filter regardless of the input given.
Really, I am confused what the argument is about. We already decided how
this should work years ago. It should work just like the code below. Having
user land functions work different than built in functions is the most
confusing thing you can do. Unless of course someone plans on fixing all the
internal functions too.
================
<?php
error_reporting(E_ALL);
$int = 1.25454;
$var = substr($int, 0, 4);
var_dump($var);
$var = round($var, 1);
var_dump($var);
$arr = array();
$var = substr($arr, 0, 1);
var_dump($var);
$text = "test";
$var = round($text, 1);
var_dump($var);
?>
$ php test.php
string(4) "1.25"
float(1.3)
Warning: substr() expects parameter 1 to be string, array given in
/Users/brianm/test.php on line 17
NULL
float(0)
Brian.
--------
brianlm...@php.net
http://brian.moonspot.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
