# Type hinting - Request for Discussion

- Thread: https://externals.io/message/44855
- Original archive: https://news-web.php.net/php.internals/44855
- Started by Zeev Suraski on 2009-07-09T07:47:41+00:00
- Messages: 48
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/44855.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

---

## #44855 — Zeev Suraski — 2009-07-09T07:47:41+00:00

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

All,

I think that we should revisit the options on the table.  I have a 
feeling that much like many people didn't realize they're voting to 
bring this into 5.3 - many weren't fully aware of the options on the 
table and their implications (to be clear - I'm sure some were, but I 
think many were not).

The options as I see them:

1.  Do nothing.  I think the vote established that this is not what 
people want.

2.  Move forward with the semantics of the current patch.  This 
approach has substantial drawbacks in my opinion, and is a strong 
misfit with the rest of PHP (again, in my opinion).  See previous 
posts from Stas, Rasmus, myself and maybe others illustrating this 
point.  Lukas's 'Strict and Weak Typing RFC' 
(http://wiki.php.net/rfc/typecheckingstrictandweak) has some good 
insight as to why strict typing is problematic in PHP.

3.  Implement 'weak' typing.  What does that mean?  Conversion rules 
will be very similar to those for internal functions, but slightly 
stricter (like I said, if we were to rewrite the conversion rules for 
internal functions today - we'd probably make them slightly stricter, 
too).  For example, if you denote that an argument is supposed to be 
an integer, then a string that looks like an integer (e.g. "17") 
would be silently converted to an integer, however, a string that 
does not look like an integer (e.g. "foo") will error out.  We need 
to come up with a complete pass/fail table, but that would be the 
theme.  Unlike option #2, this fits the rest of PHP quite well 
(except for minor inconsistencies with internal functions - but these 
are dwarfed in comparison to the inconsistencies of option #2).

Two other issues that we need to revisit:
1.  Agree on when it will be implemented - I think it's pretty clear 
it should not go to 5.3.
2.  Make sure people understand *why* we're implementing it - 
performance is certainly *not* the reason.

Before moving ahead with votes or committing the code, I suggest we 
focus on the pros & cons of options #2 and #3.  Since the 
inconsistencies introduced by option #2 are very substantial (between 
internal and userland functions, and also how values behave in PHP in 
general), I suggest we focus on use cases where option #2 would be 
truly needed and superior to option #3.  In other words - what is the 
added value and is it worth the price?

I think we can take Lukas's RFC and either change it or write 
something based on it for weak typing only.  If people here find it 
useful I'll go ahead and do that.

Zeev

---

## #44856 — Paul Biggar — 2009-07-09T08:39:59+00:00

URL: https://externals.io/message/44855#44856 · In reply to: #44855

Hi Zeev,

I've been keeping a very close eye, and have taken part in a good few
discussions, including putting my own idea on the table.


> The options as I see them:
>
> 1.  Do nothing.  I think the vote established that this is not what people
> want.

Agreed.


> 2.  Move forward with the semantics of the current patch.  This approach has
> substantial drawbacks in my opinion, and is a strong misfit with the rest of
> PHP (again, in my opinion).  See previous posts from Stas, Rasmus, myself
> and maybe others illustrating this point.  Lukas's 'Strict and Weak Typing
> RFC' (http://wiki.php.net/rfc/typecheckingstrictandweak) has some good
> insight as to why strict typing is problematic in PHP.

I believe nearly all opinions voiced have wanted the current patch.
Many more were in favour of strict typing only, but for the few
dissenters, like myself, Ilia included casting semantics using (int)
syntax.

There are I think maybe 5 or 6 people who have expressed opinions
against this. All others have been pro (I'm not counting the vote
here, I'm looking at discussions).


> 3.  Implement 'weak' typing.  What does that mean?  Conversion rules will be
> very similar to those for internal functions, but slightly stricter (like I
> said, if we were to rewrite the conversion rules for internal functions
> today - we'd probably make them slightly stricter, too).  For example, if
> you denote that an argument is supposed to be an integer, then a string that
> looks like an integer (e.g. "17") would be silently converted to an integer,
> however, a string that does not look like an integer (e.g. "foo") will error
> out.  We need to come up with a complete pass/fail table, but that would be
> the theme.  Unlike option #2, this fits the rest of PHP quite well (except
> for minor inconsistencies with internal functions - but these are dwarfed in
> comparison to the inconsistencies of option #2).

This seems like a good idea, but others disagree. I wrote a set of
rules for this, which are very much how you describe them: slightly
stricter than casting, but weaker than strict typing. In the
discussion, there was very little support, and so I withdrew it.


> Two other issues that we need to revisit:
> 1.  Agree on when it will be implemented - I think it's pretty clear it
> should not go to 5.3.

The last discussion certainly made this clear. It should be cleared up
whether people want this is 5.4 (if it happens). I think its
established that people want this in 6.


> 2.  Make sure people understand *why* we're implementing it - performance is
> certainly *not* the reason.

I believe there was only two misguided souls who believed this would
lead to better performance. Everyone else wanted it on its merits.


> Before moving ahead with votes or committing the code, I suggest we focus on
> the pros & cons of options #2 and #3.  Since the inconsistencies introduced
> by option #2 are very substantial (between internal and userland functions,
> and also how values behave in PHP in general), I suggest we focus on use
> cases where option #2 would be truly needed and superior to option #3.  In
> other words - what is the added value and is it worth the price?

It doesnt sound like you are aware of the casting semantics that Ilia
added. They are largely consistent with the internal function
semantics.

function x (int x) { /* fail on non-int */ }
function x ((int) x) { /* cast parameter to an int */ } // just like
internals functions

Indeed this adds the ability to make your function work like an
internals function (useful perhaps for library interfaces).


> I think we can take Lukas's RFC and either change it or write something
> based on it for weak typing only.  If people here find it useful I'll go
> ahead and do that.

I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC, and neither got anything like the support that strict typing
got.

One large problem is that it introduced a new 3rd set of rules, and
this set is not intuitive but rather slightly subjective (reasonable
people might disagree on whether a bool should be weakly converted to
an int, for example). The strict type checks are at least simple, and
the current weak ones are what people are used to.


Obviously I'm not against discussion, but we just had this discussion.


Thanks,
Paul



-- 
Paul Biggar
paul.biggar@gmail.com

---

## #44858 — Zeev Suraski — 2009-07-09T09:46:28+00:00

URL: https://externals.io/message/44855#44858 · In reply to: #44856

At 11:39 09/07/2009, Paul Biggar wrote:
>I believe nearly all opinions voiced have wanted the current patch.
>Many more were in favour of strict typing only, but for the few
>dissenters, like myself, Ilia included casting semantics using (int)
>syntax.

I think that many of the people who expressed 
support for that patch did not fully realize its 
implications - much in the same way they weren't 
quite realizing they're actually voting for 
inclusion in PHP 5.3.  I believe that if we had a 
'clean' Weak typing RFC as well as a Strict 
typing RFC, each with its pros and cons - there 
would be very different results.

>There are I think maybe 5 or 6 people who have expressed opinions
>against this. All others have been pro (I'm not counting the vote
>here, I'm looking at discussions).

I think you're right, but I also think it had to 
do with dynamics more than with actual content.
The two approaches were never compared 
head-to-head, with the pros and cons - and more 
importantly - with use cases on why strict typing 
is necessary despite the fact it's fairly 'alien' to PHP.

> > […]
> implementing it - performance is
> > […]
>
>I believe there was only two misguided souls who believed this would
>lead to better performance. Everyone else wanted it on its merits.

Maybe - but the only way to make sure is to make it a clear part of the RFC(s).

>It doesnt sound like you are aware of the casting semantics that Ilia
>added. They are largely consistent with the internal function
>semantics.
>
>function x (int x) { /* fail on non-int */ }
>function x ((int) x) { /* cast parameter to an int */ } // just like
>internals functions

I am - and I think I like this even less than 
pure strict typing because of increased WTF factor.
I think strict typing is wrong for PHP, and this 
cannot be fixed by also adding something 
else.  The way to 'fix' this is by not adding 
strict typing, and adding only weak typing.

>Indeed this adds the ability to make your function work like an
>internals function (useful perhaps for library interfaces).

If improved with slightly more intrusive checks 
(like the ones suggested in my email) - then it 
can be useful in mostly all of the places where strict typing would be used.

> > […]
>
>I believe people don't want this. I wrote a set of rules, Lukas wrote
>the RFC, and neither got anything like the support that strict typing
>got.

This could be for a variety of reasons - one of 
them is that people truly thought this through 
and truly prefer strict typing to weak 
typing.  But that is just one of the 
options.  Another is that the difference between 
the two approaches, as well as the issues with 
strict typing - aren't fully understood by the 
audience - and I believe that this is actually the case.

>One large problem is that it introduced a new 3rd set of rules, and
>this set is not intuitive but rather slightly subjective (reasonable
>people might disagree on whether a bool should be weakly converted to
>an int, for example). The strict type checks are at least simple, and
>the current weak ones are what people are used to.

I definitely don't think we should add two new 
semantics.  Ideally we shouldn't add any 
entirely-new semantics, and what I'm proposing is 
to actually reuse the existing semantics for 
internal functions - with very minor 
modifications.  Kind of like Semantics and 
Semantics', rather than Sematnics1, Semantics2, Semantics3.

>Obviously I'm not against discussion, but we just had this discussion.

Given the implications of introducing something 
like that (that can easily grow in the future to 
other parts of PHP) - and my belief that the 
discussion missed key ingredients, we should discuss it further.

We need to go back to the fundamentals - and look 
for use cases where strict typing would be 
substantially superior to weak typing.  As far as 
reflection, code readability, optimization and 
security is concerned - I can't find any 
superiority, but maybe I'm missing something.  We 
already have an RFC that details the 
disadvantages of strict typing (Lukas's 
RFC).  Let's focus on the advantages and see if they're worth it?

Zeev

---

## #44859 — Paul Biggar — 2009-07-09T10:18:18+00:00

URL: https://externals.io/message/44855#44859 · In reply to: #44858

> I believe that
> if we had a 'clean' Weak typing RFC as well as a Strict typing RFC, each
> with its pros and cons - there would be very different results.
>
> The two approaches were never compared head-to-head, with the pros and cons
>
> Another is that the difference between the
> two approaches, as well as the issues with strict typing - aren't fully
> understood by the audience - and I believe that this is actually the case.
>
> the
> discussion missed key ingredients, we should discuss it further.

I think you are right that the discussions weren't sufficiently clear,
and this could be resolved by better RFCs. This is obviously how it
should have been done in the first place (look at the success of
Python's PEPs).

I'm not sure this will change things, and worry it might derail what
we have now, but those are not good reasons to stop the discussion.


Thanks,
Paul


-- 
Paul Biggar
paul.biggar@gmail.com

---

## #44860 — Dennis Haarbrink — 2009-07-09T10:49:44+00:00

URL: https://externals.io/message/44855#44860 · In reply to: #44858

> -----Oorspronkelijk bericht-----
> Van: Zeev Suraski [mailto:zeev@zend.com]
> Verzonden: donderdag 9 juli 2009 11:46
> Aan: Paul Biggar
> CC: internals@lists.php.net
> Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
> 
> At 11:39 09/07/2009, Paul Biggar wrote:
> > […]
> 
> I think that many of the people who expressed
> support for that patch did not fully realize its
> implications - much in the same way they weren't
> quite realizing they're actually voting for
> inclusion in PHP 5.3.  I believe that if we had a
> 'clean' Weak typing RFC as well as a Strict
> typing RFC, each with its pros and cons - there
> would be very different results.
> 
> > […]
> 
> I think you're right, but I also think it had to
> do with dynamics more than with actual content.
> The two approaches were never compared
> head-to-head, with the pros and cons - and more
> importantly - with use cases on why strict typing
> is necessary despite the fact it's fairly 'alien' to PHP.
> 
> > […]
> 
> Maybe - but the only way to make sure is to make it a clear part of the
> RFC(s).
> 
> > […]
> 
> I am - and I think I like this even less than
> pure strict typing because of increased WTF factor.
> I think strict typing is wrong for PHP, and this
> cannot be fixed by also adding something
> else.  The way to 'fix' this is by not adding
> strict typing, and adding only weak typing.
> 
> > […]
> 
> If improved with slightly more intrusive checks
> (like the ones suggested in my email) - then it
> can be useful in mostly all of the places where strict typing would be
> used.
> 
> > […]
> something
> > […]
> I'll go
> > […]
> 
> This could be for a variety of reasons - one of
> them is that people truly thought this through
> and truly prefer strict typing to weak
> typing.  But that is just one of the
> options.  Another is that the difference between
> the two approaches, as well as the issues with
> strict typing - aren't fully understood by the
> audience - and I believe that this is actually the case.
> 
> > […]
> 
> I definitely don't think we should add two new
> semantics.  Ideally we shouldn't add any
> entirely-new semantics, and what I'm proposing is
> to actually reuse the existing semantics for
> internal functions - with very minor
> modifications.  Kind of like Semantics and
> Semantics', rather than Sematnics1, Semantics2, Semantics3.
> 
> > […]
> 
> Given the implications of introducing something
> like that (that can easily grow in the future to
> other parts of PHP) - and my belief that the
> discussion missed key ingredients, we should discuss it further.
> 
> We need to go back to the fundamentals - and look
> for use cases where strict typing would be
> substantially superior to weak typing.  As far as
> reflection, code readability, optimization and
> security is concerned - I can't find any
> superiority, but maybe I'm missing something.  We
> already have an RFC that details the
> disadvantages of strict typing (Lukas's
> RFC).  Let's focus on the advantages and see if they're worth it?
> 
> Zeev
> 



I am a long time (passive) list reader but seeing the direction of this
discussion makes me feel obligated to express my opinion.

I'm a framework developer and I have great interest in type hinting/casting.
I'm all for clarity and strictness, but it should definitely be a choice.
PHP is known for its easy learning curve, that is one of its big powers and
that should remain unchanged. But the way I see it is that it can be
implemented without *requiring* you to use it, if you want to use type
hinting/casting go ahead, if you don't want it, well, leave that bit alone.
If it comes with a minor performance hit, OK, i can live with that, I agree
with Lukas in that aspect, you don't spend lots of time checking/casting
anyway.
As for hinting/casting would not be 'php-ish', i don't see it that way, i
look at php as a language of possibilities, not restrictions.

As  I said, i'm a framework developer and it would greatly improve
readability, usability and quality when you can use type hinting/casting.
Consider a pretty common architecture where you have a service layer which
does validation and stuff and then passes control to 'deeper' parts in the
framework. Your service layer could have a casting hint, while the more
inner components could have a strict hint. There you can trust the data is
of the type you wanted, otherwise there is something wrong anyway.

The most important thing is that it is _optional_, you have the _choice_ to
use it.
Regarding syntax, to me it is totally intuitive that foo((int) $bar) tries
to do a cast and foo(int $bar) is strict, it's also easy to explain to
students, put parenthesis around your type name and it's a cast, whether it
is in an assignment or a method declaration it doesn't matter.

Seeing the discussion I think there is consensus it shouldn't be in 5.3. I
think it shouldn't be in 5.x total, the 5.x branch is already _loaded_ with
lots of new cool stuff and in my opinion all focus should be on getting a
6.0 release asap.

I know, i'm 'just' a php user but maybe I can inspire someone in taking the
'right' course.

Regards,
Dennis Haarbrink

---

## #44862 — Paul Biggar — 2009-07-09T11:02:53+00:00

URL: https://externals.io/message/44855#44862 · In reply to: #44860

Hi Dennis,


> The most important thing is that it is _optional_, you have the _choice_ to
> use it.

Sorry to go a little bit off-topic, but this idea has been bandied
around a lot over the last week, and I'd like to respond to it.

Although the proposed checks are optional, nobody has a "_choice_" to
use a new language feature. Though you may choose not to use a feature
in your code for whatever reason, it will appear in code from your
colleagues, clients, or upstream libraries. Every feature in PHP will
at some point be put in front of every PHP developer.

As a result, the argument that "you dont like it, so what, you have a
choice not to use it", is simply incorrect. Though at some point the
majority may have to overrule the views of the minority, please do not
dismiss them out of hand with this logic.


Thanks,
Paul

-- 
Paul Biggar
paul.biggar@gmail.com

---

## #44863 — Patrick ALLAERT — 2009-07-09T11:10:33+00:00

URL: https://externals.io/message/44855#44863 · In reply to: #44855

2009/7/9 Zeev Suraski <zeev@zend.com>:
> Two other issues that we need to revisit:
> 1.  Agree on when it will be implemented - I think it's pretty clear it
> should not go to 5.3.

What would be the impact including this feature (once it is
*technically* fine for everybody) in 5.3 code with #ifdef's so that
this feature is enabled only at ./configure time and disabled by
default.

We could then imagine to switch this configure parameter as enabled by
default in a future (major) release.

This way, every vanilla PHP installation wouldn't suffer of BC
problems while still providing the feature to a restricted set of
users.

-- 
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor

---

## #44864 — Lukas Kahwe Smith — 2009-07-09T11:59:43+00:00

URL: https://externals.io/message/44855#44864 · In reply to: #44863

> 2009/7/9 Zeev Suraski <zeev@zend.com>:
> > […]
>
> What would be the impact including this feature (once it is
> *technically* fine for everybody) in 5.3 code with #ifdef's so that
> this feature is enabled only at ./configure time and disabled by
> default.
>
> We could then imagine to switch this configure parameter as enabled by
> default in a future (major) release.
>
> This way, every vanilla PHP installation wouldn't suffer of BC
> problems while still providing the feature to a restricted set of
> users.


thats a no go, since this would lead to incompatible PHP code. we have  
had various php.ini settings that have caused this and we do not want  
to pile onto this.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #44865 — Lukas Kahwe Smith — 2009-07-09T12:00:59+00:00

URL: https://externals.io/message/44855#44865 · In reply to: #44860

> I'm a framework developer and I have great interest in type hinting/ 
> casting.
> I'm all for clarity and strictness, but it should definitely be a  
> choice.
> PHP is known for its easy learning curve, that is one of its big  
> powers and
> that should remain unchanged. But the way I see it is that it can be
> implemented without *requiring* you to use it, if you want to use type
> hinting/casting go ahead, if you don't want it, well, leave that bit  
> alone.
> If it comes with a minor performance hit, OK, i can live with that,  
> I agree
> with Lukas in that aspect, you don't spend lots of time checking/ 
> casting
> anyway.
> As for hinting/casting would not be 'php-ish', i don't see it that  
> way, i
> look at php as a language of possibilities, not restrictions.

I think you misunderstood Zeev. He wasn't saying that this feature is  
not PHP-ish, he was specifically talking about "strict" type checking.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #44866 — Dennis Haarbrink — 2009-07-09T12:33:39+00:00

URL: https://externals.io/message/44855#44866 · In reply to: #44862

Hi Paul,


> -----Oorspronkelijk bericht-----
> Van: Paul Biggar [mailto:paul.biggar@gmail.com]
> Verzonden: donderdag 9 juli 2009 13:03
> Aan: Dennis Haarbrink
> CC: internals@lists.php.net
> Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
> 
 
> Although the proposed checks are optional, nobody has a "_choice_" to
> use a new language feature. Though you may choose not to use a feature
> in your code for whatever reason, it will appear in code from your
> colleagues, clients, or upstream libraries. Every feature in PHP will
> at some point be put in front of every PHP developer.
> 


I don't think this is a really valid argument.
I mean, libraries may have all kinds of quirks, you may not be satisfied with the supplied API or maybe even the entire philosophy behind it, but that shouldn't stop you from using it or is it?



Regards,
Dennis Haarbrink

---

## #44867 — Paul Biggar — 2009-07-09T12:39:43+00:00

URL: https://externals.io/message/44855#44867 · In reply to: #44866

> I mean, libraries may have all kinds of quirks, you may not be satisfied with the supplied API or maybe even the entire philosophy behind it, but that shouldn't stop you from using it or is it?

You must learn what these quirks are. Likewise, every developer must
learn the quirks of the "type hinting" as they will almost certainly
be required to interact with code that uses it.

In an extreme case, suppose that we completely balls-ed up the
semantics of type checks to be really really hard to use, but people
used them anyway. That would lead to a sharp learning curve. The
people who are against this proposal, or any other, know they will be
required to use it when it comes in, and have an interest in making
sure it is clean (whatever that means in each case). We shouldn't
dismiss their objections on the argument that they arent required to
use it. If its in the language, they are required to learn it.

Paul



-- 
Paul Biggar
paul.biggar@gmail.com

---

## #44868 — Christian Schneider — 2009-07-09T12:41:19+00:00

URL: https://externals.io/message/44855#44868 · In reply to: #44858

Zeev Suraski wrote:
> We need to go back to the fundamentals - and look for use cases where
> strict typing would be substantially superior to weak typing.

I whole-heartedly agree. I can see some benefits of having weak typing
(even though I'm not desperate for it) and think it would better fit PHP
than strict typing.

If someone brings up real world use cases for strict typing then please
not only include the function being called but also the calling code as
in my experience that's where the type juggling will happen once you
have strict typing. And that's where weak typing could shine IMHO.

Regards,
- Chris

---

## #44869 — Dennis Haarbrink — 2009-07-09T12:46:47+00:00

URL: https://externals.io/message/44855#44869 · In reply to: #44865

Lukas,

> -----Oorspronkelijk bericht-----
> Van: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
> Verzonden: donderdag 9 juli 2009 14:01
> Aan: Dennis Haarbrink
> CC: internals@lists.php.net
> Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
> 
> 
> 
> I think you misunderstood Zeev. He wasn't saying that this feature is
> not PHP-ish, he was specifically talking about "strict" type checking.
> 
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org
> 
> 



Although I replied to Zeev's message it was more of a general observation
than directly aimed at him.


Regards,
Dennis

---

## #44870 — Dennis Haarbrink — 2009-07-09T13:02:57+00:00

URL: https://externals.io/message/44855#44870 · In reply to: #44867

> -----Oorspronkelijk bericht-----
> Van: Paul Biggar [mailto:paul.biggar@gmail.com]
> Verzonden: donderdag 9 juli 2009 14:40
> Aan: Dennis Haarbrink
> CC: internals@lists.php.net
> Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
> 
> You must learn what these quirks are. Likewise, every developer must
> learn the quirks of the "type hinting" as they will almost certainly
> be required to interact with code that uses it.
> 
> In an extreme case, suppose that we completely balls-ed up the
> semantics of type checks to be really really hard to use, but people
> used them anyway. That would lead to a sharp learning curve. The
> people who are against this proposal, or any other, know they will be
> required to use it when it comes in, and have an interest in making
> sure it is clean (whatever that means in each case). We shouldn't
> dismiss their objections on the argument that they arent required to
> use it. If its in the language, they are required to learn it.
> 
> Paul
> 
> 
> 
> --
> Paul Biggar
> paul.biggar@gmail.com



Thanks for this elaboration, I totally see your point.


Regards,
Dennis Haarbrink

---

## #44874 — Lukas Kahwe Smith — 2009-07-09T16:20:08+00:00

URL: https://externals.io/message/44855#44874 · In reply to: #44856

> > […]
>
> I believe people don't want this. I wrote a set of rules, Lukas wrote
> the RFC, and neither got anything like the support that strict typing
> got.


Actually, in terms of weak typing we are now at 4 supporters of the  
general idea:
Paul B.,
Lukas,
Zeev,
Christian S.

Still a minority compared to the +1 votes for Ilia's strict typing  
proposal. Though it could be argued that a fair number only voted for  
the expansion of type hinting to scalar datatypes and did not really  
look into the entire strict vs. weak hinting stuff.

regards
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #44875 — Paul Biggar — 2009-07-09T16:32:17+00:00

URL: https://externals.io/message/44855#44875 · In reply to: #44874

> Actually, in terms of weak typing we are now at 4 supporters of the general
> idea:
> Paul B.,

Better make that 3 supporters. After seeing how complicated it was to
explain the semantics of a "sensible middle", I think the patch that
Ilia currently has is close to ideal (the strict semantics are trivial
to understand, the weak ones are the same as whats already here).
Naturally, I might change my position upon seeing the new RFCs.

Paul


-- 
Paul Biggar
paul.biggar@gmail.com

---

## #44876 — Stan Vassilev — 2009-07-09T17:03:56+00:00

URL: https://externals.io/message/44855#44876 · In reply to: #44875

I want to remind everyone that this discussion is inadvertently sabotaging 
the work/schedule of maintenance 5.3.x point releases, which we actually 
need, for the 5.3 branch get to a point where it's stable enough to be used 
in production.

So, knowing this can go on forever, it's time to pick which you want first:

A) Stable 5.3 with namespaces, closures, late static binding, phar, SPL 
additions and more (essential brand new functionality, feature complete, 
only needs bug fixes).

B) Strict type casts/hints (shortcut for existing is_*() / cast 
functionality).

Regards,
Stan Vassilev

---

## #44878 — troels knak-nielsen — 2009-07-09T18:50:07+00:00

URL: https://externals.io/message/44855#44878 · In reply to: #44876

Hi list.

In advance, sorry for muddying the waters even further.

Following the current discussion about typehints to primitives, I'm
wondering if anyone have ever suggested to include some sort of
user-land contract system, such as the one that exists in
plt-scheme[1]

Given the dynamic nature of php, I would suspect that it might be a
much better fit. Unlike the semi-static typecheck that typehints can
give, a contract system would be much more expressive and would add a
lot more value (in my opinion anyway).

I think part of the reason for the popularity of typehints is that it
looks familiar for people coming from Java/C++/C#. The biggest
challenge for such a contract system would then be to come up with
something that doesn't look too alien. A simple way that I can think
of is to overload the meaning of typehints so that they may either
denote a class/interface (as they work currently) OR they may be a
function which takes the variable as argument and yields a boolean.
Eg.:

    function array_of_numeric($x) {
      foreach ($x as $val) {
        if (!is_numeric($val)) {
          return false;
        }
      }
      return true;
    }

    class Foo {
      /** Example use-case for a contract */
      function sum(array_of_numeric $a) {
        return array_sum($a);
      }
    }

This is just one suggestion - There are other ways to implement the concept.

I can see a number of benefits to a contract system over the currently
discussed typehint system:

1) It covers all the use cases for a type-based system (You can use
`is_integer` as a contract, if you want that)
2) It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs.
3) It's focused on the interface of input-parameters, rather than their type.

