Hi Felipe,
Am Donnerstag, den 17.04.2008, 21:24 -0300 schrieb Felipe Pena:
[...]
> But i think that is as name is confuse in this case.
> We need a name for that.
isOfType(), just is() or isA() (and than also allowing classnames) or
maybe getType(), similiar to the currently existing getClass().
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
+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 t
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,
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 wou
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
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 to
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, 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 So
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]
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)
- d
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]
--
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 ac
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
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
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
Derick Rethans wrote:
> 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
>>> inclu
I like and will use it a lot... sometimes you simple cannot trust on php
dynamic type convertion, please see the following example
0 && $user_id < 1000) {
// special admin users
} else {
// standard users
}
}
?>
Now if someone thinks $user_id is the user login name and call
ch
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.
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
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 :
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 ta
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
-
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
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 Ru
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 no
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 (acce
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
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
>
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_
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
> N
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 inten
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
> >
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 P
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
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 j
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!
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
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/
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
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 - 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 thi
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 argumen
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
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 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
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:4
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.
>
> W
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
user
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 lo
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 bee
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
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
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. Th
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)
alway
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, patc
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
>
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");
>
> T
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_* f
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 /a
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 b
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/
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. S
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
va
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...?
>
>
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)
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
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
> - o
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
For maintaining synchronize code in the team
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Array is already built in, and for mixed, as you already mentioned, indeed
no type hinting. I definitely want this implemented, +1 from me.
On Thu, Apr 17, 2008 at 11:01 AM, Arvids Godjuks <[EMAIL PROTECTED]>
wrote:
> What about types like
> array
> mixed
>
> Ok, for "mixed" we may not use type
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 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.
Th
73 matches
Mail list logo
