# Optional scalar type hinting

- Thread: https://externals.io/message/34325
- Original archive: https://news-web.php.net/php.internals/34325
- Started by Tomi Kaistila on 2008-01-03T17:03:01+00:00
- Messages: 75
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/34325.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #34325 — Tomi Kaistila — 2008-01-03T17:03:01+00:00

URL: https://externals.io/message/34325#34325

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. Most people that I know 
find the current type hinting, while useful, ridiculous because it looks like 
the job was left unfinished for whatever abstract reason.

In my opinion type hinting should definitely be allowed for scalar values. As 
for return types, I am not so sure. So far I have found no use for such a 
feature in my own code, so I won't comment on it. If it is added, I welcome 
it for those who find it useful but if it is not added I will not loose sleep 
over it.

> I was thinking at something along the lines of objects also for instance:
> $i = new Integer(33); 
 After my own experiments with the subject I concur that while it can be made 
to work, it is not only a bad idea (for the reasons mentioned earlier) it is 
also redundant and just unnecessary. There is a lot better way to accomplish 
the same and that by allowing scalar values to be hinted. It is simpler, 
cleaner, and easier to implement.

> What if type hinting just generated an E_NOTICE. Nothing more for the
> time being.
 Changing it to `E_NOTICE` or `E_STRICT` defeats the purpose somewhat since if I 
write a piece of code that hints that the argument for a-whatever method 
needs to be an integer it seems useless if the user of my library can avoid 
the issue just by supressing lesser errors and those who do not need to write 
extensive error handling code to respond to this sort of error (if they 
indeed deem it necessary to do so).

While hinting is, and should remain, optional, when it is used it should be 
enforced. After all the user of my library has the option to dump it and go 
for another library that does not force types. That is the beauty of having 
options.

Tomi Kaistila
PHP Developer

---

## #34326 — Sam Barrow — 2008-01-03T17:21:21+00:00

URL: https://externals.io/message/34325#34326 · In reply to: #34325

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 class that must
return a certain type.

class a {
	abstract public function getNumber() returns int ;
}
class b extends a {
	public function getNumber() {
		return `rand()` * 3463 ;
	}
}
class c extends a {
	public function getNumber() {
		return 'I\'m going to mess everything up by returning a string.' ; //
Would cause error with type hinting.
	}
}


> 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. Most people that I know 
> find the current type hinting, while useful, ridiculous because it looks like 
> the job was left unfinished for whatever abstract reason.
> 
> In my opinion type hinting should definitely be allowed for scalar values. As 
> for return types, I am not so sure. So far I have found no use for such a 
> feature in my own code, so I won't comment on it. If it is added, I welcome 
> it for those who find it useful but if it is not added I will not loose sleep 
> over it.
> 
> > […]
>  After my own experiments with the subject I concur that while it can be made 
> to work, it is not only a bad idea (for the reasons mentioned earlier) it is 
> also redundant and just unnecessary. There is a lot better way to accomplish 
> the same and that by allowing scalar values to be hinted. It is simpler, 
> cleaner, and easier to implement.
> 
> > […]
>  Changing it to `E_NOTICE` or `E_STRICT` defeats the purpose somewhat since if I 
> write a piece of code that hints that the argument for a-whatever method 
> needs to be an integer it seems useless if the user of my library can avoid 
> the issue just by supressing lesser errors and those who do not need to write 
> extensive error handling code to respond to this sort of error (if they 
> indeed deem it necessary to do so).
> 
> While hinting is, and should remain, optional, when it is used it should be 
> enforced. After all the user of my library has the option to dump it and go 
> for another library that does not force types. That is the beauty of having 
> options.
> 
> Tomi Kaistila
> PHP Developer

---

## #34327 — Sam Barrow — 2008-01-03T17:21:46+00:00

URL: https://externals.io/message/34325#34327 · In reply to: #34325

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 class that must
return a certain type.

class a {
        abstract public function getNumber() returns int ;
}
class b extends a {
        public function getNumber() {
                return `rand()` * 3463 ;
        }
}
class c extends a {
        public function getNumber() {
                return 'I\'m going to mess everything up by returning a
string.' ; //
Would cause error with type hinting.
        }
}


