Hi,
From a user perspective, I agree that this would probably be the most useful
behaviour of all. Type hint would then mean*:
Hint at what type the variable should have. If possible, convert it to the
target type; if it is not even compatible, throw an error*.
Regards,
Guillaume Rossolini
On Thu, 2008-06-19 at 20:07 +0200, Timm Friebe wrote:
Hi,
I like this generally, but cannot live with the BC issues raised.
Introducing all type names as keywords will make class Object, class
Integer and so on give a syntax error.
That's actually not true, the patch does not
What if by type hint a parameter, php automatically tries to convert the
argument into that type and throws an exception ONLY if it couldn't be done?
for example:
function concat(string $a, string $b)
{
return $a.$b;
}
I can do:
concat(1,'1');
concat(2.5,' pigs');
concat(new
Hi,
I like this generally, but cannot live with the BC issues raised.
Introducing all type names as keywords will make class Object, class
Integer and so on give a syntax error.
That's actually not true, the patch does not introduce new keywords.
Hrm, the Wiki states it does:
[EMAIL PROTECTED]
Cc: internals@lists.php.net
Sent: Monday, June 16, 2008 11:02 PM
Subject: Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi!
Maybe we should stop using the 1 and '1' argument, yes, they can be
Maybe not, while there are people that fail to understand
Fabrice VIGNALS wrote:
In mathematic, equal meen the same value AND the same nature.
The follow fact could be frustrating :
Usually, context is good enough to disambiguate between the cases. The
most prevalent convention in programming languages is = is assignment,
and == is comparison (PHP
Hi!
Maybe we should stop using the 1 and '1' argument, yes, they can be
Maybe not, while there are people that fail to understand it. Here:
But try to remember, 1 !== '1' and PHP is not an end all language, often
we have to communicate to strictly type systems, we need to be positive
So
On 16.06.2008, at 23:02, Stanislav Malyshev wrote:
So you just ignored the special cases part. Yes, if you have special
case where you interface with very brain-dead strictly typed system
that
absolutely can't understand that '1' and 1 is the same - then you
need to _convert_. So how
On Mon, Jun 16, 2008 at 2:02 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
So you just ignored the special cases part. Yes, if you have special
case where you interface with very brain-dead strictly typed system that
absolutely can't understand that '1' and 1 is the same - then you need
Hi!
I get this, really, I do, again. Like the previous post I (likely we)
understand.
Unfortunately, it looks like you do not. Probably my failure to explain
it clearly.
Did you not get or read my post? You say again and again 1 == '1', but
you are forgetting those OTHER operators, ===
Hi,
If anyone wants use type hinting, i believe that it should be strict.
Otherwise, it makes more sense to not use it.
I like this generally, but cannot live with the BC issues raised.
Introducing all type names as keywords will make class Object, class
Integer and so on give a syntax
On Sun, 15 Jun 2008, Timm Friebe wrote:
If anyone wants use type hinting, i believe that it should be strict.
Otherwise, it makes more sense to not use it.
I like this generally, but cannot live with the BC issues raised. Introducing
all type names as keywords will make class Object,
Hello,
On Sun, May 25, 2008 at 1:57 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
I see absolutely no use in strict mode. Moreover, I consider it harmful
as it teaches people not to use dynamic nature of PHP but instead pepper
their code with unnecessary checks and irrelevant errors. As I
On Sun, 2008-06-15 at 11:44 +0200, Timm Friebe wrote:
Hi,
If anyone wants use type hinting, i believe that it should be strict.
Otherwise, it makes more sense to not use it.
I like this generally, but cannot live with the BC issues raised.
Introducing all type names as keywords will
Hello Stanislav,
Thursday, April 17, 2008, 6:57:12 PM, you 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
as this seems to be your only argument throughout the discussion,
Hi!
as this seems to be your only argument throughout the discussion, I
suggest we implement is_numeric() and alike or allow a second parameter
that to 'is_*($vaue, $strict=true)' that allows to switch to non strict
mocde. We then could easily allow 'numeric' as another type hint. Or in
I see
Hi!
I may be missing something but in this context, string doesn't get
very useful (I think), because besides arrays / objects (except
Yes, it's not very useful, I agree. However, if you define useful as
being able to reject arguments that can be converted to strings but
aren't marked as
Hi,
[I'm replying also to Lukas email because of the similarity]
Stanislav Malyshev wrote:
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
Lukas Kahwe Smith wrote:
Suddenly I need to ensure that all my variables have the proper types.
So what will people do? They will start forcing type juggeling manually
before they call the library in question. Since this is the glue code,
its the kind of code you have to write day in day out.
Hi Felipe,
Am Donnerstag, den 17.04.2008, 21:24 -0300 schrieb Felipe Pena:
[...]
But i think that istype 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
Hello All,
I just want to bring in a different perception on the proposed
feature. I think people are very focused on what I call library
code. This is the kind of code that should in theory be worked on
less, than the glue code that you write in every project to finish up
the
2008/4/18, Lukas Kahwe Smith [EMAIL PROTECTED]:
Hello All,
I just want to bring in a different perception on the proposed feature. I
think people are very focused on what I call library code. This is the
kind of code that should in theory be worked on less, than the glue code
that you write
On Fri, Apr 18, 2008 at 9:03 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Suddenly I need to ensure that all my variables have the proper types. So
what will people do?
So maybe an (int) here or there
is not so much more code to type, but you can already see that code you safe
on one
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 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
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,
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, 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) -
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
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, 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
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
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
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 {
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]
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
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 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,
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
49 matches
Mail list logo
