Hi list.
In advance, sorry for muddying the waters even further.
Following the current discussion about typehints to primitives, I'm
wondering if anyone have ever suggested to include some sort of
user-land contract system, such as the one that exists in
plt-scheme[1]
Given the dynamic nature of php, I would suspect that it might be a
much better fit. Unlike the semi-static typecheck that typehints can
give, a contract system would be much more expressive and would add a
lot more value (in my opinion anyway).
I think part of the reason for the popularity of typehints is that it
looks familiar for people coming from Java/C++/C#. The biggest
challenge for such a contract system would then be to come up with
something that doesn't look too alien. A simple way that I can think
of is to overload the meaning of typehints so that they may either
denote a class/interface (as they work currently) OR they may be a
function which takes the variable as argument and yields a boolean.
Eg.:
function array_of_numeric($x) {
foreach ($x as $val) {
if (!is_numeric($val)) {
return false;
}
}
return true;
}
class Foo {
/** Example use-case for a contract */
function sum(array_of_numeric $a) {
return array_sum($a);
}
}
This is just one suggestion - There are other ways to implement the concept.
I can see a number of benefits to a contract system over the currently
discussed typehint system:
1) It covers all the use cases for a type-based system (You can use
`is_integer` as a contract, if you want that)
2) It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs.
3) It's focused on the interface of input-parameters, rather than their type.
[1] http://docs.plt-scheme.org/guide/contracts.html
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
