[POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters View as Markdown

Actually, it turns out the segfault and auto-reference bugs were
easier than I thought to fix. I've updated both gists with the new
code, and it looks to be running quite well...

Hey all,

As promised, I've created a POC patch to implement scalar type hints,
the way that zend_parse_parameters handles hinting.  First off, here's
the patch:

Directly apply-able without re2c:
https://gist.github.com/2004623

Removing generated files (requires re2c to compile):
https://gist.github.com/2004650

It's a POC, but it mostly works.  There is one known issue: passing a
class implementing __toString to a string hinted function will raise a
segmentation fault.  There's also an issue of not separating the
argument on cast yielding to reference whether indicated or not, but
that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in
the cases where it would cast)... I'll work on cleaning it up, but I
wanted to show the concept before investing too much work...

So, basically, there are 4 new parameters:

bool
int
float
string

The casting vs error rules are identical to zend_parse_parameters.  So:

function fooi(int $i) { var_dump($i); }

fooi(1); // int(1)
fooi(1.5); // int(1)
fooi("1"); // int(1)
fooi("1abc"); // int(1) + notice about non-well-formed numeric
fooi("foo"); // E_RECOVERABLE_ERROR
fooi(true); // int(1)
fooi(array()); // E_RECOVERABLE_ERROR
fooi($obj); // E_RECOVERABLE_ERROR

function foob(bool $b) { var_dump($b); }

foob(1); // bool(true)
foob(1.5); // bool(true)
foob("1"); // bool(true)
foob("abc"); // bool(true)
foob(true); // bool(true)
foob(array()); // E_RECOVERABLE_ERROR
foob($obj); // E_RECOVERABLE_ERROR

function foos(string $s) { var_dump($s);
foos(1); // string("1")
foos(1.5); // string("1.5")
foos("1"); // string("1")
foos(true); // string("1")
foos(array()); // E_RECOVERABLE_ERROR
foos(new StdClass); // E_RECOVERABLE_ERROR
foos($objImpl__toStringORcast_object); // string(result)

Float works like int, so I won't list it out here...

So, what do you think?

Thanks,

Anthony

Actually, it turns out the segfault and auto-reference bugs were
easier than I thought to fix. I've updated both gists with the new
code, and it looks to be running quite well...

Hey all,

As promised, I've created a POC patch to implement scalar type hints,
the way that zend_parse_parameters handles hinting.  First off, here's
the patch:

Directly apply-able without re2c:
https://gist.github.com/2004623

Removing generated files (requires re2c to compile):
https://gist.github.com/2004650

It's a POC, but it mostly works.  There is one known issue: passing a
class implementing __toString to a string hinted function will raise a
segmentation fault.  There's also an issue of not separating the
argument on cast yielding to reference whether indicated or not, but
that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in
the cases where it would cast)... I'll work on cleaning it up, but I
wanted to show the concept before investing too much work...

So, basically, there are 4 new parameters:

bool
int
float
string

The casting vs error rules are identical to zend_parse_parameters.  So:

function fooi(int $i) { var_dump($i); }

fooi(1); // int(1)
fooi(1.5); // int(1)
fooi("1"); // int(1)
fooi("1abc"); // int(1) + notice about non-well-formed numeric
fooi("foo"); // E_RECOVERABLE_ERROR
fooi(true); // int(1)
fooi(array()); // E_RECOVERABLE_ERROR
fooi($obj); // E_RECOVERABLE_ERROR

function foob(bool $b) { var_dump($b); }

foob(1); // bool(true)
foob(1.5); // bool(true)
foob("1"); // bool(true)
foob("abc"); // bool(true)
foob(true); // bool(true)
foob(array()); // E_RECOVERABLE_ERROR
foob($obj); // E_RECOVERABLE_ERROR

function foos(string $s) { var_dump($s);
foos(1); // string("1")
foos(1.5); // string("1.5")
foos("1"); // string("1")
foos(true); // string("1")
foos(array()); // E_RECOVERABLE_ERROR
foos(new StdClass); // E_RECOVERABLE_ERROR
foos($objImpl__toStringORcast_object); // string(result)

Float works like int, so I won't list it out here...

So, what do you think?

Thanks,

Anthony

Anthony,

My concern with this type of patch is that what you are proposing are
not really hints, they are forced casts. As such they modify the data
potentially leading to data loss.

Hey all,

As promised, I've created a POC patch to implement scalar type hints,
the way that zend_parse_parameters handles hinting.  First off, here's
the patch:

Directly apply-able without re2c:
https://gist.github.com/2004623

Removing generated files (requires re2c to compile):
https://gist.github.com/2004650

It's a POC, but it mostly works.  There is one known issue: passing a
class implementing __toString to a string hinted function will raise a
segmentation fault.  There's also an issue of not separating the
argument on cast yielding to reference whether indicated or not, but
that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in
the cases where it would cast)... I'll work on cleaning it up, but I
wanted to show the concept before investing too much work...

So, basically, there are 4 new parameters:

bool
int
float
string

