Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Hello Felipe, please do not allow non optional parameters after optional parameters. Also default value NULL seems pretty odd for a numeric type and it might be an idea to only allow types matching the type hint. But I guess it is in line the current type hints and a good solution to mark those as not passed. You took care of reflection parameter but not of reflection method/function. What I do not like about the return type hint patch is that it adds the native types upfront. This is actually all that is discussable. Return type hints themselves were already agreed on. That said we only need to think whether your syntax is ok. And from that perspective you get my vote, too. So how about a limited patch first that does not introduce native types, only implements return type hints and does also add reflection for it. marcus Friday, April 18, 2008, 1:52:22 PM, you wrote: Em Sex, 2008-04-18 às 10:22 +0300, Arvids Godjuks escreveu: +1 for strict types. That way it will be simple: * Don't need - then don't use at all * You need it - you use it fully. One thing than left to clearfy - do we allow to hint only part of args or do we go the road if hint args, then hint them all! (I'm personaly for second one - be strict) No, just use in the arg that you want. Example: http://felipe.ath.cx/diff/tests/param_tests/param_type_hint_016.phpt -- Regards, Felipe Pena. Best regards, Marcus -- 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)
+1 for strict types. That way it will be simple: * Don't need - then don't use at all * You need it - you use it fully. One thing than left to clearfy - do we allow to hint only part of args or do we go the road if hint args, then hint them all! (I'm personaly for second one - be strict)
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
On 18/04/2008, Arvids Godjuks [EMAIL PROTECTED] wrote: +1 for strict types. That way it will be simple: * Don't need - then don't use at all * You need it - you use it fully. One thing than left to clearfy - do we allow to hint only part of args or do we go the road if hint args, then hint them all! (I'm personaly for second one - be strict) It may be that a parameter CAN be mixed, so a lack of a type hint should be supported even if strict type hinting is used/implemented. Maybe a type hint of mixed? -- - 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] [RFC] Type hints (parameter and return value)
On Fri, 2008-04-18 at 12:33 +0100, Richard Quadling wrote: On 18/04/2008, Arvids Godjuks [EMAIL PROTECTED] wrote: +1 for strict types. That way it will be simple: * Don't need - then don't use at all * You need it - you use it fully. One thing than left to clearfy - do we allow to hint only part of args or do we go the road if hint args, then hint them all! (I'm personaly for second one - be strict) It may be that a parameter CAN be mixed, so a lack of a type hint should be supported even if strict type hinting is used/implemented. Maybe a type hint of mixed? Of course; we don't make type hinting necessary, just type the variable name with no type hint as you would now and no type check is performed. -- - 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] [RFC] Type hints (parameter and return value)
Em Sex, 2008-04-18 às 10:22 +0300, Arvids Godjuks escreveu: +1 for strict types. That way it will be simple: * Don't need - then don't use at all * You need it - you use it fully. One thing than left to clearfy - do we allow to hint only part of args or do we go the road if hint args, then hint them all! (I'm personaly for second one - be strict) No, just use in the arg that you want. Example: http://felipe.ath.cx/diff/tests/param_tests/param_type_hint_016.phpt -- 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)
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
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
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
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] 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] 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] [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] 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] 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] 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] 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] 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] 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] 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
[PHP-DEV] [RFC] Type hints (parameter and return value)
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