[1] http://docs.plt-scheme.org/guide/contracts.html

--
troels

---

## #44879 — Geoffrey Sneddon — 2009-07-09T19:11:31+00:00

URL: https://externals.io/message/44855#44879 · In reply to: #44874

>
> 
>
> > […]
>
>
> Actually, in terms of weak typing we are now at 4 supporters of the  
> general idea:
> Paul B.,
> Lukas,
> Zeev,
> Christian S.

As I said in the other thread, I'm in favour of weak typing (and  
against strict typing).

-g

---

## #44883 — Stanislav Malyshev — 2009-07-09T19:22:51+00:00

URL: https://externals.io/message/44855#44883 · In reply to: #44874

Hi!

> Actually, in terms of weak typing we are now at 4 supporters of the 
> general idea:

Count me in, then :)
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #44885 — Guillaume Rossolini — 2009-07-09T22:07:50+00:00

URL: https://externals.io/message/44855#44885 · In reply to: #44855

Hi!
I am a userland developer, so please take my advice with caution.  I am not
aware of the consequences of any of the implementations from an internals
point of view.  However, since the main question here seems to be strict
against weak typing, or casting, I feel I should voice my opinion.

From a user perspective, I feel that PHP does a very good job at casting
variables if needed.  One should take care not to do anything stupid but
heh, that's programming...  I therefore think using rules similar to the
casting rules is a good suggestion.  It is easy to understand, easy to use
as a library developer and mostly, it is very easy to use for library users
(no change is needed to their code).

