[PHP-DEV] weak and strict type checking RFC
Hi, Last evening I put together a quick proposal for a weak and strict checking approach, since I felt that things were being concluded a bit prematurely. More importantly I detailed the issues I see with a pure strict type checking only approach. I am publishing it a bit prematurely imho, but its not without merit at this stage either and since I will be busy playing frisbee all weekend, I thought I get it out there for people to comment right now: http://wiki.php.net/rfc/typecheckingstrictandweak As Paul insisted that my initial proposal did not sufficiently high light the fact that there are other proposals, I moved my original proposal to the above location so that we can have a disambiguation page that lists all the various related proposals: http://wiki.php.net/rfc/typechecking Most of that is in there has been said/proposed on the list, so I am just pasting the key section on why I think strict checking is dangerous: Strict type checking does have the advantage that subtle bugs will be noticed more quickly and that function/method signatures will become yet more self documenting and therefore more expressive. Also doing these type checks based on the signature also means less code and better performance over having to hand code the validation Proponents of only providing strict type checking say that for the most part variables are defined with the proper type unless they come from an outside source, which usually requires validation anyways, which is a perfect opportunity to type cast. That is to define a variable that contains a boolean, developer will probably do “$is_foo = true” and not “$is_foo = 0”. While this may be true, it does means that developers using such strict type checking API's now require that users understand data types, which currently beginning developers do not necessarily need to. Furthermore quite often developers need to parse content out of strings and pass this to other methods. With strict type checking one is now forced to explicitly type cast. While its certainly doable, its also additional work that needs to be done while writing the code (“$foo_int = (int)substr($bar, 3, 10)”). Then again some might argue that this makes the code clearer. It also means that users of such strict typed API's will tend to simply cast and due to laziness (PHP is used for rapid development after all) might forgo validating first if the content is really what they expected. Without type checking the burden would be with the developer providing the API. Since its usually expected that an API is fairly often, it seems illogic to move this burden to the API users. More over due to this, a new kind of bug will be introduced due to over use of cast instead of hand coded parameter validation as is currently necessary. This could lead to even higher bug rates. As for outside sources needing validation. This is not always the case as most people do trust that the data returned from a database is in the expected format, even though for most RDBMS it will always be returned as string. Same applies to configuration files, which if defined in something else than PHP code will most likely only return strings, but who's values will usually not be validated. regards Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On 7/4/09, Lukas Kahwe Smith m...@pooteeweet.org wrote: Last evening I put together a quick proposal for a weak and strict checking approach, since I felt that things were being concluded a bit prematurely. More importantly I detailed the issues I see with a pure strict type checking only approach. Thanks for the effort, I just wanted to add one thing though. I'm not sure how this would work with php internals really but you didn't mention arrays at all in your examples. The way I see it, with the current conversion code, a weak bool type check would take array() as a valid false value, and while I agree that it's a useful behavior in conditionals sometimes, in the case of type checks it feels horribly wrong. So I hope it's just not mentionned because it's not a problem, otherwise I think it should be clarified. Cheers, Jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Veracity of statement that FastCGI is always enabled cannot be disabled in PHP 5.3
On Jul 3, 2009, at 10:58, Gwynne Raskind wrote: On Jul 3, 2009, at 11:39 AM, Ryan Schmidt wrote: On http://www.php.net/manual/en/migration53.sapi.php it says of PHP 5.3 that FastCGI is now always enabled and can not be disabled. See sapi/cgi/CHANGES for more details. The same text appears in the NEWS file. In sapi/cgi/CHANGES it says Now fastcgi is always enabled. [snip] So I believe the statement FastCGI is now always enabled is false, because FastCGI is not enabled if you request an Apache SAPI. And I believe the statement that it can not be disabled is false, because the --disable-cgi configure argument does disable it. I believe the correct documentation of PHP 5.3's capabilities would be, The FastCGI module is now built by default, but can be disabled by using --disable-cgi. It seems the language of the documentation is unclear. It is not that the CGI SAPI (now called the CGI-FCGI SAPI) is always built, in the fashion of CLI. It is, precisely, that the FastCGI support within the CGI SAPI can no longer be turned off. However, the SAPI selection process still procedes as it did before. Ah, now I understand. Now you can't get a plain-CGI version anymore; you always get a FastCGI version. But subject to the same limitations as before about when the CGI gets built at all. That makes sense. Thanks for the reply. The only CGI version of PHP I've used is the FastCGI version, so when I think of the PHP CGI SAPI, that's what I think of, and I sometimes forget that there is (was) another possibility. Hence when reading a statement that FastCGI is now always enabled, that translated in my mind to CGI is now always enabled hence the confusion when I found it not to be. I'll see what we can do about clarifying the documentation. Sorry for the confusion :). I think it would be clearer if it said FastCGI support in the CGI SAPI is now always enabled and cannot be disabled. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] are there alternate interfaces to the bug tracking system?
hi everyone, (if there's a better place to ask this, my apologies and feel free to redirect me!) does anyone know here if there is any machine-friendly interface to the php bug tracking system? in debian we have a service called bts-link[1] which we can use to track forwarded bugs in remote systems's (i.e. a bug reported in debian which has been linked with another bug such as one on bugs.php.net). for debian package maintainers this is a major boon since we can keep better track of bugs that have been fixed or otherwise addressed upstream. so what i'm wondering is: is there an easily parseable or structured interface (xmlrpc, soap, read-only JSON export, whatever) to the php.net bts that could be used to get a bug's information? or would such a bts-link service need to resort to scraping the page for a particular bug's status? thanks! sean [1] http://bts-link.alioth.debian.org/ ps - I'm cc'ing Sandro Tosi, who i believe could answer any questions you might have about the bts-link service in case you would only provide such access under certain conditions (he is not subscribed to this list). -- signature.asc Description: Digital signature
Re: [PHP-DEV] are there alternate interfaces to the bug tracking system?
On Sat, 4 Jul 2009, sean finney wrote: so what i'm wondering is: is there an easily parseable or structured interface (xmlrpc, soap, read-only JSON export, whatever) to the php.net bts that could be used to get a bug's information? or would such a bts-link service need to resort to scraping the page for a particular bug's status? There is no such thing at the moment, but I wouldn't mind seeing a patch for this. regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
Hello Internals.
I'm a userland PHP developer, I readed all the proposals about type
hinting and did some code writing with type hinting to see how it
looks like. Well, to my understanding it's a mess if both types of
type hinting are done.
Here is an example of a function:
function calculate_age($birthday_date, $year) {}.
How to type hint it?
Strictly or softly? Really depends on the case. If you use it
somewhere deep inside your API, than it probably should be strict. But
if not? You could get your params from anythere: database (as
strings), POST or GET (again strings), $year can be simply date('Y')
as a string or just some value from config as int. So what we see is
that strict type hinting is just too much here. Weak type hinting is
more appropriate. But do we need it at all? If I get my data from POST
or GET i'll certanly do a validation on them - trim the $year and
check it for is_numeric, $birthday_date will be checked by preg_match
to de a valid date format and then will be checked by checkdate() if
it's valid date. That leaves even weak type hinting without any real
work. If I get it from database, I'll just pass it to function,
because that data is validated and contains proper values - in this
case strict type hints will give an error for $year, because it's a
string from database and soft will just make a conversion to int so it
would happen earlier that calculations.
Strict type hint's are useless in works with database results. And
mostly in WEB we work with database results and data from GET/POST or
other sources like XML, JSON API's and so on. There data is always as
strings. Do you want that data be converted to appropriate types by
userland code something like this?
$res = $mysqli-query($sql);
if ($res $res-num_rows) {
while ($row = $res-fetch_assoc()) {
foreach ($row as $k = $v) {
if (is_numeric($v)) {
$row[$k] = (int)$v;
}
}
}
}
// Now we can use strict type hints!
Looks like it's the weak type hinting that will be used in most cases.
The question I have what will be in such case with weak type hints?:
function test(array $data) {}
test(1);
For me that should be an error, but the PHP mechanics of type
conversions should convert that 1 to array(1). Same with objects. In
object or array case most people probably will want a big error so
they could investigate there is a bug and fix it. But with strings and
integers/floats I'd prefer just silent type conversion. But you people
like consistency and I'd predict you would do int to array conversion
with weak type hinting, same as string to int/float.
A little bit messy, but I believe you got the point. My IMHO is that
a). There can't be a consistent way for all type conversions b).
Strict type hinting is out of the question.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On Sat, 4 Jul 2009, Lukas Kahwe Smith wrote:
I am publishing it a bit prematurely imho, but its not without merit
at this stage either and since I will be busy playing frisbee all
weekend, I thought I get it out there for people to comment right now:
http://wiki.php.net/rfc/typecheckingstrictandweak
Like Ilia mentioned on IRC, there is no reason why the strict type
checking which he proposes is necessarily a conflict with the weak type
checking.
So I would much rather have seen an RFC where you are trying to
make a case why we would need week type checking, instead of saying that
strict type checking is bad. You might not agree with the strict type
checking, but people ask for it, people have been using it and there are
plenty of reasons why it is useful—whether you see it or not.
So I would propose to:
1. have ilia's strict typing patch (minus scalar and numeric)
2. have a patch that also adds for casting type hints from your RFC.
Those could (and should) be considered as *two* new features.
As for syntax, I believe the following would be best:
function add_user(string $name, string $phone_number, (int) $age) { .. }
because:
1. the casting type hint (int) $var is used for normal casting already
2. the strict type hint int $var is already used for class names
regards,
Derick
--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
Hi Lukas, On Sat, Jul 4, 2009 at 7:20 AM, Lukas Kahwe Smithm...@pooteeweet.org wrote: Last evening I put together a quick proposal for a weak and strict checking approach, since I felt that things were being concluded a bit prematurely. More importantly I detailed the issues I see with a pure strict type checking only approach. I can't see the difference between your proposal and the conclusion I reached yesterday? (which was that there is a near consensus around strict checks by default, with casts allowed with some syntax). Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] are there alternate interfaces to the bug tracking system?
so what i'm wondering is: is there an easily parseable or structured interface (xmlrpc, soap, read-only JSON export, whatever) to the php.net bts that could be used to get a bug's information? or would such a bts- link service need to resort to scraping the page for a particular bug's status? Not sure if this really helps you (and I agree that the bug system really needs some sort of better programmatic interface), but you can translate most bugs.php.net pages into rss (which is easier to parse than HTML... usually (-: ) by prepending rss/ to the URL. This useful for reading. For example: http://bugs.php.net/bug.php?id=46944 becomes: http://bugs.php.net/rss/bug.php?id=46944 and: http://bugs.php.net/search.php?boolean=0limit=Allorder_by=statusdirection=ASCcmd=displaystatus=Openbug_type []=Documentation+problembug_age=0 becomes: http://bugs.php.net/rss/search.php?boolean=0limit=Allorder_by=statusdirection=ASCcmd=displaystatus=Openbug_type []=Documentation+problembug_age=0 S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] are there alternate interfaces to the bug tracking system?
Just another question: may you please list me all the possible 'Status' field values? In particular we are interested in those 'Status'es that identify the bug as closed and wontfix. I believe all current statuses are declared here: http://cvs.php.net/viewvc.cgi/php-bugs-web/include/functions.inc?view=markup#l82 S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On 04.07.2009, at 14:27, Derick Rethans der...@php.net wrote:
So I would propose to:
1. have ilia's strict typing patch (minus scalar and numeric)
2. have a patch that also adds for casting type hints from your RFC.
Those could (and should) be considered as *two* new features.
As for syntax, I believe the following would be best:
function add_user(string $name, string $phone_number, (int) $age)
{ .. }
because:
1. the casting type hint (int) $var is used for normal casting
already
2. the strict type hint int $var is already used for class names
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On 04.07.2009, at 16:05, Paul Biggar paul.big...@gmail.com wrote: Hi Lukas, On Sat, Jul 4, 2009 at 7:20 AM, Lukas Kahwe Smithm...@pooteeweet.org wrote: Last evening I put together a quick proposal for a weak and strict checking approach, since I felt that things were being concluded a bit prematurely. More importantly I detailed the issues I see with a pure strict type checking only approach. I can't see the difference between your proposal and the conclusion I reached yesterday? (which was that there is a near consensus around strict checks by default, with casts allowed with some syntax). Well to me it Sounded like you wanted to Rely on Standard Type juggling and what i am proposing is more strict than that. More over i am Not convinced that strict should Be the Default. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] are there alternate interfaces to the bug tracking system?
On Sat, Jul 4, 2009 at 18:43, Sean Coatess...@caedmon.net wrote: Just another question: may you please list me all the possible 'Status' field values? In particular we are interested in those 'Status'es that identify the bug as closed and wontfix. I believe all current statuses are declared here: http://cvs.php.net/viewvc.cgi/php-bugs-web/include/functions.inc?view=markup#l82 That's perfect! Thanks a lot for your help! I'll let you know when I'll come up with the final solution. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
hi. On Sat, Jul 4, 2009 at 8:12 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote: Well to me it Sounded like you wanted to Rely on Standard Type juggling and what i am proposing is more strict than that. More over i am Not convinced that strict should Be the Default. The default is what we have now (implicit mixed). The (type) syntax is known already, it would be rather confusing to use yet another syntax in this case. I like the current proposal with int foo for strict and (int) foo for an automatic cast. As Gwynne suggested on IRC, I would also like to have mixed, for completeness. It brings nothing but it makes the code clearer. Another useful type would be callback. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
I can't see the difference between your proposal and the conclusion I
reached yesterday?
(which was that there is a near consensus around strict checks by
default, with casts allowed with some syntax).
Well to me it Sounded like you wanted to Rely on Standard Type juggling
and what i am proposing is more strict than that. More over i am Not
convinced that strict should Be the Default.
Regards,
Lukas
Just wanted to note the weak string check is the same as the strict one in
the RFC since it appears to be incomplete. It should encompass any type that
can cast to a string. That includes any scalar, and also objects with
__toString method.
Also if this will be introduced, it needs to account for mixed type
arguments, such as null/bool/int or null/numeric etc. The RFC doesn't
mention null at all leaving me to assume null is always allowed, no matter
what.
I'm a supporter of strict typing for languages in general, however, in *PHP*
in particular, strict checks don't make sense to me, given its current
behavior.
This is a language where summing up an integer and a string can result in a
float. API authors will start assuming strictness from their clients that is
hard to achieve, and in the end result in peppering function/method calls
with explicit type casting on each argument. We do not want that, I suppose.
There is one type of check that can be added right now, however, while this
discussion continues:
function add_user(scalar name, scalar phone_number, scalar age) {}
I think we can all agree, if we can check for a class and array, then
checking for a scalar is a natural constraint. It's both strict and weak at
the same time since it's generic enough not to need that separation. Scalar
here is defined by the same rules as is_scalar(), but also allows null as a
passed value to be consistent with the other check types.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi Ilia,
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org wrote:
There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most people
RE your second patch, from http://ilia.ws/patch/type_hint_53_v2.txt
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.109
diff -u -p -a -d -u -r1.647.2.27.2.41.2.109 zend_compile.c
--- Zend/zend_compile.c 7 Jun 2009 15:46:51 - 1.647.2.27.2.41.2.109
+++ Zend/zend_compile.c 4 Jul 2009 17:20:50 -
@@ -1511,10 +1514,9 @@ void zend_do_receive_arg(zend_uchar op,
zend_error(E_COMPILE_ERROR, Default
value for parameters with a
class type hint can only be NULL);
}
}
- } else {
- cur_arg_info-array_type_hint = 1;
- cur_arg_info-class_name = NULL;
- cur_arg_info-class_name_len = 0;
+ break;
+
+ case IS_ARRAY:
So, to signify an array type hint, we used to use 1, and we now use
IS_ARRAY, which is 4. I'm not 100% sure that's an ABI problem, but I
just wanted to check.
if (op == ZEND_RECV_INIT) {
if (Z_TYPE(initialization-u.constant) ==
IS_NULL ||
(Z_TYPE(initialization-u.constant) == IS_CONSTANT
!strcasecmp(Z_STRVAL(initialization-u.constant), NULL))) {
cur_arg_info-allow_null = 1;
@@ -1522,6 +1524,56 @@ void zend_do_receive_arg(zend_uchar op,
zend_error(E_COMPILE_ERROR, Default
value for parameters with
array type hint can only be an array or NULL);
}
}
+ break;
+
+ /* scalar type hinting */
+ case IS_BOOL:
+ case IS_STRING:
+ case IS_LONG:
+ case IS_DOUBLE:
+ case IS_RESOURCE:
+ case IS_NUMERIC:
+ case IS_SCALAR:
+ case IS_OBJECT:
+ if (op == ZEND_RECV_INIT) {
+ if (Z_TYPE(initialization-u.constant) !=
class_type-u.constant.type Z_TYPE(initialization-u.constant) !=
IS_NULL) {
+ zend_error(E_COMPILE_ERROR, Default
value for parameters with
%s type hint can only be %s or NULL,
zend_get_type_by_const(class_type-u.constant.type),
zend_get_type_by_const(class_type-u.constant.type));
That error says NULL is allowed for scalars, which I presume is wrong.
+ /* type forcing via cast */
+ case FORCE_BOOL:
+ case FORCE_STRING:
+ case FORCE_LONG:
+ case FORCE_DOUBLE:
+ if (op == ZEND_RECV_INIT) {
+ switch (Z_TYPE(initialization-u.constant)) {
+ case IS_ARRAY:
+ case IS_OBJECT:
+ case IS_RESOURCE:
+ zend_error(E_COMPILE_ERROR,
Default value for parameters with
a forced type of %s can only be a scalar,
zend_get_type_by_const(class_type-u.constant.type));
I think a default parameter of the wrong type must signify a
programmer error, so should be forbidden.
Index: Zend/zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.716.2.12.2.24.2.44
diff -u -p -a -d -u -r1.716.2.12.2.24.2.44 zend_execute.c
--- Zend/zend_execute.c 4 Jun 2009 18:20:42 - 1.716.2.12.2.24.2.44
+++ Zend/zend_execute.c 4 Jul 2009 17:20:50 -
@@ -506,13 +506,82 @@ static inline int zend_verify_arg_type(z
}
} else if (cur_arg_info-array_type_hint) {
if (!arg) {
- return zend_verify_arg_error(zf, arg_num, cur_arg_info,
be an
array, , none, TSRMLS_CC);
+ return zend_verify_arg_error(zf, arg_num, cur_arg_info,
be of the
type , zend_get_type_by_const(cur_arg_info-array_type_hint), none,
TSRMLS_CC);
}
- if (Z_TYPE_P(arg) != IS_ARRAY (Z_TYPE_P(arg) != IS_NULL ||
!cur_arg_info-allow_null)) {
- return zend_verify_arg_error(zf, arg_num, cur_arg_info,
be an
array, , zend_zval_type_name(arg), TSRMLS_CC);
+
+ /* existing type already matches the hint or forced type */
+ if (Z_TYPE_P(arg) == cur_arg_info-array_type_hint ||
Z_TYPE_P(arg)
== (cur_arg_info-array_type_hint ^ (17))) {
+ return 1;
+ }
+
+ /* NULL type give, check if parameter is optional */
I
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
It should be fine
Ilia Alshanetsky
On 2009-07-04, at 2:49 PM, Paul Biggar paul.big...@gmail.com wrote:
Hi Ilia,
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org
wrote:
There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most
people
RE your second patch, from http://ilia.ws/patch/type_hint_53_v2.txt
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.109
diff -u -p -a -d -u -r1.647.2.27.2.41.2.109 zend_compile.c
--- Zend/zend_compile.c7 Jun 2009 15:46:51 -
1.647.2.27.2.41.2.109
+++ Zend/zend_compile.c4 Jul 2009 17:20:50 -
@@ -1511,10 +1514,9 @@ void zend_do_receive_arg(zend_uchar op,
zend_error(E_COMPILE_ERROR, Default value for
parameters with a
class type hint can only be NULL);
}
}
-} else {
-cur_arg_info-array_type_hint = 1;
-cur_arg_info-class_name = NULL;
-cur_arg_info-class_name_len = 0;
+break;
+
+case IS_ARRAY:
So, to signify an array type hint, we used to use 1, and we now use
IS_ARRAY, which is 4. I'm not 100% sure that's an ABI problem, but I
just wanted to check.
if (op == ZEND_RECV_INIT) {
if (Z_TYPE(initialization-u.constant) == IS_NULL ||
(Z_TYPE(initialization-u.constant) == IS_CONSTANT
!strcasecmp(Z_STRVAL(initialization-u.constant), NULL))) {
cur_arg_info-allow_null = 1;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On Sat, Jul 4, 2009 at 7:12 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote: I can't see the difference between your proposal and the conclusion I reached yesterday? (which was that there is a near consensus around strict checks by default, with casts allowed with some syntax). Well to me it Sounded like you wanted to Rely on Standard Type juggling and what i am proposing is more strict than that. More over i am Not convinced that strict should Be the Default. I don't know what you mean by standard type-juggling. Your proposal really does not outline what you want very much, just what you're against. As for strictness, if your proposal suggests that strict typing is the default, I cannot see where. As I see it, each proposal is a very minor variation on the other. My proposal had an extra layer, but it it wasn't well received, so I've withdrawn it. Ilia has a patch now that does what I understand you want, using the (int) syntax, with strict by default. I may be wrong, but I believe the only thing left to argue about is strict versus weak by default. I was originally of the opinion that weak typing should be the default. However, it had barely any support, whereas there was great support for strict by default. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On 04.07.2009, at 21:10, Paul Biggar paul.big...@gmail.com wrote: On Sat, Jul 4, 2009 at 7:12 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote: I can't see the difference between your proposal and the conclusion I reached yesterday? (which was that there is a near consensus around strict checks by default, with casts allowed with some syntax). Well to me it Sounded like you wanted to Rely on Standard Type juggling and what i am proposing is more strict than that. More over i am Not convinced that strict should Be the Default. I don't know what you mean by standard type-juggling. Your proposal really does not outline what you want very much, just what you're against. As for strictness, if your proposal suggests that strict typing is the default, I cannot see where. I did Not specify what doesnt Match in the RFC. I will fix that omission on monday. I assumed it was clear that i tried to Provide Complete examples for what will Pass. So Passung a String with anything but 1 or 0 would Not Pass à Bool Type check. The other Thing that i wanted to make clear is that After the weak Type check is that a cast should Happen afterwards. Finally i wanted to clarify my concerns about Structure typing to ensure that the Short Syntax is a weak check and only with additional Chars like the proposed ! Or something like that, can One get a Strict Type check. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi!
RE your second patch, from http://ilia.ws/patch/type_hint_53_v2.txt
Some notes on this patch:
- I still think the matter of interfaces and inheritance should be dealt
with (and just comparing hints is not enough, it should be full
LSP-compliant check).
- It looks like you can't have class named string anymore, or at least
you can't use it in typehints (you can in 5.3). Same with all other type
names there.
- I see no reflection method that allows to get the type of the
parameter (as opposed to checking if the parameter belongs to a certain
type)
- The patch contains the check that the constant for an optional
parameter is not an object. AFAIK you can't have constant with object
type in PHP. Which also means initializer for any object type can only
be null.
- There seems to be no way to have default value with IS_NUMERIC
typecheck since the check
Z_TYPE(initialization-u.constant) != class_type-u.constant.type
will always fail for IS_NUMERIC - there's no zval carrying type
IS_NUMERIC. Same for IS_SCALAR.
- Also, I'm not sure what would happen there if I have:
function foo(numeric $param = CONSTANT)
and the value of CONSTANT may be not known in the compile-time. Looks
like right now it would just fail since CONSTANT has IS_CONSTANT type.
That would be confusing if you couldn't use constants for default values
with typehints.
- Shuouldn't this:
if (Z_TYPE_P(arg) == cur_arg_info-array_type_hint || Z_TYPE_P(arg) ==
(cur_arg_info-array_type_hint ^ (17))) {
be this:
if (Z_TYPE_P(arg) == (cur_arg_info-array_type_hint 0x7F)) {
this would be one check instead of two, and the type of argument zval
can't really be FORCE_*, can it?
- Are you sure with FORCE_* argument converting operation shouldn't be
convert_to_*_ex?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] are there alternate interfaces to the bug tracking system?
On Sat, Jul 4, 2009 at 20:15, Sandro Tosimo...@debian.org wrote: On Sat, Jul 4, 2009 at 18:43, Sean Coatess...@caedmon.net wrote: Just another question: may you please list me all the possible 'Status' field values? In particular we are interested in those 'Status'es that identify the bug as closed and wontfix. I believe all current statuses are declared here: http://cvs.php.net/viewvc.cgi/php-bugs-web/include/functions.inc?view=markup#l82 That's perfect! Thanks a lot for your help! I'll let you know when I'll come up with the final solution. If you can tell us what exactly you need we can hook you up quite easily... You want json result set of status/assigned/last updated/summary/... just let php-webmas...@lists.php.net know and it'll get fixed as soon as someone sees your mail (we can't keep up with the irrelevant traffic on intern...@...) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
