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
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.
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),
.)
For maintaining synchronize code in the team
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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
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
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)
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 =)
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
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.
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:
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
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
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.
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,
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)
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.
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
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
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
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
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
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
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
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,
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?
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
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
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
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
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) -
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.
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
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
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, 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
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, 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
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
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
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
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
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
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
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
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
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!
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 :)
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
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
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 {
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
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
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]
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, 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
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
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.
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
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
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,
+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
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
71 matches
Mail list logo