A function might look like this in PHP <= 5.3.0:
function foo ($x) {
   return $x + 5; // hoping the user sends a numeric value, else the results
will be silently wrong
}

It could be used like this:
foo(5); // ok
foo('hello'); // wrong but no error
foo(fopen('hello')); // wrong but no error
foo(new CustomClass()); // wrong but no error

Or it could be written to check the type of the parameter:
function foo ($x) {
   $y = (float) $x; // explicit cast
   return $y + 5; // we know what type we have so we know the operation is
safe, we don't need any errors to be shown
}

The problem, as everyone is well aware, is that we need either to change the
value of $x (which I believe is bad practice) or to have a copy of $x cast
into $y, which of course means performance decrease and increased memory
consumption.


So, we all agree PHP should provide means to help developers simplify the
validation chain: type hinting (ie. telling the developer the parameters
should be converted before calling the function) or casting (ie. following
specific rules to cast to the right type).


With strong type hinting, the function would become:
function foo (float $x) { // if the user does not send a float value, the
function fails
   echo $x + 5;
}

It could be used like this:
foo(5); // some kind of explicit error
foo((float) 5); // ok
foo(5.0); // ok
foo('hello'); // some kind of explicit error
foo((float) 'hello'); // wrong but that much is plain
foo(fopen('hello')); // some kind of explicit error
foo((float) fopen('hello')); // wrong but that much is plain
foo(new CustomClass()); // some kind of explicit error
foo((float) new CustomClass()); // wrong but that much is plain


