[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend.c zend_execute_API.c zend_vm_def.h zend_vm_execute.h php-src NEWS
Another idea: In case xdebug overwrites zend_execute() it can set EG(return_value_ptr_ptr) to point to some local variable then call original executor and then print pass return_value to caller or destroy it dependent on previous value of EG(return_value_ptr_ptr). Thanks. Dmitry. Derick Rethans wrote: On Fri, 11 Apr 2008, Dmitry Stogov wrote: Sorry, but I think mainly about PHP performance, and of course I didn't know that you trace return_values it in xdebug. After the patch, in case if return value is not used we set EG(return_value_ptr_ptr) to NULL before call to nested execute(). I assume you can just check for (EG(return_value_ptr_ptr)==NULL) before write it. Will it work for you? I'm already doing that, so not went really wrong. I am just wondering whether it would be possible to always have those return values there through some kind of option. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions = Apache Crash in PHP 5.3 Snaps
Hi Scott, Could you provide a script to reproduce the crash? Thanks. Dmitry. Scott MacVicar wrote: Jeremy Privett wrote: Another week later and still no response. I would hope /someone/ thinks this a critical issue and needs to be resolved. Is /anyone/ looking at this at all? Thanks. The line that is crashing was last changed by Dmitry on January 24th, see http://php.markmail.org/message/7egzhpab6reff7lj I can't see any errors with valgrind. Any idea Dmitry? Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
What about types like
array
mixed
Ok, for mixed we may not use type hinting at all - does patch allow to
hint only part of function args?
If we have a function, witch takes as 1st argument array or string and other
args should have strict types or just use call like myFunc(Array($string),
.) ? This is just to know this for sure.
2008/4/17, Felipe Pena [EMAIL PROTECTED]:
Hello again!
Now with both parameter and return value type hints.
For parameter type hints, i have completed the actual implementation
with the leftover php types:
- string (binary string and unicode)
- integer (accepting numeric string too)
- double (accepting numeric string too)
- boolean ('0', '1', true, false)
- resource
- object
(Yes, following our dynamic typing)
Since then, the patch also includes new methods to Reflection:
- isInt()
- isDouble()
- isBool()
- isString()
- isObject()
- isResource()
And for return value, i have modified and improved the previous patch,
and now it is using only the (type) notation. Hence, that
implementation doesn't make any BC break.
Examples, patches and tests: http://wiki.php.net/rfc/typehint
Thanks.
--
Regards,
Felipe Pena.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: preeti
For maintaining synchronize code in the team -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Scanner fixes and tweaks
Hello guys, - Original Message - From: Philip Olson Sent: Thursday, April 10, 2008 On 10 Apr 2008, at 09:48, Marcus Boerger wrote: Hello Matt, Thursday, April 10, 2008, 3:50:41 PM, you wrote: Hi Scott, [...] BTW, maybe you could change the name in that 5.2 NEWS entry to just Matt? No big deal, but that's what it's been other than the first few entries. :-) We use short names only for people with a php.net account. Well, now that I have a php.net account, and 5.2.6 will be released, can someone change my name? :-) Unless I'm granted access to do it myself...? Didn't know that about short names -- I see my name 11 times in the 5.2 NEWS, and the last 6 are just Matt. I think Ilia just started using that after the first 5. :-P Hello Matt- Just in case you've not seen this page yet, please go here and apply :) http://php.net/cvs-php.php Yeah thanks, I knew about the CVS request page, just never applied before! Regards, Philip Thanks, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Type hints (parameter and return value)
Felipe Pena wrote:
For parameter type hints, i have completed the actual implementation
with the leftover php types:
- string (binary string and unicode)
- integer (accepting numeric string too)
- double (accepting numeric string too)
- boolean ('0', '1', true, false)
- resource
- object
I don't like the difference between
function (int) test($value) { ... }
and
function test(integer $value) { ... }
I don't think we should introduce two different names for something
which is basically the same. Even if there is (as I guess) a slight
difference (int *really* being int and integer allowing strings
containing numbers), which makes the WTF factor even higher IMHO.
Also about New tokens (new keywords): I haven't tried the patch so
excuse me asking. Does this mean $this-string is invalid because string
is a new keyword? Then I'd be strongly against having these new keywords.
Is there any performance impact for people not using type hints?
Just to make it clear: I think type hinting is a Bad Idea(tm) anyway but
*if* it is implemented I think you should consider the above points.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Scanner fixes and tweaks
On 17.04.2008 14:54, Matt Wilmas wrote: Well, now that I have a php.net account, and 5.2.6 will be released, can someone change my name? :-) Unless I'm granted access to do it myself...? Done =) Didn't know that about short names -- I see my name 11 times in the 5.2 NEWS, and the last 6 are just Matt. I think Ilia just started using that after the first 5. :-P -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Type hints (parameter and return value)
Christian Schneider
I don't like the difference between
function (int) test($value) { ... }
and
function test(integer $value) { ... }
First is function return value should be int, second is function arg should
be int.
So full syntax will be like this
function (integer) test(integer $value) { ... }
That means function takes an integer as argument and returns integer value.
If any is violated - Catchable error will be thrown.
That's my understanding of this patch. Some more examples
function (resource) query(string $table, array $where = array(), array
$limit = array()) { ... }
function (array) getData(string $table, array $limit = array(0, 20), array
$where = array()) { /* cals query and generates an array from result */ }
etc.
Re: [PHP-DEV] [PATCH] Scanner fixes and tweaks
Thanks Tony! - Original Message - From: Antony Dovgal Sent: Thursday, April 17, 2008 On 17.04.2008 14:54, Matt Wilmas wrote: Well, now that I have a php.net account, and 5.2.6 will be released, can someone change my name? :-) Unless I'm granted access to do it myself...? Done =) Didn't know that about short names -- I see my name 11 times in the 5.2 NEWS, and the last 6 are just Matt. I think Ilia just started using that after the first 5. :-P -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Type hints (parameter and return value)
Arvids Godjuks wrote:
So full syntax will be like this
function (integer) test(integer $value) { ... }
I guess you are right: int and integer seem to be aliase and both check
for int *or* numeric strings, not the type int.
It is also not clear if (string) accepts ints/floats which are often
valid values.
I think a table of which type hint accepts which values would be useful.
And there also remains the issue with the keywords where I'd like to be
enlightened :-)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Hi,
Your current implementation seems to be inconsistent with both itself
and the rest of PHP. I hope this can be rectified before it is
included. PHP is inconsisent enough without adding more.
1.) There are a number of is_* functions. It seems obvious that they
should be consistent with this. So you're missing numeric and scalar.
I'm not clear if there is a is_unicode(), but if so, that should be
consistent too. (I believe scalar is particularly important, at a
language level, since mixed and object are provided).
2.) is_int has different semantics to the int type hint. Numeric
strings qualify as the latter, but not the former. In general this is
a problem. It seems type hints can only be made consistent if they
convert the actual parameter to the type which is hinted. (Note that
for call-by-reference, this will change the value in the caller, not
just the copy in the callee - I think this is a good idea). As an
example, this will fail, which it shouldnt: function y (int $x) {
assert (is_int($x); } y (24);
3.) This doesnt seem to be integrated with class type hints, in the
codebase. I wonder why that is? (I don't care all that much, I'm just
wondering).
I hope we can get these ironed out.
Thanks in advance.
Paul
On Thu, Apr 17, 2008 at 5:50 AM, Felipe Pena [EMAIL PROTECTED] wrote:
Hello again!
Now with both parameter and return value type hints.
For parameter type hints, i have completed the actual implementation
with the leftover php types:
- string (binary string and unicode)
- integer (accepting numeric string too)
- double (accepting numeric string too)
- boolean ('0', '1', true, false)
- resource
- object
(Yes, following our dynamic typing)
Since then, the patch also includes new methods to Reflection:
- isInt()
- isDouble()
- isBool()
- isString()
- isObject()
- isResource()
And for return value, i have modified and improved the previous patch,
and now it is using only the (type) notation. Hence, that
implementation doesn't make any BC break.
Examples, patches and tests: http://wiki.php.net/rfc/typehint
Thanks.
--
Regards,
Felipe Pena.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: barzaz
Helping to develop Package Services_Webervice and its doc. I talked with the leader of the package (Manfred Weber) and Helgi Ãormar Ãorbjörnsson (dufuz) and they told me to request this account. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions = Apache Crash in PHP 5.3 Snaps
My original message was sent just to Dmitry (instead to thel ist), and he
replied (again only to me instead to the list) that it is fixed in the CVS.
Sorry for the confusion.
Thanks for the fix.
Vesselin Kenashkov
On Thu, Apr 17, 2008 at 4:01 PM, Dmitry Stogov [EMAIL PROTECTED] wrote:
The bug has been already fixed in CVS.
Thanks. Dmitry.
Vesselin Kenashkov wrote:
?php
throw new Exception('test');
?
With this example I can reproduce the crash under Windows Vista Business
using today's php5.3-dev and php6.0-dev snapshots.
On Thu, Apr 17, 2008 at 10:02 AM, Dmitry Stogov [EMAIL PROTECTED]mailto:
[EMAIL PROTECTED] wrote:
Hi Scott,
Could you provide a script to reproduce the crash?
Thanks. Dmitry.
Scott MacVicar wrote:
Jeremy Privett wrote:
Another week later and still no response. I would hope
/someone/ thinks this a critical issue and needs to be
resolved. Is /anyone/ looking at this at all?
Thanks.
The line that is crashing was last changed by Dmitry on January
24th, see http://php.markmail.org/message/7egzhpab6reff7lj
I can't see any errors with valgrind.
Any idea Dmitry?
Scott
--PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions = Apache Crash in PHP 5.3 Snaps
Dmitry Stogov wrote: Hi Scott, Could you provide a script to reproduce the crash? Thanks. Dmitry. Scott MacVicar wrote: Jeremy Privett wrote: Another week later and still no response. I would hope /someone/ thinks this a critical issue and needs to be resolved. Is /anyone/ looking at this at all? Thanks. The line that is crashing was last changed by Dmitry on January 24th, see http://php.markmail.org/message/7egzhpab6reff7lj I can't see any errors with valgrind. Any idea Dmitry? Scott http://bugs.php.net/bug.php?id=44226 ?php throw new Exception; ? That's all you need - throwing any type of exception makes it blow up -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
On Thu, 2008-04-17 at 14:52 +0200, Paul Biggar wrote:
Hi,
Your current implementation seems to be inconsistent with both itself
and the rest of PHP. I hope this can be rectified before it is
included. PHP is inconsisent enough without adding more.
1.) There are a number of is_* functions. It seems obvious that they
should be consistent with this. So you're missing numeric and scalar.
I'm not clear if there is a is_unicode(), but if so, that should be
consistent too. (I believe scalar is particularly important, at a
language level, since mixed and object are provided).
2.) is_int has different semantics to the int type hint. Numeric
strings qualify as the latter, but not the former. In general this is
a problem. It seems type hints can only be made consistent if they
convert the actual parameter to the type which is hinted. (Note that
for call-by-reference, this will change the value in the caller, not
just the copy in the callee - I think this is a good idea). As an
example, this will fail, which it shouldnt: function y (int $x) {
assert (is_int($x); } y (24);
The problem with this is that there's not much point in converting the
value. PHP will do that anyway, making this kind of pointless.
3.) This doesnt seem to be integrated with class type hints, in the
codebase. I wonder why that is? (I don't care all that much, I'm just
wondering).
This works in a different way. Rather than just checking the type, it
checks the value (such as a numeric string).
Overall, I think type hinting should work by checking the type. If it
does not match, raise an error. For example, int means int, not numeric
string.
This only serves to include an additional type juggling system into php,
which is very confusing.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
On Thu, Apr 17, 2008 at 10:01:13AM -0400, Sam Barrow wrote:
On Thu, 2008-04-17 at 14:52 +0200, Paul Biggar wrote:
just the copy in the callee - I think this is a good idea). As an
example, this will fail, which it shouldnt: function y (int $x) {
assert (is_int($x); } y (24);
The problem with this is that there's not much point in converting the
value. PHP will do that anyway, making this kind of pointless.
If inside y() you have something like:
for( $i = 0; $i $x; $i++ )
you will end up converting $x to integer $x times ... which will eat
CPU if $x is large -- I tried it.
An:
assert (is_int($x))
followed by:
$x = (int)$x
is the way to go.
This only serves to include an additional type juggling system into php,
which is very confusing.
If you don't understand it: don't use it.
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Hi Sam,
On Thu, Apr 17, 2008 at 4:01 PM, Sam Barrow [EMAIL PROTECTED] wrote:
\ 2.) is_int has different semantics to the int type hint. Numeric
strings qualify as the latter, but not the former. In general this is
a problem. It seems type hints can only be made consistent if they
convert the actual parameter to the type which is hinted. (Note that
for call-by-reference, this will change the value in the caller, not
just the copy in the callee - I think this is a good idea). As an
example, this will fail, which it shouldnt: function y (int $x) {
assert (is_int($x); } y (24);
The problem with this is that there's not much point in converting the
value. PHP will do that anyway, making this kind of pointless.
That is not quite correct. PHP's weak typing is somewhat inconsistent,
and in the example I included, it will not coerce the value of $x. An
'int' type hint is not the same as is_int (), which is a mistake.
It seems the easiest thing is to make the conversion mandatory at
call-time. Alternatives would include weakening is_int(), or making
the 'int' hint fail for numeric strings (as you mention below). I
believe these two solutions are not as good.
Overall, I think type hinting should work by checking the type. If it
does not match, raise an error. For example, int means int, not numeric
string.
This only serves to include an additional type juggling system into php,
which is very confusing.
This is one alternative. The aim should be consistency (or as you say,
avoiding confusion). This weak typing is already part of the language,
so I don't believe it is inconsistent, though your suggestion clearly
is. However, it is more consistent than, and therefore preferable to,
the current patch.
Thanks,
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Win32 mail() issue and potential fix - needs better brains than me to verify solution.
Hi.
I have finally managed to get php to compile for windows (yippee for me).
So I can now try and get mail() working again.
The issue is that in ext/standard/mail.c (/* $Id: mail.c,v
1.87.2.1.2.7.2.3 2007/12/31 07:17:15 sebastian Exp $ */), line 197,
the test of ...
if (!sendmail_path)
always evaluates to false when there is no sendmail_path which would
be the case on windows.
The next line differentiates between processing for windows/netware
and everything else.
If the test is
if(0 == strlen(sendmail_path))
then that would work.
The INI_STR call in Line 194 always returns a string if the directive
is known (doesn't need to be set, just has to exist as a directive).
So, I've attached a patch which I have compiled and tested on Windows.
This is in relation to bug http://bugs.php.net/bug.php?id=43348
Index: mail.c
===
RCS file: /repository/php-src/ext/standard/mail.c,v
retrieving revision 1.87.2.1.2.7.2.3
diff -u -u -r1.87.2.1.2.7.2.3 mail.c
--- mail.c 31 Dec 2007 07:17:15 - 1.87.2.1.2.7.2.3
+++ mail.c 17 Apr 2008 14:40:33 -
@@ -194,7 +194,7 @@
char *sendmail_path = INI_STR(sendmail_path);
char *sendmail_cmd = NULL;
- if (!sendmail_path) {
+ if (0 == strlen(sendmail_path)) {
#if (defined PHP_WIN32 || defined NETWARE)
/* handle old style win smtp sending */
if (TSendMail(INI_STR(SMTP), tsm_err, tsm_errmsg, headers,
subject, to, message, NULL, NULL, NULL TSRMLS_CC) == FAILURE) {
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=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
Re: [PHP-DEV] CVS Account Request
Here are the patches against 5.2 HEAD.
Modified API's are:
1) pg_lo_create now accepts an optional parameter (large object
id). This corresponds to lo_create() which is new in PostgreSQL 8.1.
2) new API: pg_lo_import_with_oid. Same as pg_lo_import except that it
accepts large object id. This corresponds to lo_import_with_oid()
which is new in PostgreSQL 8.4 (current).
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Hello Marcus,
Thanks for guiding me. I'm going to make patches in a few days.
BTW, the problem I'm talking about does not seem to exist in the bug
database.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Hello Tatsuo,
first of all thanks for offering to help!
the usual way is to provide a few patches. You can check
http://bugs.php.net for open bugs in your area. When we like the patches
we'll apply them and give you an account.
marcus
Monday, April 14, 2008, 1:21:47 PM, you wrote:
Hi,
I would like to contribute to ext/pgsql module. Could I have CVS
account?
I've been working on PostgreSQL development for years. My intention
is to catch up PostgreSQL develpment especially when new API is
added. For example an API added to PostgreSQL 8.1 (back to 2005) is
not in PHP yet.
I have talked to Yasuo Ohgaki (one of the pgsql module maintainers)
and he seems to be happy.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Index: config.m4
===
RCS file: /repository/php-src/ext/pgsql/config.m4,v
retrieving revision 1.46.2.1.2.5
diff -c -r1.46.2.1.2.5 config.m4
*** config.m4 11 Jul 2007 21:51:55 - 1.46.2.1.2.5
--- config.m4 17 Apr 2008 14:41:04 -
***
*** 92,97
--- 92,99
AC_CHECK_LIB(pq, PQescapeStringConn,
AC_DEFINE(HAVE_PQESCAPE_CONN,1,[PostgreSQL 8.1.4 or later]))
AC_CHECK_LIB(pq, PQescapeByteaConn,
AC_DEFINE(HAVE_PQESCAPE_BYTEA_CONN,1,[PostgreSQL 8.1.4 or later]))
AC_CHECK_LIB(pq,
pg_encoding_to_char,AC_DEFINE(HAVE_PGSQL_WITH_MULTIBYTE_SUPPORT,1,[Whether
libpq is compiled with --enable-multibyte]))
+ AC_CHECK_LIB(pq, lo_create, AC_DEFINE(HAVE_LO_CREATE,1,[PostgreSQL 8.1 or
later]))
+ AC_CHECK_LIB(pq, lo_import_with_oid,
AC_DEFINE(HAVE_LO_IMPORT_WITH_OID,1,[PostgreSQL 8.4 or later]))
LIBS=$old_LIBS
LDFLAGS=$old_LDFLAGS
Index: pgsql.c
===
RCS file: /repository/php-src/ext/pgsql/pgsql.c,v
retrieving revision 1.331.2.13.2.27
diff -c -r1.331.2.13.2.27 pgsql.c
*** pgsql.c 31 Dec 2007 07:20:10 - 1.331.2.13.2.27
--- pgsql.c 17 Apr 2008 14:41:06 -
***
*** 188,193
--- 188,196
PHP_FE(pg_lo_write, NULL)
PHP_FE(pg_lo_read_all, NULL)
PHP_FE(pg_lo_import,NULL)
+ #if HAVE_LO_IMPORT_WITH_OID
+ PHP_FE(pg_lo_import_with_oid, NULL)
+ #endif
PHP_FE(pg_lo_export,NULL)
PHP_FE(pg_lo_seek, NULL)
PHP_FE(pg_lo_tell, NULL)
***
*** 2514,2561
}
/* }}} */
! /* {{{ proto int pg_lo_create([resource connection])
Create a large object */
PHP_FUNCTION(pg_lo_create)
{
! zval **pgsql_link = NULL;
PGconn *pgsql;
! Oid pgsql_oid;
int id = -1;
! switch(ZEND_NUM_ARGS()) {
! case 0:
! id = PGG(default_link);
! CHECK_DEFAULT_LINK(id);
! break;
! case 1:
! if (zend_get_parameters_ex(1, pgsql_link)==FAILURE) {
! RETURN_FALSE;
! }
! break;
! default:
WRONG_PARAM_COUNT;
! break;
}
if (pgsql_link == NULL id == -1) {
RETURN_FALSE;
}
! ZEND_FETCH_RESOURCE2(pgsql, PGconn *, pgsql_link, id, PostgreSQL
link, le_link, le_plink);
!
! /* NOTE: Archive modes not supported until I get some more data. Don't
think anybody's
! using it anyway. I believe it's also somehow related to the 'time
travel' feature of
! PostgreSQL, that's on the list of features to be removed... Create
modes not supported.
! What's the use of an object that can be only written to, but not
read from, and vice
! versa? Beats me... And the access type (r/w) must be specified again
when opening
! the object, probably (?) overrides this. (Jouni)
! */
! if ((pgsql_oid = lo_creat(pgsql, INV_READ|INV_WRITE)) == InvalidOid) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Unable to create
PostgreSQL large object);
RETURN_FALSE;
}
!
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi Felipe, Thanks for making the change. This is much more consistent. It remains that there is no 'scalar' or 'numeric' hint. Are you planning on including them? I also wonder about allowing NULL for an 'array' type hint. Is this acceptable? The patch seems to indicate it is. If so, why is this allowed? Thanks, Paul On Thu, Apr 17, 2008 at 4:42 PM, Felipe Pena [EMAIL PROTECTED] wrote: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Em Qui, 2008-04-17 às 17:17 +0200, Paul Biggar escreveu: Hi Felipe, Thanks for making the change. This is much more consistent. It remains that there is no 'scalar' or 'numeric' hint. Are you planning on including them? No, i'm not planning to do that. I also wonder about allowing NULL for an 'array' type hint. Is this acceptable? The patch seems to indicate it is. If so, why is this allowed? I added yesterday an information about that in the doc: Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). However, if NULL is used as the default parameter value, it will be allowed as an argument for any later call. Thanks, Paul On Thu, Apr 17, 2008 at 4:42 PM, Felipe Pena [EMAIL PROTECTED] wrote: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 5:24 PM, Felipe Pena [EMAIL PROTECTED] wrote: Thanks for making the change. This is much more consistent. It remains that there is no 'scalar' or 'numeric' hint. Are you planning on including them? No, i'm not planning to do that. Ah, I should have been more specific. I meant to ask for those changes. Can I ask why not? I also wonder about allowing NULL for an 'array' type hint. Is this acceptable? The patch seems to indicate it is. If so, why is this allowed? I added yesterday an information about that in the doc: Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). However, if NULL is used as the default parameter value, it will be allowed as an argument for any later call. That doesnt explain why its allowed. Can you elaborate? Thanks, Paul On Thu, Apr 17, 2008 at 4:42 PM, Felipe Pena [EMAIL PROTECTED] wrote: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Felipe Pena. -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Strict type hints (parameter and return value)
Felipe Pena wrote:
Well, thinking better about the behavior of type hinting, i decided to
change the proposal for strict type. I.e. don't accept numeric string
as an intenger, etc.
While it is now consistent with is_int() it means we end up with strict
but also stupid interfaces and hence lots of silly type conversions in
application code using such a function.
This is especially annoying as you normally have very few
implementations of a function but lots of code calling it.
You basically 'progressed' from
function foo($x) { $x = (int)$x; ... } # One place where type is
ensured or converted
foo(42);
foo(CONSTANT_42);
foo($x);
foo($db-x);
to
function foo(int $x) { ... }
foo(42);
foo((int)CONSTANT_42); # If you are not 100% about type
foo((int)$x); # If you are not 100% about type
foo((int)$db-x); # DBs normally return strings
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Strict type hints (parameter and return value)
I like this patch, it adds a feature which a lot of companies and code base
would surely implement without breaking anything. The only thing I do not
like has already been mentioned, numeric and scalar are not included.
The one thing I don't dislike, but am unsure of the ease to understand by
users is the return type hinting syntax, using type casting. Maybe I am
wrong but do you think users might get confused by it since it already has
an existing purpose of transforming values to other types, maybe they will
think at glance it transforms the return type to something else? Of course
it would be fault of there own for not reading, but is it NATURAL to use the
existing type hints for it?
Why not:
function int foo($foo) { }
I understand the problem with adding the INT as a keyword, and how that
maybe:
function int int($foo) { }
is awkward, but would be rare and seems to be more correct. I know it would
be more difficult to implement the latter but it should not be impossible
should it?
Just throwing it out there, it is a nice patch and a nice feature for A LOT
of people even though it is not exactly the php way, but all things must
evolve.
-Chris
Re: [PHP-DEV] Re: [RFC] Strict type hints (parameter and return value)
Hi Christian,
On Thu, Apr 17, 2008 at 5:41 PM, Christian Schneider
[EMAIL PROTECTED] wrote:
Felipe Pena wrote:
Well, thinking better about the behavior of type hinting, i decided to
change the proposal for strict type. I.e. don't accept numeric string
as an intenger, etc.
While it is now consistent with is_int() it means we end up with strict
but also stupid interfaces and hence lots of silly type conversions in
application code using such a function.
This is especially annoying as you normally have very few
implementations of a function but lots of code calling it.
You basically 'progressed' from
function foo($x) { $x = (int)$x; ... } # One place where type is
ensured or converted
foo(42);
foo(CONSTANT_42);
foo($x);
foo($db-x);
to
function foo(int $x) { ... }
foo(42);
foo((int)CONSTANT_42); # If you are not 100% about type
foo((int)$x); # If you are not 100% about type
foo((int)$db-x); # DBs normally return strings
You slowly understand the idea behind strict type hinting, you should
add these examples to the wiki ;-)
More seriously, it should be about time to stop to argue about why you
consider it useless, not the PHP way, too many to write, usw... But
to consider the proposal and the patch on their own and if the feature
will be added, is it the way we like to have it or how can it be
improved (keeping the goal in mind).
Whether PHP will have it or not is not yet decided, as far as I can
say. But I really like to have it (I don't feel like explaining again
why I like it is worth the bandwidth :)
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] [RFC] Strict type hints (parameter and return value)
In this case, I'd suggest using my patch for parameter type hinting. It utilizes the current type hinting system for minimal code changes, whereas this is a whole new set of functionality. It also has scalar and number types, and supports objects with __tostring methods. On Thu, 2008-04-17 at 11:42 -0300, Felipe Pena wrote: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 2008-04-17 at 17:29 +0200, Paul Biggar wrote: On Thu, Apr 17, 2008 at 5:24 PM, Felipe Pena [EMAIL PROTECTED] wrote: Thanks for making the change. This is much more consistent. It remains that there is no 'scalar' or 'numeric' hint. Are you planning on including them? No, i'm not planning to do that. Ah, I should have been more specific. I meant to ask for those changes. Can I ask why not? I think scalar is very important. For any function where you are interacting with the database values or echoing output, scalar is very useful. I also wonder about allowing NULL for an 'array' type hint. Is this acceptable? The patch seems to indicate it is. If so, why is this allowed? I added yesterday an information about that in the doc: Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). However, if NULL is used as the default parameter value, it will be allowed as an argument for any later call. That doesnt explain why its allowed. Can you elaborate? The way i do it is to only allow null if null is the default. This way, people cannot skip parameters using null unless specifically allowed to in the function declaration. Thanks, Paul On Thu, Apr 17, 2008 at 4:42 PM, Felipe Pena [EMAIL PROTECTED] wrote: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Felipe Pena. -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 9:01 AM, Sam Barrow [EMAIL PROTECTED] wrote: I like this alot better too, the only downside is compatibility problems. Can you explain, I understand; in partial the problem but I am curious what can not be solved through added logic?
Re: [PHP-DEV] Re: [RFC] Strict type hints (parameter and return value)
On Thu, 2008-04-17 at 09:18 -0700, Chris Stockton wrote:
On Thu, Apr 17, 2008 at 9:01 AM, Sam Barrow [EMAIL PROTECTED] wrote:
I like this alot better too, the only downside is compatibility
problems.
Can you explain, I understand; in partial the problem but I am curious what
can not be solved through added logic?
function int() {
}
PHP won't know if this is a return type hint or function name. This
specific case might be solvable with added logic though, I really don't
know how to do it or how hard it would be; alot of this is done in the
parser which I am only slightly familiar with.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Just for the record, I see absolutely no sense in strict type hints. While there might be some use cases when you want to save typing by having function convert the arguments instead of you doing it manually - there's absolutely no sense to check types strictly in PHP, especially taking into attention that no API ever worked that way, and that it would force users to surround each call to such function with checks for argument types, since PHP can not have static type control. Using such feature would be a nightmare. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Strict type hints (parameter and return value)
On Thu, 2008-04-17 at 08:54 -0700, Chris Stockton wrote:
I like this patch, it adds a feature which a lot of companies and code base
would surely implement without breaking anything. The only thing I do not
like has already been mentioned, numeric and scalar are not included.
The one thing I don't dislike, but am unsure of the ease to understand by
users is the return type hinting syntax, using type casting. Maybe I am
wrong but do you think users might get confused by it since it already has
an existing purpose of transforming values to other types, maybe they will
think at glance it transforms the return type to something else? Of course
it would be fault of there own for not reading, but is it NATURAL to use the
existing type hints for it?
Why not:
function int foo($foo) { }
I understand the problem with adding the INT as a keyword, and how that
maybe:
function int int($foo) { }
I like this alot better too, the only downside is compatibility
problems.
is awkward, but would be rare and seems to be more correct. I know it would
be more difficult to implement the latter but it should not be impossible
should it?
Just throwing it out there, it is a nice patch and a nice feature for A LOT
of people even though it is not exactly the php way, but all things must
evolve.
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 9:33 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Just for the record, I see absolutely no sense in strict type hints. While
there might be some use cases when you want to save typing by having
function convert the arguments instead of you doing it manually - there's
absolutely no sense to check types strictly in PHP, especially taking into
attention that no API ever worked that way, and that it would force users to
surround each call to such function with checks for argument types, since
PHP can not have static type control. Using such feature would be a
nightmare.
You have a good point, but I think it might have slightly more benefit then
we may think. Less code bloat for the checks many of us already enforce is
one.
Doing some greps in the Zend Framework is a good example.
grep -riE -A2
is_(binary|bool|double|float|int|long|null|numeric|object|real|resource|scalar|string|unicode)
*
I get tons of parameter checks which throw exceptions, so users already have
to check there code prior to sending it up the chain. And by Check a good
framework, like Zend, will do the boundary checking for you, so as long as
it is the right type you are ok.
So:
function foo($var) { if(!is_int($var)) { throw new exception('not int'); }}
Turns to:
function foo(int $bar) { }
which is called like this in both cases, maybe with a try catch etc etc:
foo((int) $baz['bar']);
-Chris
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi!
So:
function foo($var) { if(!is_int($var)) { throw new exception('not int'); }}
What's the use of such code? If $var is '1' and not 1, what's the use of
throwing an exception and having to handle it later (basically by
failing the task, since you don't know how to do foo() now) - instead of
just doing with that 1 what was intended for? There's no any difference
between 1 and '1' that can be important to anybody. Only difference is
the way it is represented in underlying bits in zvals, about which
nobody should ever care. That's like making function that would accept
only arguments that has 3'rd bit of pointer set to 1 and 5th bit set to
0, and reject all others. No sane application should ever behave this
way. Writing such function is just plain wrong, it replaces the
substance of programming with nitpicking over the details that are not
important. Whole phenomenon of dynamic languages has grown on the
principle of liberating people from caring for bits and concentrate on
substance, and now you try to drag the bits back in.
which is called like this in both cases, maybe with a try catch etc etc:
foo((int) $baz['bar']);
So every time you call foo you need try/catch? And that's supposed to be
_good_?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 mail() issue and potential fix - needs better brains than me to verify solution.
Hi Richard,
The patch would fix it in this case but there is an underlying change
that needs sorted.
zend_ini_string()'s behaviour was changed to fix
http://bugs.php.net/bug.php?id=42657 so that if the default value was
NULL it would then return an empty string instead.
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.18.2.6r2=1.39.2.2.2.18.2.7
This broke the places that were relying on INI_STR returning the NULL?
Should this fix be backed out and change ini_get and ini_set to deal
with this for the userland?
Scott
Richard Quadling wrote:
Hi.
I have finally managed to get php to compile for windows (yippee for me).
So I can now try and get mail() working again.
The issue is that in ext/standard/mail.c (/* $Id: mail.c,v
1.87.2.1.2.7.2.3 2007/12/31 07:17:15 sebastian Exp $ */), line 197,
the test of ...
if (!sendmail_path)
always evaluates to false when there is no sendmail_path which would
be the case on windows.
The next line differentiates between processing for windows/netware
and everything else.
If the test is
if(0 == strlen(sendmail_path))
then that would work.
The INI_STR call in Line 194 always returns a string if the directive
is known (doesn't need to be set, just has to exist as a directive).
So, I've attached a patch which I have compiled and tested on Windows.
This is in relation to bug http://bugs.php.net/bug.php?id=43348
Index: mail.c
===
RCS file: /repository/php-src/ext/standard/mail.c,v
retrieving revision 1.87.2.1.2.7.2.3
diff -u -u -r1.87.2.1.2.7.2.3 mail.c
--- mail.c 31 Dec 2007 07:17:15 - 1.87.2.1.2.7.2.3
+++ mail.c 17 Apr 2008 14:40:33 -
@@ -194,7 +194,7 @@
char *sendmail_path = INI_STR(sendmail_path);
char *sendmail_cmd = NULL;
- if (!sendmail_path) {
+ if (0 == strlen(sendmail_path)) {
#if (defined PHP_WIN32 || defined NETWARE)
/* handle old style win smtp sending */
if (TSendMail(INI_STR(SMTP), tsm_err, tsm_errmsg, headers,
subject, to, message, NULL, NULL, NULL TSRMLS_CC) == FAILURE) {
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Hi! Your current implementation seems to be inconsistent with both itself and the rest of PHP. I hope this can be rectified before it is included. PHP is inconsisent enough without adding more. If you talk about consistency, you should remember that right now no function and no feature in PHP relies on strict checking of primitive types. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Hi! The problem with this is that there's not much point in converting the value. PHP will do that anyway, making this kind of pointless. There would be a point since PHP might convert to different type that you intended. Think of $foo = My age is $age. If $age is supposed to be int, then converting int hint might help. Overall, I think type hinting should work by checking the type. If it does not match, raise an error. For example, int means int, not numeric string. What code scenario would make it necessary to distinguish between number stored as string and number stored as binary? This only serves to include an additional type juggling system into php, which is very confusing. There's already type juggling in PHP, and if you find it confusing, you find whole PHP and whole set of dynamic languages very confusing. I guess maybe C or Java would work better then :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 9:57 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
What's the use of such code? If $var is '1' and not 1, what's the use of
throwing an exception and having to handle it later (basically by failing
the task, since you don't know how to do foo() now) - instead of just doing
with that 1 what was intended for? There's no any difference between 1 and
'1' that can be important to anybody. Only difference is the way it is
represented in underlying bits in zvals, about which nobody should ever
care. That's like making function that would accept only arguments that has
3'rd bit of pointer set to 1 and 5th bit set to 0, and reject all others. No
sane application should ever behave this way. Writing such function is just
plain wrong, it replaces the substance of programming with nitpicking over
the details that are not important. Whole phenomenon of dynamic languages
has grown on the principle of liberating people from caring for bits and
concentrate on substance, and now you try to drag the bits back in.
So every time you call foo you need try/catch? And that's supposed to be
_good_?
Somebody missed the point...
Seeing how you work for zend I thought maybe you have used the zend
framework = ) Sorry in my example I used int instead of numeric, but my
point is the same, grep in zend framework for is_bool.
It does what you are complaining about:
From: Zend_Pdf_Element_Numeric
public function __construct($val)
{
if ( !is_numeric($val) ) {
throw new Zend_Pdf_Exception('Argument must be numeric');
}
$this-value = $val;
}
That could be...
public function __construct(numeric $val)
{
$this-value = $val;
}
So, let's re-visit my point of less code bloat
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Hi Stanislav, On Thu, Apr 17, 2008 at 7:02 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! Your current implementation seems to be inconsistent with both itself and the rest of PHP. I hope this can be rectified before it is included. PHP is inconsisent enough without adding more. If you talk about consistency, you should remember that right now no function and no feature in PHP relies on strict checking of primitive types. Please try to minimize redundant response (at least within 15 mins). I think we all got that you are against type hints in PHP, that's plain wrong to do it, etc, etc. Thanks for your understanding (reply to my ICU questions instead :-D, 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] [RFC] Type hints (parameter and return value)
Hi! Please try to minimize redundant response (at least within 15 mins). I think we all got that you are against type hints in PHP, that's plain Against strict type hints, yes. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 2008-04-17 at 10:06 -0700, Chris Stockton wrote:
On Thu, Apr 17, 2008 at 9:57 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
What's the use of such code? If $var is '1' and not 1, what's the use of
throwing an exception and having to handle it later (basically by failing
the task, since you don't know how to do foo() now) - instead of just doing
with that 1 what was intended for? There's no any difference between 1 and
'1' that can be important to anybody. Only difference is the way it is
represented in underlying bits in zvals, about which nobody should ever
care. That's like making function that would accept only arguments that has
3'rd bit of pointer set to 1 and 5th bit set to 0, and reject all others. No
sane application should ever behave this way. Writing such function is just
plain wrong, it replaces the substance of programming with nitpicking over
the details that are not important. Whole phenomenon of dynamic languages
has grown on the principle of liberating people from caring for bits and
concentrate on substance, and now you try to drag the bits back in.
So every time you call foo you need try/catch? And that's supposed to be
_good_?
Somebody missed the point...
Seeing how you work for zend I thought maybe you have used the zend
framework = ) Sorry in my example I used int instead of numeric, but my
point is the same, grep in zend framework for is_bool.
It does what you are complaining about:
From: Zend_Pdf_Element_Numeric
public function __construct($val)
{
if ( !is_numeric($val) ) {
throw new Zend_Pdf_Exception('Argument must be numeric');
}
$this-value = $val;
}
That could be...
public function __construct(numeric $val)
{
$this-value = $val;
}
So, let's re-visit my point of less code bloat
Actually, is_numeric checks for strings that contain numeric values,
it's not the same as is_bool, is_int, is_float, etc, which check the
variable's type.
Your point is very valid for is_int and similar functions, just not
is_numeric(). I just did a grep on zend framework for is_int and there
were tons of results.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
On Thu, 2008-04-17 at 10:06 -0700, Stanislav Malyshev wrote: Hi! The problem with this is that there's not much point in converting the value. PHP will do that anyway, making this kind of pointless. There would be a point since PHP might convert to different type that you intended. Think of $foo = My age is $age. If $age is supposed to be int, then converting int hint might help. Overall, I think type hinting should work by checking the type. If it does not match, raise an error. For example, int means int, not numeric string. What code scenario would make it necessary to distinguish between number stored as string and number stored as binary? This only serves to include an additional type juggling system into php, which is very confusing. There's already type juggling in PHP, and if you find it confusing, you find whole PHP and whole set of dynamic languages very confusing. I guess maybe C or Java would work better then :) I understand it very well, but why have a whole other system of type juggling? That would be duplicating type juggling functionality that's already in there. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 mail() issue and potential fix - needs better brains than me to verify solution.
On Thu, 2008-04-17 at 17:59 +0100, Scott MacVicar wrote: Hi Richard, The patch would fix it in this case but there is an underlying change that needs sorted. zend_ini_string()'s behaviour was changed to fix http://bugs.php.net/bug.php?id=42657 so that if the default value was NULL it would then return an empty string instead. http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.18.2.6r2=1.39.2.2.2.18.2.7 This broke the places that were relying on INI_STR returning the NULL? Propably, but INI_STR is evil and should never be used anyway. Should this fix be backed out and change ini_get and ini_set to deal with this for the userland? Hell no. Fix places using INI_STR incorrectly instead. (as in: make them NOT use INI_STR.. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 10:11 AM, Sam Barrow [EMAIL PROTECTED] wrote: Actually, is_numeric checks for strings that contain numeric values, it's not the same as is_bool, is_int, is_float, etc, which check the variable's type. Hence my second example = ) Your point is very valid for is_int and similar functions, just not is_numeric(). I just did a grep on zend framework for is_int and there were tons of results. I think it is valid for anything, numeric type hinting is very appropriate in php.
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 2008-04-17 at 10:23 -0700, Chris Stockton wrote: On Thu, Apr 17, 2008 at 10:11 AM, Sam Barrow [EMAIL PROTECTED] wrote: Actually, is_numeric checks for strings that contain numeric values, it's not the same as is_bool, is_int, is_float, etc, which check the variable's type. Hence my second example = ) Your point is very valid for is_int and similar functions, just not is_numeric(). I just did a grep on zend framework for is_int and there were tons of results. I think it is valid for anything, numeric type hinting is very appropriate in php. Numeric type hinting is valid, all I'm saying is that PHP's is_numeric function doesn't perform a strict type check like is_int or is_bool. I agree with you I just think you misunderstood the purpose of the is_numeric function. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Strict type hints (parameter and return value)
Em Qui, 2008-04-17 às 12:31 -0400, Sam Barrow escreveu:
On Thu, 2008-04-17 at 09:18 -0700, Chris Stockton wrote:
On Thu, Apr 17, 2008 at 9:01 AM, Sam Barrow [EMAIL PROTECTED] wrote:
I like this alot better too, the only downside is compatibility
problems.
Can you explain, I understand; in partial the problem but I am curious what
can not be solved through added logic?
function int() {
}
PHP won't know if this is a return type hint or function name. This
specific case might be solvable with added logic though, I really don't
know how to do it or how hard it would be; alot of this is done in the
parser which I am only slightly familiar with.
I'm not a bison expert, but i don't know how make the parser accepts
'function type name()', actually i get two Shift/reduce and two
Reduce/reduce conflicts because the T_STRING as a possible type name.
... Maybe it is an known issue.
--
Regards,
Felipe Pena.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
On Thu, 17 Apr 2008, Felipe Pena wrote:
Now with both parameter and return value type hints.
For parameter type hints, i have completed the actual implementation
with the leftover php types:
- string (binary string and unicode)
- integer (accepting numeric string too)
- double (accepting numeric string too)
- boolean ('0', '1', true, false)
I think that the typehints should be strict, if you don't want
strictness, don't use type hints.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 17 Apr 2008, Felipe Pena wrote: Em Qui, 2008-04-17 às 17:17 +0200, Paul Biggar escreveu: Hi Felipe, Thanks for making the change. This is much more consistent. It remains that there is no 'scalar' or 'numeric' hint. Are you planning on including them? No, i'm not planning to do that. I don't think scalar is very useful, but I do think there is a case for numeric. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
I understand it very well, but why have a whole other system of type It's the same system. The same system that makes internal functions work. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Derick Rethans wrote: I don't think scalar is very useful, but I do think there is a case for numeric. I don't think string is useful. I would use scalar instead. I only need to know that the variable is not an array or object. I can echo, concatenate, etc. any scalar as if it was a string. -- Brian Moon Senior Developer/Engineer -- When you care enough to spend the very least. http://dealnews.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
I just did a grep on zend framework for is_int and there were tons of results. No offense to Zend, I love thos guys, but I don't think using Zend Framework as the gold standard for how people want to code in PHP is the right thing to do. -- Brian Moon Senior Developer/Engineer -- When you care enough to spend the very least. http://dealnews.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
On Thu, Apr 17, 2008 at 7:02 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Your current implementation seems to be inconsistent with both itself and the rest of PHP. I hope this can be rectified before it is included. PHP is inconsisent enough without adding more. If you talk about consistency, you should remember that right now no function and no feature in PHP relies on strict checking of primitive types. That is not the case (or I am very much mistaken). In particular, is_int, which I mentioned in my email, is predicated on the IS_LONG type only. Paul -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! Seeing how you work for zend I thought maybe you have used the zend framework = ) Sorry in my example I used int instead of numeric, but my point is the same, grep in zend framework for is_bool. It might come as a surprise to you, but I did not write whole Zend Framework personally :) Moreover, as even more surprise I did not even inspect personally each line of code. As a final shock, I am not convinced functions in PHP should throw exceptions when parameters don't match - and even if they do, first they should attempt to make sense of parameters (which makes string hints like integer and string make no sense - you can convert a lot of things to int or string). Even if they can't, it's much better to be handled on user code level with error message that makes sense and way that makes sense for application - but I could kind of live with the scenario where these hints would work as internal function types work now. However, that's not what is proposed - what is proposed is that if you've got int typehint, '1' would be rejected. Having such restriction makes no sense and goes contrary to what PHP and dynamic languages in general are. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi Stanislav, On Thu, Apr 17, 2008 at 7:59 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: As a final shock, I am not convinced functions in PHP should throw exceptions when parameters don't match - and even if they do, first they should attempt to make sense of parameters (which makes string hints like integer and string make no sense - you can convert a lot of things to int or string). This is of course why I suggested that the best approach would be automatically convert them, rather than reject a type which can be coerced appropriately. I would settle for the current proposal, but if you're going to make the language weakly-typed, which it is, it is more appropriate to keep this in line with the rest of the language. Paul -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 10:59 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! Seeing how you work for zend I thought maybe you have used the zend framework = ) Sorry in my example I used int instead of numeric, but my point is the same, grep in zend framework for is_bool. It might come as a surprise to you, but I did not write whole Zend Framework personally :) Moreover, as even more surprise I did not even inspect personally each line of code. As a final shock, I am not convinced functions in PHP should throw exceptions when parameters don't match - and even if they do, first they should attempt to make sense of parameters (which makes string hints like integer and string make no sense - you can convert a lot of things to int or string). Even if they can't, it's much better to be handled on user code level with error message that makes sense and way that makes sense for application - but I could kind of live with the scenario where these hints would work as internal function types work now. However, that's not what is proposed - what is proposed is that if you've got int typehint, '1' would be rejected. Having such restriction makes no sense and goes contrary to what PHP and dynamic languages in general are. That first part made me laugh, hehe. I wanted to just point out that your company was a good example of how code could be minimized using type checks. I understand your philosophy with dynamic types in php, but there are times that these dynamic types have really shot people in the foot and added exploits and bad coding practices, which is why high-quality frameworks push users to use correct types, zf is just one of many examples my friend. I get your point of 12 and '12', which is why I proposed earlier numeric hinting would be very appropriate. -Chris
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
I like and will use it a lot... sometimes you simple cannot trust on php
dynamic type convertion, please see the following example
?php
function check_user($user_id) {
if ($user_id == 0) {
// root user
} else if ($user_id 0 $user_id 1000) {
// special admin users
} else {
// standard users
}
}
?
Now if someone thinks $user_id is the user login name and call
check_user('login_name');
'login_name' will be converted to 0 (zero) as per php automatic string
to numeric convertion and this user will be handled as being the root
user. In this case strict comparison === is not apropriate, and I'm
forced to verify the parameter against is_numeric.
I much simpler approach would be...
?php
function check_user(int $user_id) {...}
Also I think this is a basic prerequisite to allowing function overload
on php OO side in the future ;)
Thanks,
Jaris.
Stanislav Malyshev wrote:
Hi!
So:
function foo($var) { if(!is_int($var)) { throw new exception('not
int'); }}
What's the use of such code? If $var is '1' and not 1, what's the use
of throwing an exception and having to handle it later (basically by
failing the task, since you don't know how to do foo() now) - instead
of just doing with that 1 what was intended for? There's no any
difference between 1 and '1' that can be important to anybody. Only
difference is the way it is represented in underlying bits in zvals,
about which nobody should ever care. That's like making function that
would accept only arguments that has 3'rd bit of pointer set to 1 and
5th bit set to 0, and reject all others. No sane application should
ever behave this way. Writing such function is just plain wrong, it
replaces the substance of programming with nitpicking over the details
that are not important. Whole phenomenon of dynamic languages has
grown on the principle of liberating people from caring for bits and
concentrate on substance, and now you try to drag the bits back in.
which is called like this in both cases, maybe with a try catch etc etc:
foo((int) $baz['bar']);
So every time you call foo you need try/catch? And that's supposed to
be _good_?
--
*Jarismar Chaves da Silva, M.Sc.*
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend.c zend_execute_API.c zend_vm_def.h zend_vm_execute.h php-src NEWS
On Thu, 17 Apr 2008, Dmitry Stogov wrote: Another idea: In case xdebug overwrites zend_execute() it can set EG(return_value_ptr_ptr) to point to some local variable then call original executor and then print pass return_value to caller or destroy it dependent on previous value of EG(return_value_ptr_ptr). See, I was looking for just such a trick. I'll give it a try later. Thanks Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Hi! If you talk about consistency, you should remember that right now no function and no feature in PHP relies on strict checking of primitive types. That is not the case (or I am very much mistaken). In particular, is_int, which I mentioned in my email, is predicated on the IS_LONG type only. Read that no function except for a tiny handful of very special cases like is_* and serializes and probably one or two other functions that I forgot, ok? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Hi, On Thu, Apr 17, 2008 at 8:22 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: If you talk about consistency, you should remember that right now no function and no feature in PHP relies on strict checking of primitive types. That is not the case (or I am very much mistaken). In particular, is_int, which I mentioned in my email, is predicated on the IS_LONG type only. Read that no function except for a tiny handful of very special cases like is_* and serializes and probably one or two other functions that I forgot, ok? is_* are the important functions, since they are the ones which most resemble the type hints under discussion. Up until now, anyone implementing this in user-land would use is_int(). It makes perfect sense that type hints should mimic this behaviour. Not doing so would be very inconsistent, and so confusing. Paul -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Hi! is_* are the important functions, since they are the ones which most resemble the type hints under discussion. Up until now, anyone Circular argument here. implementing this in user-land would use is_int(). It makes perfect No, you shouldn't do that - there's absolutely no reason to accept 1 and reject '1', unless you have some very rare and special circumstance. If you are using is_int for that, your code is wrong. sense that type hints should mimic this behaviour. Not doing so would be very inconsistent, and so confusing. Could we stop using word consistent to replace I like it? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! Scalar is useful if you DON'T want an array or object - but don't care if you get an int/string/whatnot When you can use string but not object with __toString? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Derick Rethans wrote:
On Thu, 17 Apr 2008, Felipe Pena wrote:
Now with both parameter and return value type hints.
For parameter type hints, i have completed the actual implementation
with the leftover php types:
- string (binary string and unicode)
- integer (accepting numeric string too)
- double (accepting numeric string too)
- boolean ('0', '1', true, false)
I think that the typehints should be strict, if you don't want
strictness, don't use type hints.
+1
- Mark
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
I think that the typehints should be strict, if you don't want strictness, don't use type hints. Note that right now we already have non-strict typehints in most of the internal functions, so you *are* using them if you use PHP. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 2008-04-17 at 11:43 -0700, Stanislav Malyshev wrote: Hi! Scalar is useful if you DON'T want an array or object - but don't care if you get an int/string/whatnot When you can use string but not object with __toString? my patch does that -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
On Thu, Apr 17, 2008 at 8:41 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Circular argument here. No comment. 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] [RFC] Strict type hints (parameter and return value)
Hi! When you can use string but not object with __toString? my patch does that Ok, that's great. So then it makes sense to allow converting int-string too, right? And then it'd also make sense to allow string-int too? Especially if we have object-int convertor and that can be allowed too. In fact, we have good old conversion system used in parse_parameters. So why not use the same rules? That'd make at least some sense - give PHP programmers the tools that extension C programmers have. I still wouldn't like it too much but at least it would make sense :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
On Thu, Apr 17, 2008 at 8:41 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
is_* are the important functions, since they are the ones which most
resemble the type hints under discussion. Up until now, anyone
Circular argument here.
Yes, I phrased that badly. I believe it is fair to say that there
would be confusion over why is_int may fail after an 'int' type hint.
More generally, I think it is difficult to explain why an int type
hint does not guarantee an int.
implementing this in user-land would use is_int(). It makes perfect
No, you shouldn't do that - there's absolutely no reason to accept 1 and
reject '1', unless you have some very rare and special circumstance. If you
are using is_int for that, your code is wrong.
That is very subjective. I doubt there is 'one true style' of PHP,
despite suggestions I see about 'the PHP way'. But let us suppose you
would use an int cast instead to ensure you have an int (by type, not
coerced value). The behaviour I recommend is also consistent with
casting. It would be syntactic sugar for
function ($x) { $x = (int) ($x); ... }
sense that type hints should mimic this behaviour. Not doing so would
be very inconsistent, and so confusing.
Could we stop using word consistent to replace I like it?
I am very deliberately not using consistent to replace I like it,
except in the sense that I like consistency. It makes no sense to find
that you do not have an int, when you specify you must. I very much
mean consistency, and do not have a preference for the approach,
except that only one seems perfectly consistent in this case, which is
why I have recommended it.
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 9:04 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: In fact, we have good old conversion system used in parse_parameters. So why not use the same rules? That'd make at least some sense - give PHP programmers the tools that extension C programmers have. I still wouldn't like it too much but at least it would make sense :) As I read it, these convert the parameter to the expected type, if it is not already, and fail when this is not possible. All thats missing is scalar and numeric to be consistent with the is_*(), and its perfect. Paul -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi Felipe, first of all, thanks for your proposal. I like it. Am Donnerstag, den 17.04.2008, 11:42 -0300 schrieb Felipe Pena: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. [...] I would also like to see scalar and numeric too, but that's just for the record. For ReflectionParameter I would like to see an additional ReflectionParameter::isType(string $type_name) to allow constructs like foreach (array(string, integer) as $type) if (!$reflection_param-isType($type)) throw new Exception(); What about additions in the ReflectionMethod-class? I would say adding ReflectionMethod::isInt(), ...::isDouble() and isType() would be appropriate. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
+1
Derick Rethans wrote:
On Thu, 17 Apr 2008, Felipe Pena wrote:
Now with both parameter and return value type hints.
For parameter type hints, i have completed the actual implementation
with the leftover php types:
- string (binary string and unicode)
- integer (accepting numeric string too)
- double (accepting numeric string too)
- boolean ('0', '1', true, false)
I think that the typehints should be strict, if you don't want
strictness, don't use type hints.
regards,
Derick
--
*Jarismar Chaves da Silva, M.Sc.*
*ADP**Labs** Brazil *
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
http://www.adp.com
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Em Qui, 2008-04-17 às 23:14 +0200, Lars Strojny escreveu: Hi Felipe, first of all, thanks for your proposal. I like it. Am Donnerstag, den 17.04.2008, 11:42 -0300 schrieb Felipe Pena: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. [...] I would also like to see scalar and numeric too, but that's just for the record. For ReflectionParameter I would like to see an additional ReflectionParameter::isType(string $type_name) to allow constructs like foreach (array(string, integer) as $type) if (!$reflection_param-isType($type)) throw new Exception(); I also thought that when adding the istype methods! :D What about additions in the ReflectionMethod-class? I would say adding ReflectionMethod::isInt(), ...::isDouble() and isType() would be appropriate. Sure, should there be! Thanks for remember me. But i think that istype as name is confuse in this case. We need a name for that. -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
