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
+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)
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
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
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,
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),
.)
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.
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_*
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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)
-
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]
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
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
+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
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
27 matches
Mail list logo