We all agree, I hope, that this makes userland code very ugly, not to
mention very repetitive. Each time I call foo(), PHP would make me write a
manual cast on the parameters every time I call the function.  I am quite
sure it helps to make the code a lot safer, but this is not at all what PHP
developers are used to do. And it would *not* help PHP's fame.  To a user,
that would make PHP close to C or C++, but without the good performance.  I
can see very little gain here.

Here is another example:
foo($var);

If I am not sure what type $var is at the time I call foo(), because this is
PHP and I have never had to worry about it before, strong type hinting would
have me do this:
foo((float) $var);

If I did that, my users would simply drop my libraries because they would
not appear to be written in PHP.  Not the PHP they like, anyway.  After all,
why would my libraries refuse an integer value when they expect a float?
 And of course, PHP already has internal rules to convert several types to
others.  Why not use that?

So, let's take a user point of view.  As such, I defnitely would like to be
able to call my function foo() without any explicit casting every time I
need the function, under the threat that I would have errors when PHP should
already be able to cast the parameters.

foo(5); // ok
foo('hello'); // ok, empty
foo(fopen('hello')); // ok, could be empty or cast to: "0" for error, "1"
otherwise (like booleans in other languages)
foo(new CustomClass()); // ok, empty or maybe a handler can be set to
automatically cast in this case?

