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 "A
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 betwee
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
> > Subje
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 -
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 Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote:
> 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
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 PH
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
> hand
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, 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. I
> 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 hint
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
co
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 at all
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 bi
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 bi
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 th
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 getti
> 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 typ
-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
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 happen.
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
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
> stric
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
> >> omi
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 sc
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 t
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 o
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 interac
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 (!is_int($myn
> 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 wa
$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 $n
> > 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 fac
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 t
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
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 represen
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: htt
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
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 it
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 yo
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" t
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 explic
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 appl
> 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 Devel
> 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 st
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 s
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 blows up. And the type-checking
should be total - otherwis
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 could be a future project, depending on code con
On Thu, 2008-01-03 at 13:37 -0800, Stanislav Malyshev wrote:
> > suitable to enterprise level development. it's merely a case of
> > not being able to please everyone all of the time (or of not having your
> > cake
>
> PHP is pretty good with pleasing people (including enterprise
> developers) a
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, a
-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.
>
suitable to enterprise level development. it's merely a case of
not being able to please everyone all of the time (or of not having your cake
PHP is pretty good with pleasing people (including enterprise
developers) as it is now, and will get better in 5.3 and 6 - without any
strict typing. So
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 bel
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 lea
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 be
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 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 Ja
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
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
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 un
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
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
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 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 backw
> 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 *
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.
-
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, D
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 langu
-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 fee
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] http://www.ze
-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
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 E_FAT
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 practice
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
[EMAI
-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
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 E_STRICT,
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 converte
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 parent
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 parent
77 matches
Mail list logo
