On 17 Jun 2010, at 20:14, Stas Malyshev wrote:
Hi!
I know the discussion is about scalar type hints. But what is with a
object type hint as base for all objects?
When it makes sense to accept any object, regardless of the class, but not
other types? I wonder if it's really a common
On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote:
On 17 Jun 2010, at 20:14, Stas Malyshev wrote:
Hi!
I know the discussion is about scalar type hints. But what is with a
object type hint as base for all objects?
When it makes sense to accept any object, regardless of the
On Fri, 18 Jun 2010 16:28:31 +0200, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote:
On 17 Jun 2010, at 20:14, Stas Malyshev wrote:
Hi!
I know the discussion is about scalar type hints. But what is with a
object type hint as base for
On 18.06.2010, at 18:13, Christian Kaps wrote:
On Fri, 18 Jun 2010 16:28:31 +0200, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote:
On 17 Jun 2010, at 20:14, Stas Malyshev wrote:
Hi!
I know the discussion is about scalar type
On 18 June 2010 15:13, Melanie Rhianna Lewis cybersp...@php.net wrote:
On 17 Jun 2010, at 20:14, Stas Malyshev wrote:
Hi!
I know the discussion is about scalar type hints. But what is with a
object type hint as base for all objects?
When it makes sense to accept any object, regardless of
Hi,
I know the discussion is about scalar type hints. But what is with a
object type hint as base for all objects?
What is the next step to get type hinting in the next PHP release,
regardless of whether strict or weak?
Best regards,
Christian
--
PHP Internals - PHP Runtime Development
Hi!
I know the discussion is about scalar type hints. But what is with a
object type hint as base for all objects?
When it makes sense to accept any object, regardless of the class, but
not other types? I wonder if it's really a common use-case.
--
Stanislav Malyshev, Software Architect
Am 17.06.2010 21:14, schrieb Stas Malyshev:
Hi!
I know the discussion is about scalar type hints. But what is with a
object type hint as base for all objects?
When it makes sense to accept any object, regardless of the class, but
not other types? I wonder if it's really a common use-case.
Zeev Suraski wrote:
That's exactly what I had in mind. Have E_TYPE off by default and
implement it throughout PHP - instead of just type hints.
for example:
$foo = 0;
$foo += (int)'123abc'; // no error
$foo += '123abc'; // E_TYPE
Out of curiosity: What would you do with the E_TYPE on the
At 15:12 10/06/2010, Christian Schneider wrote:
Zeev Suraski wrote:
That's exactly what I had in mind. Have E_TYPE off by default and
implement it throughout PHP - instead of just type hints.
for example:
$foo = 0;
$foo += (int)'123abc'; // no error
$foo += '123abc'; // E_TYPE
Out of
On Thu, Jun 10, 2010 at 2:12 PM, Christian Schneider
cschn...@cschneid.comwrote:
Zeev Suraski wrote:
That's exactly what I had in mind. Have E_TYPE off by default and
implement it throughout PHP - instead of just type hints.
for example:
$foo = 0;
$foo += (int)'123abc'; // no error
Hi all:
On Wed, Jun 9, 2010 at 1:59 AM, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting situation is unique.
On 9 June 2010 00:59, Daniel Convissor dani...@analysisandsolutions.com wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting situation is unique. It is something that
On 09.06.2010, at 12:01, André Rømcke wrote:
Example:
function fetchById( int $id, bool $asObject = true )
If weak type hints are accepted, type hints would be useless in this case as
consumer can do something strange as fetchById( true, 'foo' ) (Obviously I'm
not saying anyone would do
Hi Lukas!
On Wed, Jun 9, 2010 at 12:08 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote:
On 09.06.2010, at 12:01, André Rømcke wrote:
Example:
function fetchById( int $id, bool $asObject = true )
If weak type hints are accepted, type hints would be useless in this case
as
consumer
On Wed, Jun 9, 2010 at 12:08 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote:
On 09.06.2010, at 12:01, André Rømcke wrote:
Example:
function fetchById( int $id, bool $asObject = true )
If weak type hints are accepted, type hints would be useless in this case
as
consumer can do
- trigger_error OR exceptions? (we said, that exceptions shouldn't be
allowed inside the core, so maybe this can be only impelemted through
spl)
I think the exception discussion should be omitted. There exists some
other RFCs to fix this issue.
http://wiki.php.net/rfc/enhanced_error_handling
At 02:59 09/06/2010, Daniel Convissor wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting situation is unique. It is something that
applications will frequently want to
On Wed, Jun 9, 2010 at 4:17 PM, Zeev Suraski z...@zend.com wrote:
At 02:59 09/06/2010, Daniel Convissor wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting
-Original Message-
From: Zeev Suraski [mailto:z...@zend.com]
Sent: 09 June 2010 15:17
To: Daniel Convissor
Cc: PHP Internals List
Subject: Re: [PHP-DEV] Type hinting
At 02:59 09/06/2010, Daniel Convissor wrote:
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas
At 19:55 09/06/2010, Jared Williams wrote:
Is E_TYPE good enough? If it follows the other E_*, I'd suggest it's
not.
Yes, same error mechanism.
Just having a single string error message describing the error, and
having to unmangle the detailed information* from that doesn't seem
that great.
At 17:54 09/06/2010, Ferenc Kovacs wrote:
If we introduce the E_TYPE what will be the new default/suggested error level?
If it won't be enabled by default, then maybe we could introduce
this in the whole language.
I mean, if you implicitly convert '123asd' to integer, you will
trigger this
for example:
$foo = 0;
$foo += (int)'123abc'; // no error
$foo += '123abc'; // E_TYPE
Exactly. And to make sure we're on the same page:
$foo += '123'; // no error
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Zeev:
On Wed, Jun 09, 2010 at 05:17:13PM +0300, Zeev Suraski wrote:
I think having E_TYPE (or whatever), a non-fatal notice that can be
either ignored or handled separately from everything else makes sense. I
think we may actually want to introduce it at the most basic levels of
PHP,
Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting situation is unique. It is something that
applications will frequently want to handle gracefully in order to
provide useful
On 04.06.2010, at 03:18, Daniel Convissor wrote:
On Thu, Jun 03, 2010 at 10:29:30AM -0400, Daniel Convissor wrote:
Hi Folks:
On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote:
IMHO we shouldn't be getting to any kind of fatal error/exception
situation, which is why I like
Hi Folks:
On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote:
IMHO we shouldn't be getting to any kind of fatal error/exception
situation, which is why I like the idea of auto-conversion plus E_STRICT
in the 'weird conversion' scenarios
E_STRICT doesn't cut it. So many
On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote:
It is very frequent that you want number and get 1 instead - almost
all incoming data for PHP are strings.
I'd like to point out that filter_input() does cast user input to the
right PHP type. And if memory serves, ext/filter is
On 03.06.2010, at 18:25, Josh Davis wrote:
On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote:
It is very frequent that you want number and get 1 instead - almost
all incoming data for PHP are strings.
I'd like to point out that filter_input() does cast user input to the
On Thu, Jun 3, 2010 at 6:32 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote:
On 03.06.2010, at 18:25, Josh Davis wrote:
On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote:
It is very frequent that you want number and get 1 instead - almost
all incoming data for PHP are
On 03.06.2010, at 18:57, Ferenc Kovacs wrote:
On Thu, Jun 3, 2010 at 6:32 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 03.06.2010, at 18:25, Josh Davis wrote:
On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote:
It is very frequent that you want number and get
On 3 June 2010 18:25, Josh Davis php...@gmail.com wrote:
seems that mysqlnd experiments in using MySQL's binary protocol for
all queries and not just prepared statements [1] didn't materialize.
I have to correct myself here, the MYSQLI_OPT_INT_AND_FLOAT_NATIVE
option did materialize, so native
On Thu, 03 Jun 2010 17:25:53 +0100, Josh Davis php...@gmail.com wrote:
On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote:
It is very frequent that you want number and get 1 instead - almost
all incoming data for PHP are strings.
I'd like to point out that filter_input() does
On 3 June 2010 22:24, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Thu, 03 Jun 2010 17:25:53 +0100, Josh Davis php...@gmail.com wrote:
The only other big source of data is the database. [...]
Emphasis on big. There's an infinite number of sources (from mashups
using XML or JSON to XML-RPC
Hi!
And remember that I was only discussing it in response to the claim
that almost all incoming data for PHP are strings. My point was that
user input will be correctly typed if you validate it with PHP's
bundled extension, as it is commonly recommended, and it's also
Validation and typing
On 3 June 2010 23:37, Stas Malyshev smalys...@sugarcrm.com wrote:
Validation and typing are entirely different things. Many validation methods
do not require or provide strict typing.
I can't agree more and that's exactly why I want typehints to only
check for type, not validate the content of
On Thu, Jun 03, 2010 at 10:29:30AM -0400, Daniel Convissor wrote:
Hi Folks:
On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote:
IMHO we shouldn't be getting to any kind of fatal error/exception
situation, which is why I like the idea of auto-conversion plus E_STRICT
in the
On Wed, Jun 2, 2010 at 12:49 AM, Chad Fulton chadful...@gmail.com wrote:
Hello!
As I mentioned, I think that we have to inform the caller about the
problem
(be either a type or a conversion mismatch), so the only options to
trigger
an error, or throw an exception.
I like the exception
Hi!
2010/6/2 Stas Malyshev smalys...@sugarcrm.com
Hi!
Is there some other reason / use case for wanting exceptions? So, I
mean, where is the use case where '123abc' will be passed to a
type-hinted field where you could catch the exception and do something
meaningful to carry on with the
Hi!
The optional scalar type hinting would raise a catchable fatal error
that could be converted to an exception.
If you advocate moving PHP to full-OO with exceptions as primary error
handling mechanism, it's fine - but there would be nothing optional or
hinting about it - once you
On Tue, Jun 1, 2010 at 7:55 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
The optional scalar type hinting would raise a catchable fatal error
that could be converted to an exception.
If you advocate moving PHP to full-OO with exceptions as primary error
handling mechanism, it's
Hi!
type hinting for arrays and objects does the same (catchable fatal error
on mismatch), whats the difference?
if you start using a piece of code, which uses type hinting for
non-scalar variables, you already have to deal with this kind of
situation (custom error handler, or catching the
On Tue, Jun 1, 2010 at 8:43 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
type hinting for arrays and objects does the same (catchable fatal error
on mismatch), whats the difference?
if you start using a piece of code, which uses type hinting for
non-scalar variables, you already
Hi!
Also, it never makes sense to convert one object type into another, and
almost never this operation can be defined.
array and ArrayObject?
This is a good example because strict typing would probably reject
ArrayObject passed as array, thus defeating the whole purpose of having
On Tue, Jun 1, 2010 at 10:11 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Also, it never makes sense to convert one object type into another, and
almost never this operation can be defined.
array and ArrayObject?
This is a good example because strict typing would probably
Hello!
As I mentioned, I think that we have to inform the caller about the problem
(be either a type or a conversion mismatch), so the only options to trigger
an error, or throw an exception.
I like the exception idea better, because it can be easily handled localy
(no need to register a
Hi!
Is there some other reason / use case for wanting exceptions? So, I
mean, where is the use case where '123abc' will be passed to a
type-hinted field where you could catch the exception and do something
meaningful to carry on with the execution of the program other than
simply error-ing out?
Hi!
Pretty much everywhere. Suppose you have form with, say, 2 fields and first
field does not validate. Maybe you want to check the second field too and
give the user both errors if they are both wrong?
In general, looking at strict typing as user input validation mechanism is a
very bad
On Wed, Jun 2, 2010 at 7:41 AM, Chad Fulton chadful...@gmail.com wrote:
Hi!
Pretty much everywhere. Suppose you have form with, say, 2 fields and first
field does not validate. Maybe you want to check the second field too and
give the user both errors if they are both wrong?
In general,
I remember Marcus worked on something like that some time ago. Might still
be into SVN or somewhere I think.
Julien
On Sat, May 29, 2010 at 9:03 PM, Ferenc Kovacs i...@tyrael.hu wrote:
On Sat, May 29, 2010 at 7:34 PM, Zeev Suraski z...@zend.com wrote:
At 20:28 29/05/2010, Chris Stockton
On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote:
On 28.05.2010, at 11:22, Etienne Kneuss wrote:
so, it would be nice to update the RFC(s), so that we have a solid
ground on which we can discuss/vote.
i agree. i currently see 5 fundamental different options on the table:
1)
On Mon, May 31, 2010 at 2:42 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote:
On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote:
On 28.05.2010, at 11:22, Etienne Kneuss wrote:
so, it would be nice to update the RFC(s), so that we have a solid
ground on which we can discuss/vote.
Well at least I fixed the splweaktypehintingwithautoboxing for the function
to return ++$var instead of $var++ which couldn't make it ;-)
Julien
On Mon, May 31, 2010 at 5:54 PM, Ferenc Kovacs i...@tyrael.hu wrote:
On Mon, May 31, 2010 at 2:42 PM, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
thank you, btw. I don't know how did that happen, I copypasted from my
previous post, which has $var++ in it :)
Tyrael
On Mon, May 31, 2010 at 7:06 PM, Julien Pauli jpa...@php.net wrote:
Well at least I fixed the splweaktypehintingwithautoboxing for the function
to return ++$var instead of
Hi.
This is one of those out there ideas. Not sure about the feasibility of it.
So ...
Currently, there are not a massive number of functions that can detail
what has been supplied to a function. Currently, the most useful is
func_get_args().
func_get_args() has no parameters and simply
Am 28.05.2010 20:07, schrieb Stas Malyshev:
On top of that, your boilerplate throws exception. Strict typing would
error out. That's very different thing (exceptions can be handled
hierarchically, errors can't). So replacing that with strict type
probably won't do the same.
The optional
My biggest issue as a user is the fatal errors. Why are we blowing up on
something that should throw some kind of useful argument exception? I end up
in my applications using instanceof everywhere because their is important
cleanup to be done before the end of the request. For example I can't
At 20:28 29/05/2010, Chris Stockton wrote:
My biggest issue as a user is the fatal errors. Why are we blowing
up on something that should throw some kind of useful argument
exception? I end up in my applications using instanceof everywhere
because their is important cleanup to be done before
At 20:34 29/05/2010, Zeev Suraski wrote:
At 20:28 29/05/2010, Chris Stockton wrote:
My biggest issue as a user is the fatal errors. Why are we blowing
up on something that should throw some kind of useful argument
exception? I end up in my applications using instanceof everywhere
because
On Sat, May 29, 2010 at 7:34 PM, Zeev Suraski z...@zend.com wrote:
At 20:28 29/05/2010, Chris Stockton wrote:
My biggest issue as a user is the fatal errors. Why are we blowing up on
something that should throw some kind of useful argument exception? I end up
in my applications using
At 08:28 28/05/2010, Tjerk Anne Meesters wrote:
On the other hand, auto-casting used to be my favourite until I
glanced over the conversion table; it's not just regular casting, it
has different rules. I wouldn't want to be the one going over that
table when writing code against a certain API, I
On Friday 28 May 2010 01:54:55 am Zeev Suraski wrote:
At 08:28 28/05/2010, Tjerk Anne Meesters wrote:
On the other hand, auto-casting used to be my favourite until I
glanced over the conversion table; it's not just regular casting, it
has different rules. I wouldn't want to be the one going
As man from userland, I totally agree with Larry. I see completely no sense
in raising error when a safe conversion can be done. And I don't like
current implementation at all. It is completely not-php-way.
2010/5/28 Larry Garfield la...@garfieldtech.com
On Friday 28 May 2010 01:54:55 am Zeev
I'd say that I agree on this, I would like to see the conversion rules
cleaned up and made more clear. The idea of emitting e_warning or
e_strict on conversions with data loss throughout the language is very
appealing. Maybe we really need to do that so conversion rules and
type hinting rules to
On 28.05.2010, at 10:57, Arvids Godjuks wrote:
I'd say that I agree on this, I would like to see the conversion rules
cleaned up and made more clear. The idea of emitting e_warning or
e_strict on conversions with data loss throughout the language is very
appealing. Maybe we really need to do
Hi,
Apparently, the discussion is not looking like it will end up in a
general agreement. I'd suggest the following:
1) Since it seems that there is concerns about the current
auto-casting RFC (inconsistencies, when/what errors, etc..), I believe
it's authors should refine the RFC to propose
On Fri, May 28, 2010 at 11:04, Lukas Kahwe Smith m...@pooteeweet.org wrote:
In the weak type hinting RFC the conversion rules are pretty clear to me,
anything that converts without data loss goes through, anything else does not
convert silently (or even fails if we want to be so strict,
Lukas, Etienne, Hannes:
You all pointed out the issues and enhansments that can be done.
Basic thing I want to say that type hinting and data casting should be
done in tandem and work the same way. So generally there is a need to
rething how type casting works and implement enhansments with
Am 27.05.2010 12:59, schrieb Ilia Alshanetsky:
As far as your example goes consider a function that expects a boolean, but
instead gets an int/string/float, which in nearly all cases will result in
TRUE. Which is not the desired outcome.
Which is why, for instance, PHPUnit today is full of
Am 27.05.2010 00:30, schrieb Derick Rethans:
Would it be possible to support two syntaxes:
function foo( (int) $bar) { } // auto-cast to int
function foo(int $bar) { } // require int
I think that's a brilliant plan. We won't ever agree on whether we want
either strict type hinting, or
Hi!
Currently if you pass int(42) to an array type hint it will fail. For
the weak type hint it will cast it to whatever was hinted.
This makes sense. 42 doesn't have array representation. We might
introduce a rule that if anything passed to a function that requires
array gets converted to
Hi!
I think that's a brilliant plan. We won't ever agree on whether we want
either strict type hinting, or casting typehinting and this provides
both possibilities with the following pros:
For the record, I think having both is even worse than having one of
them. That makes the language into
Hi!
Which is why, for instance, PHPUnit today is full of code like this
public function foo($flag)
{
if (!is_bool($flag)) {
throw new InvalidArgumentException(/* ... */);
}
}
This is the type of code that I want to get rid off using scalar
Am 28.05.2010 19:45, schrieb Stas Malyshev:
The question here is does it make sense somewhere outside PHPUnit?
I have seen boilerplate [1] code like this in other Open Source projects
as well as closed-source applications.
--
[1] boilerplate as is code I need to write because the language
Hi!
I have seen boilerplate [1] code like this in other Open Source projects
as well as closed-source applications.
I've seen all kinds of code, whether making sense or not. The question
is not if somebody somewhere is doing it but if it's the right thing to
recommend to do. I think
Just wanted to remind everyone that option #3 proposed earlier doesn't
include auto-casting when data loss is happening.
That means:
function hintMe(int $number) {
}
hintMe(1);
hintMe(1);
hintMe(1.0);
hintMe(array(1)); - Error or notice, no array - int conversions
hintMe(1.25); - Error or
Hi,
On Thu, May 27, 2010 at 09:45, Arvids Godjuks arvids.godj...@gmail.com wrote:
Just wanted to remind everyone that option #3 proposed earlier doesn't
include auto-casting when data loss is happening.
That means:
function hintMe(int $number) {
}
hintMe(1);
hintMe(1);
hintMe(1.0);
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that integer or float - no matter. I don't want to make my code look
like this:
function
Hi,
if it comes to auto-converting (that's different from existing type-juggling):
wouldn't it be nice, to change type-juggling as well?
I know about BC breaks here, thus it would need till PHP 7 or so to become the
default behavior. But I think, BC breaks mainly occur in the cases where
On Thu, May 27, 2010 at 10:34, Arvids Godjuks arvids.godj...@gmail.com wrote:
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that
Heh... Please do a DB select and make a var_dump on the rows from
database. You will see things like:
array(3) {
[id]=
string(1) 1
[ref_id]=
string(2) 15
[name]=
string(7) Bla bla
}
string, string and string again.
And that breaks the concept of strict type hinting. Because we get
On 27.05.2010, at 10:45, Daniel Egeberg wrote:
If you don't know whether the user/database provided information you
have is correct before you pass it along to something else, I would
say that the code indeed is bad. Unless you regard 123abc as a valid
value from your user, don't allow the
, explict_types=On/Off.
- Original Message -
From: Daniel Egeberg daniel.egeb...@gmail.com
To: Arvids Godjuks arvids.godj...@gmail.com
Cc: Etienne Kneuss col...@php.net; PHP internals internals@lists.php.net
Sent: Thursday, May 27, 2010 4:45 PM
Subject: Re: [PHP-DEV] Type hinting
On Thu, May
Exactly.
Yes, we check data coming from POST/GET/COOKIE and other really
external resources. But doing the same for data coming from database
is kinda an overkill. And most projects do select their data mostly
from databases. And I'm 100% sure that people will not use type
hinting if they have to
On Thu, May 27, 2010 at 10:53, Arvids Godjuks arvids.godj...@gmail.com wrote:
Heh... Please do a DB select and make a var_dump on the rows from
database. You will see things like:
array(3) {
[id]=
string(1) 1
[ref_id]=
string(2) 15
[name]=
string(7) Bla bla
}
string, string and
arvids.godj...@gmail.com
Cc: Etienne Kneuss col...@php.net; PHP internals
internals@lists.php.net
Sent: Thursday, May 27, 2010 4:45 PM
Subject: Re: [PHP-DEV] Type hinting
On Thu, May 27, 2010 at 10:34, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Please read more carefully - what I mean
On Thu, May 27, 2010 at 11:05, 魏世江 shiji...@staff.sina.com.cn wrote:
Hi .
I think there is no need to argue on it any more.
Good programmers have the ability to manipulate the variables' types.
But I think it's the icing on the cake if we give the PHP programmer the
choice of whether use
On 27.05.2010, at 11:05, 魏世江 wrote:
But I think it's the icing on the cake if we give the PHP programmer the
choice of whether use explicit types.
For examlpe, we may add a switch in php.ini, let's say, explict_types=On/Off.
heh .. you are giving the question cake or death a new dimension
Lest not touch the validation topic - it's obvious and we are not
talking about it.
As for the DB - I don't want to write code like this.
// Select from DB
// Start the loop fetch the data
settype('integer', $row['id']);
settype('float', $row['price']);
settype('int', $row['amount']);
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting in a
potentially un-expected value. I must say I am completely against the
auto-conversion hint idea.
As far as your example goes consider a
Brian,
What we are talking about here is an **optional** feature for user-land
function that allow the author to implement really cheap input-validation to
facilitate ensuring that the correct input is supplied. Additionally it also
allows for better language interrogation for auto-generation of
Why not do the check and let auto converting for int = float, int =
string, string = int, string = float when it doesn't loose any
precision.
2010/5/27 Ilia Alshanetsky i...@prohost.org:
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input
On 27.05.2010, at 12:59, Ilia Alshanetsky wrote:
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting in a
potentially un-expected value. I must say I am completely against the
auto-conversion
Because auto-conversion is magic and like any magic causes in-consistent
behaviour and what I like to call WTF factor, which means the developer is
not quite certain what is going on. With strict type hints the behaviour is
consistent every-time and there is no ambiguity of function.
On Thu, May
At 13:59 27/05/2010, Ilia Alshanetsky wrote:
Zeev,
Auto-conversion does not validate input to the function/method, it
merely obfuscates the wrong input by converting it to desired type
resulting in a potentially un-expected value. I must say I am
completely against the auto-conversion hint
At 14:09 27/05/2010, Ilia Alshanetsky wrote:
Because auto-conversion is magic and like any magic causes
in-consistent behaviour and what I like to call WTF factor, which
means the developer is not quite certain what is going on. With
strict type hints the behaviour is consistent every-time and
On Thu, 2010-05-27 at 06:59 -0400, Ilia Alshanetsky wrote:
As far as your example goes consider a function that expects a boolean, but
instead gets an int/string/float, which in nearly all cases will result in
TRUE. Which is not the desired outcome.
Especially the int to boolean conversion is
On 2010-05-27, at 8:14 PM, Zeev Suraski wrote:
At 13:59 27/05/2010, Ilia Alshanetsky wrote:
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting in a
potentially un-expected value. I must
Is a 'scalar' typehint still being considered? It doesn't seem to suffer
from the conversion vs. typechecking argument.
Currently, it's available in trunk:
http://svn.php.net/viewvc?view=revisionrevision=299707
Ah that's great news, thanks!
Evert
--
PHP Internals - PHP Runtime
On Thu, 27 May 2010, Johannes Schlüter wrote:
On Thu, 2010-05-27 at 06:59 -0400, Ilia Alshanetsky wrote:
As far as your example goes consider a function that expects a boolean, but
instead gets an int/string/float, which in nearly all cases will result in
TRUE. Which is not the desired
1 - 100 of 596 matches
Mail list logo