Of course, these are set values.  Day to day programming does not always
involve hard-coded values like this but rather user-supplied values, ie.
mostly text values.  I my experience, most of the time text values are easy
to cast to other types.  I think this is why type hinting/casting could be
of great help.

Maybe a nice addition would be a specific error level so that I could see
where in my code these silent castings should take place.  Or where they do
take place.  Or neither.

foo($bar); // throws an error only if error_level is set to E_HINT


Bottom line: As a user of libraries, I see no good in strong hint typing.
 However, as a library developer I see uses for it.


Best regards,

--
Guillaume Rossolini

---

## #44886 — Josh Thompson — 2009-07-10T00:28:35+00:00

URL: https://externals.io/message/44855#44886 · In reply to: #44878

troels knak-nielsen wrote:
> 1) It covers all the use cases for a type-based system (You can use
> `is_integer` as a contract, if you want that)
> 2) It's extensible in user-space, which means that it can be used to
> convey much more accurate information, relevant to the application
> needs.
> 3) It's focused on the interface of input-parameters, rather than their type.

This is my favorite alternative so far. There are just a few problems 
with parsing as I see it.

  - How do you know if it is a contract or the current object type hint?
  - It doesn't allow a type to be forced (casted) to the correct type.

To address these items, I suggest the following changes.