> 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. Most people that
I know 
> find the current type hinting, while useful, ridiculous because it
looks like 
> the job was left unfinished for whatever abstract reason.
> 
> In my opinion type hinting should definitely be allowed for scalar
values. As 
> for return types, I am not so sure. So far I have found no use for
such a 
> feature in my own code, so I won't comment on it. If it is added, I
welcome 
> it for those who find it useful but if it is not added I will not
loose sleep 
> over it.
> 
> > […]
instance:
> > […]
>  After my own experiments with the subject I concur that while it can
be made 
> to work, it is not only a bad idea (for the reasons mentioned earlier)
it is 
> also redundant and just unnecessary. There is a lot better way to
accomplish 
> the same and that by allowing scalar values to be hinted. It is
simpler, 
> cleaner, and easier to implement.
> 
> > […]
the
> > […]
>  Changing it to `E_NOTICE` or `E_STRICT` defeats the purpose somewhat
since if I 
> write a piece of code that hints that the argument for a-whatever
method 
> needs to be an integer it seems useless if the user of my library can
avoid 
> the issue just by supressing lesser errors and those who do not need
to write 
> extensive error handling code to respond to this sort of error (if
they 
> indeed deem it necessary to do so).
> 
> While hinting is, and should remain, optional, when it is used it
should be 
> enforced. After all the user of my library has the option to dump it
and go 
> for another library that does not force types. That is the beauty of
having 
> options.
> 
> Tomi Kaistila
> PHP Developer
> 

> 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. Most people that I know 
> find the current type hinting, while useful, ridiculous because it looks like 
> the job was left unfinished for whatever abstract reason.
> 
> In my opinion type hinting should definitely be allowed for scalar values. As 
> for return types, I am not so sure. So far I have found no use for such a 
> feature in my own code, so I won't comment on it. If it is added, I welcome 
> it for those who find it useful but if it is not added I will not loose sleep 
> over it.
> 
> > […]
>  After my own experiments with the subject I concur that while it can be made 
> to work, it is not only a bad idea (for the reasons mentioned earlier) it is 
> also redundant and just unnecessary. There is a lot better way to accomplish 
> the same and that by allowing scalar values to be hinted. It is simpler, 
> cleaner, and easier to implement.
> 
> > […]
>  Changing it to `E_NOTICE` or `E_STRICT` defeats the purpose somewhat since if I 
> write a piece of code that hints that the argument for a-whatever method 
> needs to be an integer it seems useless if the user of my library can avoid 
> the issue just by supressing lesser errors and those who do not need to write 
> extensive error handling code to respond to this sort of error (if they 
> indeed deem it necessary to do so).
> 
> While hinting is, and should remain, optional, when it is used it should be 
> enforced. After all the user of my library has the option to dump it and go 
> for another library that does not force types. That is the beauty of having 
> options.
> 
> Tomi Kaistila
> PHP Developer

---

## #34328 — Alain Williams — 2008-01-03T17:28:13+00:00

URL: https://externals.io/message/34325#34328 · In reply to: #34326

> 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 (eg string -> integer) when the
function is called; it then need not be converted again when it is used in
the function. This will presumably be a win if the value is used more than once.

-- 
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h

---

## #34329 — Tomi Kaistila — 2008-01-03T18:19:03+00:00

URL: https://externals.io/message/34325#34329 · In reply to: #34326

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, for the 
simple fact that they are ignore by a major portion of PHP developers and to 
use them would prompt a high risk of people writing bad code.

Also, now that you mentioned abstract classes, type hinting might also be 
useful with interfaces.

Tomi Kaistila
PHP Developer

On Thursday 03 January 2008 19:21:21 you wrote:
> 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 class that must
> return a certain type.
>
> class a {
> 	abstract public function getNumber() returns int ;
> }
> class b extends a {
> 	public function getNumber() {
> 		return `rand()` * 3463 ;
> 	}
> }
> class c extends a {
> 	public function getNumber() {
> 		return 'I\'m going to mess everything up by returning a string.' ; //
> Would cause error with type hinting.
> 	}
> }
>
> 
> > […]

---

## #34330 — Markus Fischer — 2008-01-03T18:36:48+00:00

URL: https://externals.io/message/34325#34330 · In reply to: #34328

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

Alain Williams wrote:
> 
> > […]
> 
> The other thing to note about type hinting is that it could result in faster code.
> The value is checked and if needed converted (eg string -> integer) when the
> function is called; it then need not be converted again when it is used in
> the function. This will presumably be a win if the value is used more than once.

I don't think that automagic conversion of types is a good idea.

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
according to the documentation but not always very intuitive. I sense a
possible small trap, and after all type hints should help developers get
code right and spot problems easier without less work.

PHP supports explicit casting and that should be used for that. Because
if this results in a problem alter in the code you know who to blame:
yourself, and not the automagic behavior of PHP.

my 2c,
- - Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHfStA1nS0RcInK9ARAu/dAKDNOMC7M1X8CyrjyCrpzt0/oiLsCgCg2YSY
YAUYre0HTc3dLxsbHTu7+Ik=
=KXMz
-----END PGP SIGNATURE

