+1
On Mon, Jul 6, 2009 at 10:42 PM, Eddie Drapkinoorza...@gmail.com wrote:
On Mon, Jul 6, 2009 at 8:52 PM, Ilia Alshanetskyi...@prohost.org wrote:
Last week or so there was a fairly detailed discussion on the internals list
regarding type hinting based on my original patch. Since then the
On Tue, Jul 7, 2009 at 8:52 AM, Ilia Alshanetskyi...@prohost.org wrote:
I would like to ask all developers to voice their opinions of whether it
makes sense to add this to 5.3 or to throw it away (either one is fine btw).
To keep the process simple flamewar free, please restrict yourself to
On Tue, Jul 7, 2009 at 4:52 AM, Ilia Alshanetskyi...@prohost.org wrote:
Last week or so there was a fairly detailed discussion on the internals list
regarding type hinting based on my original patch. Since then the patch has
been revised to address the major concerns that were identified
Hi all,
I've submitted this suggestion once before, but it was quickly shunned with
two generic answers: It's not the PHP way and It all boils down to
documentation. That's what PHPDoc is for. Both of those are partially
correct, but I feel the benefits and other uses certainly make a better
Not bringing the issue back up on the list, I was just wondering if
there is a supporter of type hinting that would be willing to help me
implement an automatic conversion of objects with a __tostring() method
to strings if the object was passed as an argument with a string type
hint.
--
PHP
On Wed, February 6, 2008 7:20 am, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the types
that
we use in the manual) - and they should behave in the same way
On 06/02/2008, Stefan Priebsch [EMAIL PROTECTED] wrote:
Sam Barrow schrieb:
If anyone has any objections to a scalar type hint please raise a
valid point.
Chris Stockton schrieb:
This library would probably have ~300(String) + ~110(Int)
~40(Resource) ~30(Bool) ~10(Float) = 500 less
On Feb 6, 2008 9:31 AM, Derick Rethans [EMAIL PROTECTED] wrote:
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same way as the
other type hints that we laready have.
Same here.
--
Pierre
http://blog.thepimp.net |
On Wed, 6 Feb 2008, Steph Fox wrote:
As with so many topics on this list, I have no authority to influence
the outcome. I personally think they've all got rules to instantly
delete my email (but that's cause I'm paranoid).
That's rubbish Richard - in some ways you're the most important
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same way as the
other type hints that we laready have.
I also agree with this too.
Add the common types first and then if there is a good reason, add special
ones but
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Steph Fox wrote:
As with so many topics on this list, I have no authority to influence
the outcome. I personally think they've all got rules to instantly
delete my email (but that's cause I'm paranoid).
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same way as the
other type hints that we laready have.
True,
To me it does not make sense to have a scalar type hint. For the
simple reason it's inconsistent with PHP, and it adds no value other
then the fact you then know the value is not on array (or maybe not a
resource?). It's also inconsistent with PHP, array type hinting, is
complemented by array
On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same
On Wed, 2008-02-06 at 06:30 -0700, Chris Stockton wrote:
To me it does not make sense to have a scalar type hint. For the
simple reason it's inconsistent with PHP, and it adds no value other
then the fact you then know the value is not on array (or maybe not a
Ok. Well the array type hint
HI Sam,
On Feb 6, 2008 2:33 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the
Ok. Well the array type hint ensures that it is an array. This just does
the opposite then, I don't see a problem with that. I like to be able to
protected my code from having arrays/objects accidentally inserted into
databases or outputted.
I completely understand you want to create (easier)
Wow, you guys sure are a bit harsh
Here's the problem - there's a group of people who really want true (I
might say javaish) type-hints for scalar values - int, bool, string,
float, and won't settle for anything less.
There's a group who thinks type hints are stupid because of the way php
On Wed, 2008-02-06 at 15:31 +0100, Pierre Joye wrote:
HI Sam,
On Feb 6, 2008 2:33 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
Hi Sam,
On Feb 6, 2008 4:08 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 15:31 +0100, Pierre Joye wrote:
HI Sam,
On Feb 6, 2008 2:33 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow
On Wed, 2008-02-06 at 10:09 -0500, Elizabeth M Smith wrote:
Wow, you guys sure are a bit harsh
Here's the problem - there's a group of people who really want true (I
might say javaish) type-hints for scalar values - int, bool, string,
float, and won't settle for anything less.
Hi All,
Just a suggestion. Maybe make your case analyzing a set of
representative php applications for calls to the various is*() methods
(maybe even factoring in assert()). This could help in showing how
often people are currently forced to write out type checks.
My humble guess:
On Feb 6, 2008 5:13 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Hi All,
Just a suggestion. Maybe make your case analyzing a set of
representative php applications for calls to the various is*() methods
(maybe even factoring in assert()). This could help in showing how
often people are
Really, it's not the most accurate test, to make it more accurate you
would only check parameter variables but I wanted something fast.
These are the calls to the is_* family from a major library. All calls
are within a Class { }. I think this shows several things, a couple I
would like to mention
Sam Barrow schrieb:
If anyone has any objections to a scalar type hint please raise a
valid point.
Chris Stockton schrieb:
This library would probably have ~300(String) + ~110(Int)
~40(Resource) ~30(Bool) ~10(Float) = 500 less function calls, and much
cleaner code if there was type hinting.
On Wed, Feb 06, 2008 at 06:47:23PM +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
If anyone has any objections to a scalar type hint please raise a
valid point.
Chris Stockton schrieb:
This library would probably have ~300(String) + ~110(Int)
~40(Resource) ~30(Bool) ~10(Float) = 500
This library would probably have ~300(String) + ~110(Int)
~40(Resource) ~30(Bool) ~10(Float) = 500 less function calls, and much
cleaner code if there was type hinting.
You forgot the code that you'd have to write to deal with the situation
that typehinted function fails.
I understand a lot
On Feb 6, 2008 7:13 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
with. Bottom line all stubbornness should be put aside and look to see
if it would improve the language use and appeal to a large user base,
No, it won't improve.
for you.
Cheers,
--
Pierre
http://blog.thepimp.net |
On 05/02/2008, Sam Barrow [EMAIL PROTECTED] wrote:
Hey, I have an idea.
We can appeal to the PHP developers to simply include the scalar type
hint.
They can't argue that this goes against type juggling, as the four
scalar types can juggle, and this allows any of them.
Anyone who is against
On Feb 6, 2008 12:02 AM, Tomi Kaistila [EMAIL PROTECTED] wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there isn't a way to answer that point. Anyone who does would
Good point. Either way the argument against it is even weaker now that
all it has are the scalar and resource types. It is now fully compliant
with PHP's type juggling system. Anyone who disagrees with a scalar
hint should probably also disagree with the array hint.
On Wed, 2008-02-06 at 01:02
On 05/02/2008, Tomi Kaistila [EMAIL PROTECTED] wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there isn't a way to answer that point. Anyone who does would
be
Tomi Kaistila wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there isn't a way to answer that point. Anyone who does would
be laughed out of the barn. Like I told Sam
On Tue, 2008-02-05 at 23:19 +, Richard Quadling wrote:
On 05/02/2008, Tomi Kaistila [EMAIL PROTECTED] wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there
On Wed, 2008-02-06 at 00:27 +0100, Markus Fischer wrote:
Tomi Kaistila wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there isn't a way to answer that point.
As with so many topics on this list, I have no authority to influence
the outcome. I personally think they've all got rules to instantly
delete my email (but that's cause I'm paranoid).
That's rubbish Richard - in some ways you're the most important person on
the list. Odd, eh?
I think
Rasmus Lerdorf skrev:
PHP is first and foremost a Web scripting language. Everything we do
and every decision is based on that.
There is one aspect that has popped up in the discussion about array
syntax but not here where it is almost as applicable.
ECMAScript 4 will have introduce
On Wed, 2008-01-09 at 00:58 +0200, Tomi Kaistila wrote:
Ok, but a scalar becomes useful for a couple of important things.
Scalars are all displayable values, that can be stored in a db,
outputted, etc. The scalar type hint prevents errors related to objects,
resources, and arrays
Hi,
I am still wondering if we ever going to get a summary of this
discussion.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 07/01/2008, Stefan Priebsch [EMAIL PROTECTED] wrote:
Robert Cummings schrieb:
The onus should be on consumers of my API to use it properly, not on me
to jump through hoops to make sure they gave me the correct data at
every step of the way. I stopped holding hands in grade 3 or so.
On Tue, 2008-01-08 at 09:41 +, Richard Quadling wrote:
On 07/01/2008, Stefan Priebsch [EMAIL PROTECTED] wrote:
Robert Cummings schrieb:
The onus should be on consumers of my API to use it properly, not on me
to jump through hoops to make sure they gave me the correct data at
every
I believe the cleanest solution that we could implement would be using
the type casting with Type objects.
I experimented with this for a couple of months, a couple of weeks ago. In
opinion, it does not work well. I am guessing developers at java also figured
the same since they still also
On Tue, 2008-01-08 at 16:03 +0200, Tomi Kaistila wrote:
I believe the cleanest solution that we could implement would be using
the type casting with Type objects.
I experimented with this for a couple of months, a couple of weeks ago. In
opinion, it does not work well. I am guessing
But the syntax is longer ($a = 5 vs $a = new Integer(5)), and if you
have a large application with hundreds of integers it starts to add up.
Performance is also much worse when using objects for every variable.
I agree. That is what I meant by ugly and clumsy in my last post.
This sounds
On Tue, 2008-01-08 at 22:47 +0200, Tomi Kaistila wrote:
But the syntax is longer ($a = 5 vs $a = new Integer(5)), and if you
have a large application with hundreds of integers it starts to add up.
Performance is also much worse when using objects for every variable.
I agree. That is what I
Ok, but a scalar becomes useful for a couple of important things.
Scalars are all displayable values, that can be stored in a db,
outputted, etc. The scalar type hint prevents errors related to objects,
resources, and arrays attempting to be stored in the db or echoed.
True, but honestly I do
The main flaw in type conversion hinting is that it's nearly pointless.
Why convert the type at function call? PHP will automatically juggle the
type depending on the variable's destination, really no point in
converting it one more time when calling the function
Well that is not entirely
-0300
From: Martin Alterisio [EMAIL PROTECTED]
To: PHP Developers Mailing List internals@lists.php.net
Subject: [PHP-DEV] type hinting
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
Sorry for the noise. That was meant to be forwarded off-list.
Wietse
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sam Barrow schrieb:
Well these errors can be handled like any other, as long as they don't
issue a fatal.
That's exactly my point. You need to handle them. So in pidgin PHP that
could look something like
function foo(int $foo) {}
try
{
foo($bar);
}
catch (WhateverException $e)
{
since
On Mon, 2008-01-07 at 15:19 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Well these errors can be handled like any other, as long as they don't
issue a fatal.
That's exactly my point. You need to handle them. So in pidgin PHP that
could look something like
function foo(int $foo)
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number.
I did not make the point of my code clear enough. do_whatever is not the
code that triggers the error, but the code that
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number.
I did not make the point of my code clear enough. do_whatever
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number.
I did not make the point of my code clear enough. do_whatever
On Mon, 2008-01-07 at 13:33 -0500, Robert Cummings wrote:
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number.
On Jan 7, 2008 1:34 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Mon, 2008-01-07 at 13:33 -0500, Robert Cummings wrote:
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error
Robert Cummings schrieb:
The onus should be on consumers of my API to use it properly, not on me
to jump through hoops to make sure they gave me the correct data at
every step of the way. I stopped holding hands in grade 3 or so.
Still you force any defensive coder to repeat explicit type
On Mon, 2008-01-07 at 19:45 +0100, Stefan Priebsch wrote:
Robert Cummings schrieb:
The onus should be on consumers of my API to use it properly, not on me
to jump through hoops to make sure they gave me the correct data at
every step of the way. I stopped holding hands in grade 3 or so.
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
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 when
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 means is:
*
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 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 specifying
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
?php
echo (int) 1,
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 Hinting. Functions are
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 dealing with
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 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 a
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
= array())
2008/1/4, Jani Taskinen [EMAIL PROTECTED]:
As I'm +1 for OPTIONAL scalar-type hinting.
me too +1 as long as :
?php
function foo(int $a) {}
foo('5');
?
Raises an error, and is rejected because is not a valid integer, otherwise -1
--
http://www.kissofjudas.net/
--
PHP Internals - PHP
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
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
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
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
function. It
I'm a little afraid that introducing type hints will have us end up with
code like this (to stick with a previous example):
?php
function foo(int $a) {}
foo((int) '5');
?
So, just to make sure, add Java-ish typecasts everywhere. I'm not sure
if that solves the problem (error handling still
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):
?php
function foo(int $a) {}
foo((int) '5');
?
So, just to make sure, add Java-ish typecasts
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 but
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
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
-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 would
-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 as
| |
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 should raise
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 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.
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 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));'
make:
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 was
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
problem
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 the
problem
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 like
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
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, functions,
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
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 ensuring that
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 requireFile(string
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 :
?php
function foo(int $a) {}
foo('5');
?
Raises an error, and is rejected because is not a valid
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
function is called
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 cons camp.
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 like to have
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
problem that
301 - 400 of 596 matches
Mail list logo