Change the syntax of the contract to look like a function call (which is 
essentially what we are doing):

   <?php
   function array_of_numeric($x)
   {
       if (!is_array($x)) {
           return false;
       }
       foreach ($x as $val) {
           if (!is_numeric($val)) {
               return false;
           }
       }
       return true;
   }

   function sum(array_of_numeric($a)) {
       return array_sum($a);
   }

This could even be extended to allow for more generic types by allowing 
constant parameters for the contract:

   <?php
   function array_of($x, $type)
   {
       if (!is_array($x)) {
           return false;
       }
       switch ($type) {
           case 'int':
               $check = 'is_int';
               break;
           case 'float':
               $check = 'is_float';
               break;
           case 'numeric':
               $check = 'is_numeric';
               break;
           case 'string':
               $check = 'is_string';
               break;
           case 'bool':
               $check = 'is_bool';
               break;
           default:
               return false;
       }
       foreach ($x as $val) {
           if (!$check($val)) {
               return false;
           }
       }
       return true;
   }

   function sum(array_of($a, 'numeric')) {
       return array_sum($a);
   }

To allow for casting, the contract function could take the value by 
reference and cast it:

   <?php
   function array_of_float(&$x)
   {
       if (!is_array($x)) {
           return false;
       }
       foreach ($x as $key => $val) {
           if (!is_numeric($val)) {
               return false;
           }
           $x[$key] = (float)$val;
       }
       return true;
   }

   function sum(array_of_float($a)) {
       return array_sum($a);
   }

