It really doesn't fit in very well with PHP's loosely typed nature which
is one of the main reasons it has been so easy to use.
I think this is one of the cornerstones that two sides disagree the most on.
People are afraid that PHP would turn into a strong-typed language by
allowing type
On Thu, 3 Jan 2008, Stanislav Malyshev wrote:
I don't get it. We already have type hinting, just not for scalars. The
Type hinting for scalars is different because it disables one of the features
of PHP language - conversion of scalar types into each other.
It doesn't disable this. It's
On Thu, 3 Jan 2008, Sam Barrow wrote:
It doesn't disable type conversion unless you specifically tell it to.
Plus the fact that if it issues an E_WARNING, your application will not
necessarily stop execution.
Stop right here for a moment. Type hints currently throw an
E_RECOVERABLE_ERROR,
On Thu, 3 Jan 2008, Sam Barrow wrote:
On Thu, 2008-01-03 at 22:37 +0100, Markus Fischer wrote:
Of course, Jochem, you're right. Exceptions would be nice.
WrongArgumentException, InvalidWhateverException, ...
That would be very nice. The full blown suite of exception error
handlers
On Thu, 2008-01-03 at 15:58 -0600, Brian Moon wrote:
I don't get it. We already have type hinting, just not for scalars.
The discussion seems to be about whether or not we should have it all.
But, the truth is, we have it. We half way have it. I fought for it to
be all or nothing back
On Fri, 2008-01-04 at 10:06 +0200, Tomi Kaistila wrote:
It really doesn't fit in very well with PHP's loosely typed nature which
is one of the main reasons it has been so easy to use.
I think this is one of the cornerstones that two sides disagree the most on.
People are afraid that PHP
See below:
-Original Message-
From: Sam Barrow [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 5:47 AM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote:
We've
I've stated my opinion on this, I'm going for standard hinting. Int
means int, not 1 or one or 1one. Bool means boolean true or false,
I don't see any difference in substance between 1 and 1.
not true, 1, 0, 0, etc.
Same for boolean - I don't see any substantial difference between
(int)0,
On Fri, 2008-01-04 at 10:08 -0800, Andi Gutmans wrote:
See below:
-Original Message-
From: Sam Barrow [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 5:47 AM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] RE: Optional scalar type hinting
Definitely not. Type hints now throw E_RECOVERABLE_ERROR, and that
should be the same for any other typehinting system that we add.
Then we don't add any, because without static type control it's just a
ticking timebomb waiting to blow up your production code (and having
application display
Hello everyone
I figured I would bring my opinion in to support of Sam's request for a more
complete type hinting feature. Namely I am interested in the support for
hinting scalar types on function and method arguments and I am sure it is
safe for me to say that I speak for a lot of people.
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a
On Thu, Jan 03, 2008 at 12:21:21PM -0500, Sam Barrow wrote:
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
The other thing to note about type hinting is that it could result in faster
code.
The value is checked and if needed converted
Yes it seems PHP will omit E_WARNING if you omit an argument.
(Had to actually check.)
Not a bad choice for an error and probably also easier to manage when you are
dealing with complicated error handling in large applications.
I would suggest E_WARNING or E_FATAL, but not E_NOTICE or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Alain Williams wrote:
On Thu, Jan 03, 2008 at 12:21:21PM -0500, Sam Barrow wrote:
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
The other thing to note about type hinting is
am I the only one to consider E_FATAL (as generated for class typehints) makes
type hinting useless - given that there is no compile stage at which to catch
typehint related mistakes. which means there is no way to trap the issue and
offer some useful/user-friendly feedback to the user (in
I think we should stick with E_WARNING for now. If you want to use
exceptions you can throw one in a custom error handler. I can change
about 4 lines of code in my patch to have it emit an E_WARNING easily.
On Thu, 2008-01-03 at 19:49 +0100, Jochem Maas wrote:
am I the only one to consider
When the type hint says I want an integer, then only integer should be
accepted; no casting should be done. It may give predictable results
Why people that want Java just don't use Java I wonder? PHP never was a
strict static typed language.
--
Stanislav Malyshev, Zend Software Architect
But with the current situation it feels very awkward. We get class and
array type hints but not the other scalar types?! :-/
Arrays and objects aren't scalar types, so other scalar types are in
fact all on them.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
you're right. However to me it's an unimportant factor but maybe not for
the ones who don't like to see type hints (but I don't know what there
arguments are).
thanks,
- - Markus
Stanislav Malyshev wrote:
But with the current situation it
On Thu, 3 Jan 2008, Stanislav Malyshev wrote:
When the type hint says I want an integer, then only integer should be
accepted; no casting should be done. It may give predictable results
Why people that want Java just don't use Java I wonder? PHP never was a strict
static typed language.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Stanislav Malyshev wrote:
When the type hint says I want an integer, then only integer should be
accepted; no casting should be done. It may give predictable results
Why people that want Java just don't use Java I wonder? PHP never was a
Thank you. As long as a feature is useful, why not add it? Just because
some people don't find it useful, this is not at all a reason to
completely discard the idea, especially when the only argument is well
PHP doesn't need that so just use another language.
On Thu, 2008-01-03 at 20:23 +0100,
Just so anyone who wants it has it, I have attached the last version of
my patch.
Note that it still issues a fatal error but this can be changed very
easily, would take me about 2 minutes.
Full specs:
Type hinting patch allows for 8 new type hints, in addition to array and
class type hinting.
Broken record perhaps? I am getting a bit tired of this just use Java
argument, it's perhaps even a bit arrogant. From what I read there is
plenty of people that want type hints for static types - there's a few
patches out there, it doesn't slow down the general case. So why should
we *not*
On Thu, 2008-01-03 at 20:50 +0100, Derick Rethans wrote:
With that statement I don't agree though. It needs to be usefull for a
more general public, and not introduce a huge performance loss for
example.
You're right, I didn't mean that like it sounded.
But a feature that maintains
On Thu, 3 Jan 2008, Sam Barrow wrote:
Thank you. As long as a feature is useful, why not add it?
With that statement I don't agree though. It needs to be usefull for a
more general public, and not introduce a huge performance loss for
example.
Derick
PS: Top-posting is considered evil on a
On Thu, 2008-01-03 at 22:01 +0200, Tomi Kaistila wrote:
Broken record perhaps? I am getting a bit tired of this just use
Java
argument, it's perhaps even a bit arrogant. From what I read there
is
plenty of people that want type hints for static types - there's a
few
patches out there,
On Thu, 2008-01-03 at 13:00 -0700, John Coggeshall wrote:
Wouldn't this patch also allow for additional performace optimizations
which would help counter losses even in the non-general case?
Performance optimizations in what way?
--
PHP Internals - PHP Runtime Development Mailing List
To
patches out there, it doesn't slow down the general case. So why should
we *not* add it? (And yes, I changed my mind)
My opinion is that the language is not a salad of features that somebody
somewhere found useful. The language should have some directions and
properties that make it easy to
On Thu, 2008-01-03 at 12:27 -0800, Stanislav Malyshev wrote:
patches out there, it doesn't slow down the general case. So why
should
we *not* add it? (And yes, I changed my mind)
My opinion is that the language is not a salad of features that somebody
somewhere found useful. The
Tomi Kaistila schreef:
Broken record perhaps? I am getting a bit tired of this just use Java
argument, it's perhaps even a bit arrogant. From what I read there is
plenty of people that want type hints for static types - there's a few
patches out there, it doesn't slow down the general case. So
On Jan 3, 2008 8:23 PM, Derick Rethans [EMAIL PROTECTED] wrote:
On Thu, 3 Jan 2008, Stanislav Malyshev wrote:
When the type hint says I want an integer, then only integer should be
accepted; no casting should be done. It may give predictable results
Why people that want Java just don't
In a way this is true, but I look at it this way. Some languages are
strictly typed, some are dynamically typed. PHP can have the best of
both worlds by having optional strict typing where desired, as well as
I do not believe trying to both eat cake and leave it intact would do us
well. Mixing
On Thursday 03 January 2008 22:51:27 Stanislav Malyshev wrote:
In a way this is true, but I look at it this way. Some languages are
strictly typed, some are dynamically typed. PHP can have the best of
both worlds by having optional strict typing where desired, as well as
I do not believe
Stanislav Malyshev schreef:
In a way this is true, but I look at it this way. Some languages are
strictly typed, some are dynamically typed. PHP can have the best of
both worlds by having optional strict typing where desired, as well as
I do not believe trying to both eat cake and leave it
On Thu, 2008-01-03 at 12:51 -0800, Stanislav Malyshev wrote:
In a way this is true, but I look at it this way. Some languages are
strictly typed, some are dynamically typed. PHP can have the best of
both worlds by having optional strict typing where desired, as well as
I do not believe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Sam, Jochem,
Sam Barrow wrote:
I think we should stick with E_WARNING for now. If you want to use
exceptions you can throw one in a custom error handler. I can change
about 4 lines of code in my patch to have it emit an E_WARNING easily.
On Thu, 2008-01-03 at 22:14 +0100, Jochem Maas wrote:
Stanislav Malyshev schreef:
In a way this is true, but I look at it this way. Some languages are
strictly typed, some are dynamically typed. PHP can have the best of
both worlds by having optional strict typing where desired, as well as
I don't get it. We already have type hinting, just not for scalars.
The discussion seems to be about whether or not we should have it all.
But, the truth is, we have it. We half way have it. I fought for it to
be all or nothing back then and I still think it is half done that we
don't have
So now to use such function you'd have to check your variables for
typing - otherwise your application blows up. And the type-checking
should be total - otherwise you miss some call to some function or some
code path bringing wrong value and your application blows up at runtime
- since static
So, can we switch the mundane conversation from should we have type
hinting to why don't we have scalar type hinting if we have non-scalar
type hinting? That is the real conversation. Type hinting is here.
It is not going anywhere. Let's finish the job.
Amen.
Tomi Kaistila
PHP Developer
On 1/4/08, Stanislav Malyshev [EMAIL PROTECTED] wrote:
There aren't two code models here at all. You can have a function
parameter, or you can have a type-enforced function parameter. PHP
So now to use such function you'd have to check your variables for
typing - otherwise your application
The question that pops to my mind by reading this thread is what's wrong with
the following code:
function add(int $a, int $b)
{
return $a + $b;
}
add($_REQUEST['a'], $_REQUEST['b']); // Assume $_REQUEST['a'] == '1' and
$_REQUEST['b'] == '2'.
And the truth is that if I was forced to
I don't get it. We already have type hinting, just not for scalars. The
Type hinting for scalars is different because it disables one of the
features of PHP language - conversion of scalar types into each other.
So, can we switch the mundane conversation from should we have type
hinting to
Unless you are aware of the type of your variables and the data they contain
as you write your applications, you are only inviting trouble anyway. Yes,
If you think so, you should use statically typed languages, why invite
trouble from the start?
The one I mentioned not so long ago, or we
type-hinting is asserting.
checking of types is needed only on interface-border points (where
With strict checking, that means instead of calling:
foo($bar);
you'd have now to do:
if(is_integer($bar)) {
// stupid foo() call would blow up if passed not integer, so I have
to manually handle
W liście Stanislav Malyshev z dnia czwartek 03 stycznia 2008:
type-hinting is asserting.
checking of types is needed only on interface-border points (where
With strict checking, that means instead of calling:
foo($bar);
you'd have now to do:
if(is_integer($bar)) {
// stupid foo()
you'd have now to do:
if(is_integer($bar)) {
!is_integer() was meant there of course.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
This code is just a good argument *FOR* type hints. When foo is:
function foo(int $bar) {...}
and you want the code to die if $bar is not integer, then foo($bar) would be
Why would you want it? I wouldn't want my code to die, I would want it
to work.
you have either an int or string
On Jan 4, 2008 12:23 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
This code is just a good argument *FOR* type hints. When foo is:
function foo(int $bar) {...}
and you want the code to die if $bar is not integer, then foo($bar) would be
Why would you want it? I wouldn't want my code to
W liście Stanislav Malyshev z dnia piątek 04 stycznia 2008:
This code is just a good argument *FOR* type hints. When foo is:
function foo(int $bar) {...}
and you want the code to die if $bar is not integer, then foo($bar) would
be
Why would you want it? I wouldn't want my code to die, I
Unless you are aware of the type of your variables and the data they
contain as you write your applications, you are only inviting trouble
anyway. Yes,
If you think so, you should use statically typed languages, why invite
trouble from the start?
It is not inviting trouble. In fact it is
$n2 is a string value of the number one. What happens if, during a more
complex computation an incorrect value is store to $n2, lets say an
alphabetic character?
The value would be interpreted as a zero and the result would be wrong.
If you change data, result changes - surprise! If you set
If you change data, result changes - surprise! If you set $n2 to 42,
result would be wrong too, if by right you mean $n2 being 1 and not 42.
How it has anything to do with static typing?
Ohh gee wiz... Well odds are that you would not want the value to increase by
zero, when the intention was
The value is this:
With type hinting:
function a(string $mystring, num $mynum, object $myobject) {
}
Without type hinting:
function a($mystring, $mynum, $myobject) {
if (!is_string($mystring)) {
trigger_error('Parameter 1 of function a() must be a string.',
E_USER_WARNING) ;
}
if
You have a point, but for input in general non type-hinted functions
should be used. Your first example shows a scenario in which not to use
type hinting, because all $_REQUEST input is in string form. However
when dealing with internal functions and methods, type hinting can
prevent flawed
If foo() is changed, the type hints should be removed. Most of the time
however, a function will not change its functionality enough to change
the purpose of the arguments.
On Thu, 2008-01-03 at 14:50 -0800, Stanislav Malyshev wrote:
type-hinting is asserting.
checking of types is needed only
On Thu, Jan 03, 2008 at 10:13:22PM -, Amir Abiri wrote:
So the bottom line is that it seems to me that what would be really useful is
not strict type
hinting, but more like Juggling hinting. i.e differentiate between an OK
type juggle and a bad
type juggle. Silently perform the first,
It doesn't disable type conversion unless you specifically tell it to.
Plus the fact that if it issues an E_WARNING, your application will not
necessarily stop execution.
On Thu, 2008-01-03 at 14:30 -0800, Stanislav Malyshev wrote:
I don't get it. We already have type hinting, just not for
On Thu, Jan 03, 2008 at 07:36:48PM +0100, Markus Fischer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Alain Williams wrote:
On Thu, Jan 03, 2008 at 12:21:21PM -0500, Sam Barrow wrote:
I think E_WARNING would be appropriate. That's what happens when you
omit an argument
On Thu, Jan 03, 2008 at 10:43:39AM -0800, Stanislav Malyshev wrote:
When the type hint says I want an integer, then only integer should be
accepted; no casting should be done. It may give predictable results
Why people that want Java just don't use Java I wonder? PHP never was a
strict
On Thu, Jan 03, 2008 at 03:14:37PM -0500, Sam Barrow wrote:
On Thu, 2008-01-03 at 13:00 -0700, John Coggeshall wrote:
Wouldn't this patch also allow for additional performace optimizations
which would help counter losses even in the non-general case?
Performance optimizations in what
You aren't making it a strict static typed language. All that you are doing
is saying that at certain points (function entry) that the values are checked
and converted to certain types. If within the fuction an argument hinted as
integer is used in a string context, the juggling will still
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stanislav Malyshev wrote:
You aren't making it a strict static typed language. All that you are
doing
is saying that at certain points (function entry) that the values are
checked
and converted to certain types. If within the fuction an argument
For me type hinting has nothing to do with type conversion. Hinting
a 'string' expects a string, nothing else, not even an object.
Agreed. It seems like a way to compromise between those who support this
feature and those who do not, but in a way that completely defeats the
purpose of type
On Fri, 2008-01-04 at 02:01 +, Steph wrote:
I'm just a php developer who didn't agree with the rules on type
hinting.
... or superglobals, or multiple class inheritance rules. Why PHP? What did
we do? :\
More seriously (because I don't think this has a hope in hell of getting in,
I just like PHP enough that rather than switch languages, I would like
to attempt to make PHP better. I've only been working with the PHP
source since November and I'm 19
Right, that'd explain it. It's just that usually people do a bit of PHP
development (websites, applications, whatever) or
On Fri, 2008-01-04 at 02:56 +, Steph wrote:
I just like PHP enough that rather than switch languages, I would like
to attempt to make PHP better. I've only been working with the PHP
source since November and I'm 19
Right, that'd explain it. It's just that usually people do a bit of
On Fri, 2008-01-04 at 02:56 +, Steph wrote:
I just like PHP enough that rather than switch languages, I would like
to attempt to make PHP better. I've only been working with the PHP
source since November and I'm 19
Right, that'd explain it. It's just that usually people do a bit of
snip /
That wasn't what I meant, I'm sorry if it came over that way.
I used PHP for quite a while before using any object oriented stuff.
When I was ready, I started doing object oriented programming.
That's pretty normal :)
Also, I didn't say we should throw away loose typing. This is not
We've discussed scalar type hinting many times in the past and decided
against it.
It really doesn't fit in very well with PHP's loosely typed nature which
is one of the main reasons it has been so easy to use. The only reason
why it works with classes and arrays is because those are unambiguous
73 matches
Mail list logo
