On Sun, 2008-01-06 at 23:58 -0300, Martin Alterisio wrote:
> A friend told me you were having a most interesting debate on type hinting
> in the internals, when I got some free time I checked the newsgroup to see
> how was it coming. It's quite interesting and many good points have been
> made alre
On Sun, 2008-01-06 at 23:15 +0100, Stefan Esser wrote:
> Hi Marcus,
> > That said I would only agree to type hints if we make them respect existing
> > PHP conversion rules
> if "type hints" are supposed to convert data, then they are wrongly
> named. Then they should be better called "implicit typ
On Sun, 2008-01-06 at 23:15 +0100, Stefan Priebsch wrote:
> Pierre schrieb:
> > I don't see the point to make a application working when you pass to
> > it the wrong data, it is a bad usage. That was the moto for the
>
> So how are you going to deal with the "bad usage" then? Isn't the
> proble
On Sun, 2008-01-06 at 22:41 +0100, Pierre wrote:
> On Jan 6, 2008 9:55 PM, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> > Pierre schrieb:
> > > When a method or function uses the strict typing, it is on purpose. It
> > > is documented (self documented and hopefully using normal docs). There
> > > i
On Sun, 2008-01-06 at 21:23 +, Alain Williams wrote:
> On Sun, Jan 06, 2008 at 10:08:16PM +0100, Markus Fischer wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Pierre wrote:
> > | That can be a good compromise and may make happy the cons camp.
> > | However, I would not li
On Sun, 2008-01-06 at 21:53 +0100, Pierre wrote:
> Hi Marcus,
>
> On Jan 6, 2008 9:24 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>
> > That said I would only agree to type hints if we make them respect existing
> > PHP conversion rules.
>
> That can be a good compromise and may make happy the
On Sun, 2008-01-06 at 20:02 +, Mikko Koppanen wrote:
> >
> > Why I mean by:
> >Type HINTING is not type ENFORCEMENT.
> > is that:
> >function foo(int $a) {}
> >
> >foo(1); // OK
> >
> >foo("1"); // OK - the string is juggled to an int when the
> > f
On Sun, 2008-01-06 at 15:41 -0300, Cristian Rodriguez wrote:
> 2008/1/4, Jani Taskinen <[EMAIL PROTECTED]>:
>
> > As I'm +1 for OPTIONAL scalar-type hinting.
>
> me too +1 as long as :
>
>
> function foo(int $a) {}
>
> foo('5');
>
> ?>
>
> Raises an error, and is rejected because is not a v
On Sun, 2008-01-06 at 19:18 +0200, Giedrius D wrote:
> On Jan 6, 2008 5:55 PM, Sam Barrow <[EMAIL PROTECTED]> wrote:
> > As I said, this patch is not intended for stuff like $_GET, $_POST,
> > database data, etc. It is intended for internal functions to your
> > application.
> >
> > function requir
On Sun, 2008-01-06 at 09:03 -0800, Mike Lively wrote:
> On Sun, 2008-01-06 at 10:55 -0500, Sam Barrow wrote:
>
> > function requireFile(string $file, bool $getOutput = false, array $args
> > // ...
> > This function will not be called using input data.
> >
>
> So is there some way you are ensuri
A friend told me you were having a most interesting debate on type hinting
in the internals, when I got some free time I checked the newsgroup to see
how was it coming. It's quite interesting and many good points have been
made already. But it is quite difficult to understand some concepts that
som
On Jan 7, 2008 12:01 AM, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> Pierre schrieb:
> > That what happens now with the numerous fatal errors. That's not the
> > case with an E_RECOVERABLE error. PHP has no compiler and all errors
> > will be see at runtime, even fatals like missing classes, funct
Pierre schrieb:
That what happens now with the numerous fatal errors. That's not the
case with an E_RECOVERABLE error. PHP has no compiler and all errors
will be see at runtime, even fatals like missing classes, functions,
methods, wrong interfaces or bad usages of set/getters.
Sorry, not true.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Hannes Magnusson wrote:
| It means that in PHP the type name is 'float' and referred to as
| 'float' throughout the manual
| For convenience you can use "double" (is_double($f), (double)$f,
| settype($f, "double")..), just like you can use is_int
On Jan 6, 2008 9:23 PM, Markus Fischer <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Hannes Magnusson wrote:
> | No, the comment is correct.
> |
> | "for historical [read: BC] reasons "double" is returned in case of a
> | float, and not simply "float""
> |
On Jan 6, 2008 11:15 PM, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> Pierre schrieb:
> > I don't see the point to make a application working when you pass to
> > it the wrong data, it is a bad usage. That was the moto for the
>
> So how are you going to deal with the "bad usage" then?
> Isn't th
On Sun, Jan 06, 2008 at 11:15:43PM +0100, Stefan Priebsch wrote:
> Pierre schrieb:
> > I don't see the point to make a application working when you pass to
> > it the wrong data, it is a bad usage. That was the moto for the
>
> So how are you going to deal with the "bad usage" then? Isn't the
> p
Hi Marcus,
> That said I would only agree to type hints if we make them respect existing
> PHP conversion rules
if "type hints" are supposed to convert data, then they are wrongly
named. Then they should be better called "implicit typecasting".
However "implicit typecasting" is not really usefull f
Pierre schrieb:
> I don't see the point to make a application working when you pass to
> it the wrong data, it is a bad usage. That was the moto for the
So how are you going to deal with the "bad usage" then? Isn't the
problem that this "bad usage" is discovered at runtime, vs at compile
time l
On Jan 6, 2008 10:46 PM, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> Error handling is to catch the exception (or error) and take measures so
> that your program can continue to work.
I don't see the point to make a application working when you pass to
it the wrong data, it is a bad usage. That
On Jan 6, 2008 10:48 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Hello Pierre,
>
> I agree something that is not really a number should not be converted into
> a number as it is not compatible but then...what do we do right now?
>
> [EMAIL PROTECTED] PHP_5_3]$ php -r 'var_dump(fmod(12,5));'
>
Hello Pierre,
I agree something that is not really a number should not be converted into
a number as it is not compatible but then...what do we do right now?
[EMAIL PROTECTED] PHP_5_3]$ php -r 'var_dump(fmod(12,5));'
make: `sapi/cli/php' is up to date.
float(2)
[EMAIL PROTECTED] PHP_5_3]$ php -
On Sun, Jan 06, 2008 at 10:43:19PM +0100, Marcus Boerger wrote:
> Hello Johannes,
>
> then obviously pass by reference and base type hints are not compatible.
> Apart from that so far in PHP it does not matter whether a variable changes
> in base type. And we should not change this nature of PHP
Pierre schrieb:
Sorry, but I don't understand you. Why is there no need of error
handling?
I meant in user land, like adding tests and raising exception or an error.
I think there is a misunderstanding here: testing and raising exceptions
is not error handling to me. This is checking conditi
Hello Johannes,
then obviously pass by reference and base type hints are not compatible.
Apart from that so far in PHP it does not matter whether a variable changes
in base type. And we should not change this nature of PHP.
marcus
Sunday, January 6, 2008, 10:03:44 PM, you wrote:
> Hi,
> On
On Jan 6, 2008 9:55 PM, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> Pierre schrieb:
> > When a method or function uses the strict typing, it is on purpose. It
> > is documented (self documented and hopefully using normal docs). There
> > is no need of error handling, it is an usage error and shoul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alain Williams wrote:
|> Pierre wrote:
|> | That can be a good compromise and may make happy the cons camp.
|> | However, I would not like to have "11an" returns 0 but raises an
|> | error. I can live with "[0-1.]" being converted to integer or float
On Sun, Jan 06, 2008 at 10:08:16PM +0100, Markus Fischer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Pierre wrote:
> | That can be a good compromise and may make happy the cons camp.
> | However, I would not like to have "11an" returns 0 but raises an
> | error. I can live with "[
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pierre wrote:
| That can be a good compromise and may make happy the cons camp.
| However, I would not like to have "11an" returns 0 but raises an
| error. I can live with "[0-1.]" being converted to integer or float as
| it is the case now. Even I wo
Hi,
On Sun, 2008-01-06 at 21:24 +0100, Marcus Boerger wrote:
> That said I would only agree to type hints if we make them respect existing
> PHP conversion rules.
Which we can't really do. Think about Mikko's example:
$b = '5';
function foo( int &$a )
{
echo gettype( $a );
}
foo( $b );
echo
Pierre schrieb:
When a method or function uses the strict typing, it is on purpose. It
is documented (self documented and hopefully using normal docs). There
is no need of error handling, it is an usage error and should raise a
E_{whatever}, be happy, it will not be fatal as it is now in all thes
Hi Marcus,
On Jan 6, 2008 9:24 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> That said I would only agree to type hints if we make them respect existing
> PHP conversion rules.
That can be a good compromise and may make happy the cons camp.
However, I would not like to have "11an" returns 0 bu
On Jan 6, 2008 9:37 PM, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> I'm a little afraid that introducing type hints will have us end up with
> code like this (to stick with a previous example):
>
>
> function foo(int $a) {}
>
> foo((int) '5');
>
> ?>
>
> So, just to make sure, add Java-ish typeca
I'm a little afraid that introducing type hints will have us end up with
code like this (to stick with a previous example):
So, just to make sure, add Java-ish typecasts everywhere. I'm not sure
if that solves the problem (error handling still required when the cast
is not possible), but may
Hello Cristian,
Sunday, January 6, 2008, 7:42:58 PM, you wrote:
> 2008/1/5, Alain Williams <[EMAIL PROTECTED]>:
>> "1" and 1 should both be acceptable to type hint 'int'.
> No way, "1" is an string, not an integer.
Well that is the whole issue here. In PHP "1" is pretty equal to 1 in any
funct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Hannes Magnusson wrote:
| No, the comment is correct.
|
| "for historical [read: BC] reasons "double" is returned in case of a
| float, and not simply "float""
|
| See http://docs.php.net/settype && http://docs.php.net/gettype
Thanks for the poi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mikko Koppanen wrote:
| I have not been following very closely this conversation so this might
have
| been answered already:
|
|
| $b = '5';
|
| function foo( int &$a )
| {
| echo gettype( $a );
| }
|
| foo( $b );
|
| echo gettype( $b );
|
|
| what
On Jan 6, 2008 8:37 PM, Markus Fischer <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> accidentally I came across settype() in ext/standard/type.c which says
>
> ~ } else if (!strcasecmp(new_type, "float")) {
> ~convert_to_double(*var);
> ~ } else if (
>
> Why I mean by:
>Type HINTING is not type ENFORCEMENT.
> is that:
>function foo(int $a) {}
>
>foo(1); // OK
>
>foo("1"); // OK - the string is juggled to an int when the
> function is called
>// ENFORCEMENT would have (in some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
accidentally I came across settype() in ext/standard/type.c which says
~ } else if (!strcasecmp(new_type, "float")) {
~convert_to_double(*var);
~ } else if (!strcasecmp(new_type, "double")) { /* deprecated */
~convert_to_double(*var);
2008/1/5, Alain Williams <[EMAIL PROTECTED]>:
> "1" and 1 should both be acceptable to type hint 'int'.
No way, "1" is an string, not an integer.
--
http://www.kissofjudas.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2008/1/4, Jani Taskinen <[EMAIL PROTECTED]>:
> As I'm +1 for OPTIONAL scalar-type hinting.
me too +1 as long as :
Raises an error, and is rejected because is not a valid integer, otherwise -1
--
http://www.kissofjudas.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
On Jan 6, 2008 5:55 PM, Sam Barrow <[EMAIL PROTECTED]> wrote:
> As I said, this patch is not intended for stuff like $_GET, $_POST,
> database data, etc. It is intended for internal functions to your
> application.
>
> function requireFile(string $file, bool $getOutput = false, array $args
> = arra
On Sun, 2008-01-06 at 10:55 -0500, Sam Barrow wrote:
> function requireFile(string $file, bool $getOutput = false, array $args
> // ...
> This function will not be called using input data.
>
So is there some way you are ensuring that users of your code NEVER pass
a value that trickled down from
On Sun, 2008-01-06 at 15:59 +0100, Magnus Määttä wrote:
> On Sunday 06 January 2008, Alain Williams wrote:
> > On Sun, Jan 06, 2008 at 01:02:54PM +0100, Stefan Esser wrote:
> > > Hello Alain,
> > >
> > > I think you are also confused about PHP type hinting...
> > >
> > > The manual clearly states
On Sun, 2008-01-06 at 11:28 +, Alain Williams wrote:
> On Sat, Jan 05, 2008 at 07:34:04PM -0800, Mike Lively wrote:
>
> > input is going to makes it's way into your api at some point. Now of
> > course you can (and should) be filtering this
> > input before it is used, but if imo when dealin
On Sunday 06 January 2008, Alain Williams wrote:
> On Sun, Jan 06, 2008 at 01:02:54PM +0100, Stefan Esser wrote:
> > Hello Alain,
> >
> > I think you are also confused about PHP type hinting...
> >
> > The manual clearly states:
> >
> >
> > > Type Hinting
> >
> > > PHP 5 introduces Type Hi
Am Sonntag, 6. Januar 2008 12:28 schrieb Alain Williams:
Hello,
> You are confusing the TYPE and the VALUE.
>
> What type hinting means is:
>
> * is the TYPE correct ? If so succeed.
>
> * can the VALUE be 100% converted to the desired TYPE (eg '5' to int) ?
> If so succeed.
>
> * fail
\n"; // =
Hello Stanislav,
tha makesw three then already, how about we ask around again?
Ryusuke, can you please start a new '[RFC] Square brackets shortcut' thread
to collect opinions and pass along the patch for that?
I like the anonymous function patch too. It is clean and simple. Maybe you
want to st
On Sun, Jan 06, 2008 at 01:02:54PM +0100, Stefan Esser wrote:
> Hello Alain,
>
> I think you are also confused about PHP type hinting...
>
> The manual clearly states:
>
>
> > Type Hinting
>
> > PHP 5 introduces Type Hinting. Functions are now able to force
> parameters to be objects (by s
Hello Alain,
I think you are also confused about PHP type hinting...
The manual clearly states:
> Type Hinting
> PHP 5 introduces Type Hinting. Functions are now able to force
parameters to be objects (by specifying the name of the class in the
function prototype) or arrays (since PHP 5.1)
On Sun, Jan 06, 2008 at 12:51:20PM +0100, Kore Nordmann wrote:
>
> Am Sonntag, den 06.01.2008, 11:28 + schrieb Alain Williams:
> > PLEASE READ CAREFULLY
> >
> > You have NOT understood what type hinting is about.
> >
> > You are confusing the TYPE and the VALUE.
> >
> > What type hinting me
Am Sonntag, den 06.01.2008, 11:28 + schrieb Alain Williams:
> On Sat, Jan 05, 2008 at 07:34:04PM -0800, Mike Lively wrote:
>
> > input is going to makes it's way into your api at some point. Now of
> > course you can (and should) be filtering this
> > input before it is used, but if imo whe
On Sat, Jan 05, 2008 at 07:34:04PM -0800, Mike Lively wrote:
> input is going to makes it's way into your api at some point. Now of course
> you can (and should) be filtering this
> input before it is used, but if imo when dealing with a loosely typed
> language where the same input could be hi
Hello Daniel,
> It may be off-topic for the initial post, but I disagree
> wholeheartedly with the above statement, Stefan. There are
> innumerable reasons where $_REQUEST would be much more economic than
> writing out all conditions for $_POST, $_GET, $_SESSION, $_COOKIE
>
it doesn't m
55 matches
Mail list logo