-- 
Joshua Thompson
Mechanical Engineer/Software Developer
http://www.schmalls.com

---

## #44887 — troels knak-nielsen — 2009-07-10T00:44:52+00:00

URL: https://externals.io/message/44855#44887 · In reply to: #44886

On Fri, Jul 10, 2009 at 2:28 AM, Josh
Thompson<spam.goes.in.here@gmail.com> wrote:
> troels knak-nielsen wrote:
>  - How do you know if it is a contract or the current object type hint?

The simplest solution would be to make one take precedence. You're not
likely to have both a class and a function with the same name, and if
you do, you kind of had it coming to you. For backwards compatibility
it would probably be most fitting to let the current behaviour
(class/interface) take precedence, although the other way around makes
for some quite interesting possibilities.

>  - It doesn't allow a type to be forced (casted) to the correct type.

As far as I can tell, this is a moot point. The whole discussion about
casting comes from the fact that hinting to a primitive type is more
restrictive than php's weak typing system. With a contract system this
problem doesn't exist. You could test that something conforms to your
specifications and then simply let the type system do its thing.

For example, instead of:

    function addFive(int $x) {
      return $x + 5;
    }

You would simply do:

    function addFive(is_numeric $x) {
      return $x + 5;
    }

Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.

--
troels

---

## #44888 — Josh Thompson — 2009-07-10T01:03:34+00:00