---

## #34331 — Stanislav Malyshev — 2008-01-03T18:43:39+00:00

URL: https://externals.io/message/34325#34331 · In reply to: #34330

> 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
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #34332 — Jochem Maas — 2008-01-03T18:49:53+00:00

URL: https://externals.io/message/34325#34332 · In reply to: #34329

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 it usually
means the white page of death for a site visitor)

 `E_WARNING` also is not much better given that one would assume the function/method
that was passed incorrect variables (according to type) wouldn't run.

would an exception not be the most suitable thing to generate on a typehint error?
to me anything else makes typehinting in production environments pretty much unusable
unless one write code like so:

function foo(Foo $f) { /* do foo stuff */ }

$f = getFoo();
if ($f instanceof Foo) {
	foo($f);
}

now the issue with such code is not that it is alot more verbose than might
strictly be needed but that the instanceof statement makes the typehint rather
superfluous.



Tomi Kaistila schreef:
> 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, for the 
> simple fact that they are ignore by a major portion of PHP developers and to 
> use them would prompt a high risk of people writing bad code.
> 
> Also, now that you mentioned abstract classes, type hinting might also be 
> useful with interfaces.
> 
> Tomi Kaistila
> PHP Developer
> 
> On Thursday 03 January 2008 19:21:21 you wrote:
> > […]

---

## #34334 — Sam Barrow — 2008-01-03T18:54:24+00:00

URL: https://externals.io/message/34325#34334 · In reply to: #34332

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.


> 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 it usually
> means the white page of death for a site visitor)
> 
> `E_WARNING` also is not much better given that one would assume the function/method
> that was passed incorrect variables (according to type) wouldn't run.
> 
> would an exception not be the most suitable thing to generate on a typehint error?
> to me anything else makes typehinting in production environments pretty much unusable
> unless one write code like so:
> 
> function foo(Foo $f) { /* do foo stuff */ }
> 
> $f = getFoo();
> if ($f instanceof Foo) {
> 	foo($f);
> }
> 
> now the issue with such code is not that it is alot more verbose than might
> strictly be needed but that the instanceof statement makes the typehint rather
> superfluous.
> 
> 
> 
> Tomi Kaistila schreef:
> > […]

---

## #34335 — Markus Fischer — 2008-01-03T19:00:51+00:00

URL: https://externals.io/message/34325#34335 · In reply to: #34331

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Stanislav Malyshev wrote:
> > […]
> 
> Why people that want Java just don't use Java I wonder? PHP never was a
> strict static typed language.

I can't answer you that one :) I want PHP and not Java. Yet I would like
to have type hinting. Don't see a conflict here.

But with the current situation it feels very awkward. We get class and
array type hints but not the other scalar types?! :-/

- - Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHfTDj1nS0RcInK9ARAqL3AJsFeFxW/m+xonir+ukKEtOHU/m/WQCfetSx
wvy6jLFuSclijBClsADGG+8=
=8Lwh
-----END PGP SIGNATURE

---

## #34336 — Stanislav Malyshev — 2008-01-03T19:09:33+00:00

URL: https://externals.io/message/34325#34336 · In reply to: #34335

> 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
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #34337 — Markus Fischer — 2008-01-03T19:21:02+00:00

URL: https://externals.io/message/34325#34337 · In reply to: #34336

-----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:
> > […]
> 
> Arrays and objects aren't scalar types, so "other" scalar types are in
> fact all on them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHfTWe1nS0RcInK9ARAvlJAKCvC5rcQ1je1wbnht3GCacQ7E5HoQCgq/Ix
H9GKXUubMQupLwhx1icukFM=
=jQSH
-----END PGP SIGNATURE

---

## #34338 — Derick Rethans — 2008-01-03T19:23:32+00:00

URL: https://externals.io/message/34325#34338 · In reply to: #34331

> > […]
> 
> Why people that want Java just don't use Java I wonder? PHP never was a strict
> static typed language.

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* add it? (And yes, I changed my mind)

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

---

## #34339 — Sam Barrow — 2008-01-03T19:38:42+00:00

URL: https://externals.io/message/34325#34339 · In reply to: #34338

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".


> 
> 
> > […]
> 
> 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* add it? (And yes, I changed my mind)
> 
> regards,
> Derick
> 
> -- 
> Derick Rethans
> http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

---

## #34343 — Derick Rethans — 2008-01-03T19:50:19+00:00

URL: https://externals.io/message/34325#34343 · In reply to: #34339

> 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 mailinglist.

-- 
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

---