The casting vs error rules are identical to zend_parse_parameters.  So:

function fooi(int $i) { var_dump($i); }

fooi(1); // int(1)
fooi(1.5); // int(1)
fooi("1"); // int(1)
fooi("1abc"); // int(1) + notice about non-well-formed numeric
fooi("foo"); // E_RECOVERABLE_ERROR
fooi(true); // int(1)
fooi(array()); // E_RECOVERABLE_ERROR
fooi($obj); // E_RECOVERABLE_ERROR

function foob(bool $b) { var_dump($b); }

foob(1); // bool(true)
foob(1.5); // bool(true)
foob("1"); // bool(true)
foob("abc"); // bool(true)
foob(true); // bool(true)
foob(array()); // E_RECOVERABLE_ERROR
foob($obj); // E_RECOVERABLE_ERROR

function foos(string $s) { var_dump($s);
foos(1); // string("1")
foos(1.5); // string("1.5")
foos("1"); // string("1")
foos(true); // string("1")
foos(array()); // E_RECOVERABLE_ERROR
foos(new StdClass); // E_RECOVERABLE_ERROR
foos($objImpl__toStringORcast_object); // string(result)

Float works like int, so I won't list it out here...

So, what do you think?

Thanks,

Anthony

Anthony Ferrara wrote:

So, what do you think?

I am a big fan of this style. Accepting e.g. "1abc" as int(1) with a
notice seems like a better solution than anything else. A full error
would be too much towards strict typing (I wouldn't mind personally, but
others do have a strong opinion on this, as we've seen).

The only thing I'm not so crazy about is foob('abc') -> bool(true). I
can live with it, but I don't particularly like it as far as the typing
goes.

Ilia Alshanetsky wrote:

My concern with this type of patch is that what you are proposing are
not really hints, they are forced casts. As such they modify the data
potentially leading to data loss.

I disagree with Ilia on this, as the casts are only made if they can be
converted properly, and give E_RECOVERABLE_ERROR instead. Anything
that's going to have significant data loss is covered by that.

Bottom line: I'd personally use this, while I certainly would not use
the previous style (with (int) $foo e.g.).

--
Ryan McCue
<http://ryanmccue.info/

Hey all,

As promised, I've created a POC patch to implement scalar type hints,
the way that zend_parse_parameters handles hinting.  First off, here's
the patch:
Thanks for all the hard work you're putting into this :)

So, what do you think?
This is the proposal I like most. It allows for some type juggling,
but blocks off the ugly edge cases where dataloss would occur.

Thinking in that direction I'd say that the casting rules are still
too lax though:

a) I'm not sure that we really want to accept '123abc' on an int cast
with just a notice. In my eyes that is clearly malformed input, which
should not be accepted.

b) The bool cast rules also accept lots of input with dataloss. At
least the fact that "abc" is considered a valid bool seems odd.

Nikita

I like it.

(Now, it would be nice to have another RFC about custom object casting to
int, float and bool...)

Lazare INEPOLOGLOU
Ingénieur Logiciel

2012/3/9 Anthony Ferrara ircmaxell@gmail.com

Hey all,

As promised, I've created a POC patch to implement scalar type hints,
the way that zend_parse_parameters handles hinting. First off, here's
the patch:

Directly apply-able without re2c:
https://gist.github.com/2004623

Removing generated files (requires re2c to compile):
https://gist.github.com/2004650

It's a POC, but it mostly works. There is one known issue: passing a
class implementing __toString to a string hinted function will raise a
segmentation fault. There's also an issue of not separating the
argument on cast yielding to reference whether indicated or not, but
that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in
the cases where it would cast)... I'll work on cleaning it up, but I
wanted to show the concept before investing too much work...

So, basically, there are 4 new parameters:

bool
int
float
string

The casting vs error rules are identical to zend_parse_parameters. So:

function fooi(int $i) { var_dump($i); }

fooi(1); // int(1)
fooi(1.5); // int(1)
fooi("1"); // int(1)
fooi("1abc"); // int(1) + notice about non-well-formed numeric
fooi("foo"); // E_RECOVERABLE_ERROR
fooi(true); // int(1)
fooi(array()); // E_RECOVERABLE_ERROR
fooi($obj); // E_RECOVERABLE_ERROR

function foob(bool $b) { var_dump($b); }

foob(1); // bool(true)
foob(1.5); // bool(true)
foob("1"); // bool(true)
foob("abc"); // bool(true)
foob(true); // bool(true)
foob(array()); // E_RECOVERABLE_ERROR
foob($obj); // E_RECOVERABLE_ERROR

function foos(string $s) { var_dump($s);
foos(1); // string("1")
foos(1.5); // string("1.5")
foos("1"); // string("1")
foos(true); // string("1")
foos(array()); // E_RECOVERABLE_ERROR
foos(new StdClass); // E_RECOVERABLE_ERROR
foos($objImpl__toStringORcast_object); // string(result)

Float works like int, so I won't list it out here...

So, what do you think?

Thanks,

Anthony