URL: https://externals.io/message/44855#44888 · In reply to: #44887

troels knak-nielsen wrote:
> > […]
> 
> The simplest solution would be to make one take precedence. You're not
> likely to have both a class and a function with the same name, and if
> you do, you kind of had it coming to you. For backwards compatibility
> it would probably be most fitting to let the current behaviour
> (class/interface) take precedence, although the other way around makes
> for some quite interesting possibilities.
> 

I would much rather be explicit with a different syntax, that way we 
don't have to add a new set of resolution rules. For example what would 
this do to autoload? Would we have to call it to see if the class is 
available every time? I think the function syntax disambiguates things 
and hints at what is happening.

> > […]
> 
> As far as I can tell, this is a moot point. The whole discussion about
> casting comes from the fact that hinting to a primitive type is more
> restrictive than php's weak typing system. With a contract system this
> problem doesn't exist. You could test that something conforms to your
> specifications and then simply let the type system do its thing.
> 

I can concede on this point. I just thought there might be some reason 
you would need it in a specific type, but none are coming to mind...

-- 
Joshua Thompson
Mechanical Engineer/Software Developer
http://www.schmalls.com

---

## #44889 — John Coggeshall — 2009-07-10T03:02:26+00:00

URL: https://externals.io/message/44855#44889 · In reply to: #44888

All:

I'm in favor of this so-called "Weak" typing Zeev has proposed as
well, but I would like to see it become available in PHP before PHP 6.
That doesn't mean it has to go into 5.3.x, but I don't see why there
can't be a 5.4 that includes it. Personally, I think primitive typing
has a much more immediate need than many of the features proposed for
6 and, considering there is already been numerous working patches that
implement this feature in principal, I don't see why we can't have a
5.4 release including it. Waiting for PHP 6 is too long and the many
serious time-consuming tasks that are required to achieve the goals of
PHP 6 shouldn't stop a very useful feature like this from getting into
the wild promptly.

Secondly, I'd like to discuss a little something I thought about
regarding when PHP will/will not throw an error dealing with primitive
types. Specifically when dealing with user input (which always comes
across as a string to start), if you had something like...

function foo(int $a, int $b) { return $a + $b; }

and called:

foo($_GET['a'], $_GET['b']); // $_GET['a'] === "foo", $_GET['b'] === 5

According to Zeev's description of the behavior this would cause a
fatal error, as $_GET['a'] cannot be converted to an integer value.. I
like that, but I think we need to devise a mechanism that allows you
to catch this error at runtime and write application logic around
it... In the simple case above the point would be to be able to catch
the error so that the requesting user could be informed he must enter
two integer values. Off the top of my head the only mechanism that I
can think of would be to throw an exception, which I'm not crazy about
either:

try
{
    print foo($_GET['a'], $_GET['b']);
} catch(TypeCheckException $e) {
    print "Sorry, you need to provide two integer values!";
}

Personally I really like the practical feel and ease of understanding
of using an exception in this case, but the idea of an exception being
thrown from potentially procedural code isn't the best thing to me..

John

---

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