## #34340 — Sam Barrow — 2008-01-03T19:52:28+00:00

URL: https://externals.io/message/34325#34340 · In reply to: #34338

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.

- Integers (specified by "int", "integer", or "long")
- Floats (specified by "float", "double", or "real")
- Numbers (matches integers and floats, specified by "num" or "number")
- Strings (specified by "string")
- Booleans (specified by "bool" or "boolean")
- Scalars (matches strings, booleans, and numbers; specified by
"scalar")
- Resources (specified by "resource")
- Objects (matches any object, specified by "object")

The patch specifies a constant, PATCH_SCALAR_TYPE_HINTING, just there to
indicate that the patch is installed.


> 
> 
> > […]
> 
> 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* add it? (And yes, I changed my mind)
> 
> regards,
> Derick
> 
> -- 
> Derick Rethans
> http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

---

## #34341 — Tomi Kaistila — 2008-01-03T20:01:24+00:00

URL: https://externals.io/message/34325#34341 · In reply to: #34338

> 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* add it? (And yes, I changed my mind)
Same here. I am getting generally tired of the attitude some 
politically-correct people seem to have about writing "javaish" code. What 
the heck is "javaish" code anyway? Most features that exist in both PHP and 
Java can also be found in myriad of other languages and it has so far not 
stopped the development team from adding a feature when it is clearly useful 
and (most importantly) desired an uncounted number of people.

In fact those who oppose the feature seem only capable of doing so with 
hair-splitting rhetorics.

> 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
In principle you are correct. But E_FATAL errors should not happen in a 
program that is in production use. If they do, it seems someone was not doing 
their job properly.

I am not convinced throwing an exception is the best course of action. If it 
was, you might make the argument that all errors should be exceptions, while 
traditionally it is the other way around and changing that is beyond the 
scope of this thread. I actually like the current "division of labor" when it 
comes to error handling.

When PHP detects an error, it should actually be an error. Exceptions are 
convenient for the code that you as a PHP developer can throw. They are 
especially a blessing when writing library code. That way exceptions work for 
the error management, instead of competing with it.

I say use `E_WARNING` at this stage. If there is some large redecorating with 
PHP's error handling in the future, it can be changed then.

Tomi Kaistila
PHP Developer

---

## #34342 — Sam Barrow — 2008-01-03T20:05:07+00:00

URL: https://externals.io/message/34325#34342 · In reply to: #34343

> 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 backwards compatibility and doesn't have a
major disadvantage for those who choose not to use it is almost always
good. In this case, it will benefit many, and to those who choose not to
use it, they will probably never even notice it's there.

So why not? Because it somehow goes against the ideology of some PHP
users? I'm sorry but I just don't see that as reason enough to throw
away something that could be very useful.

PHP is quickly moving from an easy to learn unprofessional scripting
language into an enterprise-level scalable language. Look at it's newer
enhanced XML capabilities, improved OO engine, and all of the
third-party integration libraries.

Finer-grained control over an application (which type hinting
contributes to) is something that fits the newer and better language
that PHP is becoming.

---

## #34344 — Sam Barrow — 2008-01-03T20:12:43+00:00

URL: https://externals.io/message/34325#34344 · In reply to: #34341

> > […]
> Java
> > […]
> is
> > […]
> few
> > […]
> should
> > […]
> Same here. I am getting generally tired of the attitude some 
> politically-correct people seem to have about writing "javaish" code. What 
> the heck is "javaish" code anyway? Most features that exist in both PHP and 
> Java can also be found in myriad of other languages and it has so far not 
> stopped the development team from adding a feature when it is clearly useful 
> and (most importantly) desired an uncounted number of people.
> 
> In fact those who oppose the feature seem only capable of doing so with 
> hair-splitting rhetorics.

Thank you, I've been thinking this stuff for a while now, ever since the
attitude I got when first introducing my patch. I'm glad some people
agree with me.

I don't care what my code looks like, and it's not written in some holy
PHP bible that PHP's one and only purpose of existence is to not be like
Java. If a good feature comes along, it should be evaluated on its pros
and cons, not whether or not it reminds us of Java or any other language
for that matter.

I'm sorry I just have no idea where people come up with this stuff. We
are supposed to be thinking technically and logically as we are all
obviously computer people, not like some Java-hating cult. The issue
seems incredibly simple to me, if there's a good feature and it's worth
adding, add it.

---

## #34345 — Sam Barrow — 2008-01-03T20:14:37+00:00

URL: https://externals.io/message/34325#34345

> 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?

---

## #34346 — Stanislav Malyshev — 2008-01-03T20:27:22+00:00

URL: https://externals.io/message/34325#34346 · In reply to: #34338

> 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 understand and handy to work with. 
Having both strict and non-strict typing in the same language does not 
seem like a good idea to me.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #34347 — Sam Barrow — 2008-01-03T20:35:31+00:00

URL: https://externals.io/message/34325#34347 · In reply to: #34346

> > […]
> should 
> > […]
> 
> 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 understand and handy to work with. 
> Having both strict and non-strict typing in the same language does not 
> seem like a good idea to me.

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
dynamic typing. I have numerous cases where I will have a type hinted
parameter and a non type hinted parameter in the same function. This way
we can have maximum flexibility where useful, but also control where
needed.

Keep in mind, this is not "strict typing" in its correct definition.
Strict typing allows very little room for type conversion. This is
optionally hinting the desired type of a function parameter.

---

## #34348 — Jochem Maas — 2008-01-03T20:37:19+00:00

URL: https://externals.io/message/34325#34348 · In reply to: #34341

Tomi Kaistila schreef:
> > […]
> Same here. I am getting generally tired of the attitude some 
> politically-correct people seem to have about writing "javaish" code. What 
> the heck is "javaish" code anyway? Most features that exist in both PHP and 
> Java can also be found in myriad of other languages and it has so far not 
> stopped the development team from adding a feature when it is clearly useful 
> and (most importantly) desired an uncounted number of people.
> 
> In fact those who oppose the feature seem only capable of doing so with 
> hair-splitting rhetorics.
> 
> > […]
> In principle you are correct. But E_FATAL errors should not happen in a 
> program that is in production use. If they do, it seems someone was not doing 
> their job properly.

you are right, they shouldn't - but who can say that every execution permutation has
been tested and hammered shut in their code (let alone someone else 3rd party lib or extension)?

in practice mistakes do occur - and saying someone has not been doing their job
properly is little consilation to the end user, client or manager (who gets a white screen of death) ...
there is no reason not to let the application try to gracefully handle a mistake
like this ... besides I was under the impression that E_FATAL meant the engine was
in an unstable state and was unable to continue execution - I don't see why a typehint
failure would cause an unstable engine state (rather the engine is presuming that
the code is *going* to create an unstable state if it were to continue ... which is
not very helpful in my book).

> 
> I am not convinced throwing an exception is the best course of action. If it 
> was, you might make the argument that all errors should be exceptions, while 
> traditionally it is the other way around and changing that is beyond the 
> scope of this thread. I actually like the current "division of labor" when it 
> comes to error handling.
> 
> When PHP detects an error, it should actually be an error. Exceptions are 
> convenient for the code that you as a PHP developer can throw. They are 
> especially a blessing when writing library code. That way exceptions work for 
> the error management, instead of competing with it.
> 
> I say use `E_WARNING` at this stage. If there is some large redecorating with 
> PHP's error handling in the future, it can be changed then.

that is a very sane arguement. I'll have to concede :-)

> 
> Tomi Kaistila
> PHP Developer

---

## #34349 — Pierre — 2008-01-03T20:40:25+00:00

URL: https://externals.io/message/34325#34349 · In reply to: #34338

> 
>
> > […]
>
> Broken record perhaps? I am getting a bit tired of this "just use Java
> argument", it's perhaps even a bit arrogant.

It is arrogant.

For what I see the strictness is making its way in php simply like OO
made it. First we resist (we all remember how hard it was to introduce
OO API to some extensions "why bloat it with OO?"). In doubts, we only
need to look at all the OO strictness we added in the past versions.
Please not that I use "we" for all php internals developers, as a
group (even if we all have different opinions, we reflect only one in
our releases).

> 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* add it? (And yes, I changed my mind)

Mines was always in favor of strictness for all types. As it is not
necessary to create clean code, it is a really nice addition to bring
PHP to yet another good level. Without talking about reducing the WTF
in some cases, especially when you have to work in teams with
developers not aware of PHP's "weirdness" (please don't tell me to ask
them to RTFM, that's off base).

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

---

## #34350 — Stanislav Malyshev — 2008-01-03T20:51:27+00:00

URL: https://externals.io/message/34325#34350 · In reply to: #34347

> 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 strict and non-strict code would be a nightmare. Absence of 
static type control (necessary for interpreted language) would make 
strictly typed code less, and not more stable. Add performance penalty 
from type checking and effort would be required from PHP newcomers to 
understand two code models instead of one - and you get the worst of 
both worlds, not the best.

> Strict typing allows very little room for type conversion. This is
> optionally hinting the desired type of a function parameter.

That's not what I am hearing here on the list.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

Next page: https://externals.io/message/34325.md?page=2