addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgoogleimageimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

Re: [php-49] Type Hinting

From: Jared
Sent on: Thursday, March 1, 2012 12:25 PM
I think what you are experiencing is similar to what is so expertly written up here.

Good luck getting your banana.

-J

On Thu, Mar 1, 2012 at 12:21 PM, Kris Craig <[address removed]> wrote:
Yeah the proposal I've put out there is to make it optional, so the default behavior would be completely unchanged.

To be honest, I'm not entirely sure why there's so much opposition to this.  Thus far, the only arguments I'm seeing against it are obvious logical fallacies.  For example, "Strict typing would break PHP," completely ignoring the fact that we're not proposing strict typing and that this would be optional.  The most prevelent argument I'm seeing though is, "We've already voted this down years ago so it should never be brought up again!"  This ignores the fact that any rejected proposal can be reintroduced after 6 months, along with the fact that the previous proposals differed significantly from this one.

Essentially, every argument I've seen against it either refers to things that aren't in this proposal (like strict typing, mandatory usage, etc) or claims that nobody wants it, even though many if not most developers in fact do.  It basically boils-down to a battle against a very firmly entrenched status quo that thinks everything is perfect just the way it is.


At the end of the day, I get the impression that this is more about egoes than logic.  These core devs don't want it because they said so.  And they've said repeatedly that they'll vote down anything that even resembles type hinting regardless of the merits or public support for it.  Of course, I won't be deterred so easily, but it does present an uphill battle.

So far, the response on this list has been a stark contrast to the response on Internals.  Not that I'm surprised, mind you.  I've known for some time that this is something people have been asking for but it never seems to get done.  If any of you would like to follow this little soap opera, you can go to http://www.php.net/mailing-lists.php and look at the "Internals" list (you can either subscribe or just view each post in your web browser).  It's quite an interesting spectacle to watch.


As far as strict typing goes, David touched on some of the reasoning:  It would be a major, fundamental change to the PHP language and would render many-- if not most-- existing PHP scripts inoperable.  PHP developers with no programming experience would essentially be forced to learn an entirely new paradigm.  One of PHP's biggest selling points is its accessibility to web developers who have little or no programming experience.  Strict typing, while definitely having some positive points as some of you have mentioned, would just alienate too many people in favor of other languages.

I'd liken it to PHP 5's implementation of stronger OO principles.  People can now write object-oriented code (more or less), but they can also continue writing procedural code instead if they so choose.  I'd encourage these people to use this new functionality as an opportunity to learn OO design, but it's their choice.  My optional typing proposal for PHP 6 essentially follows that same logic.  We could always discuss strict typing in PHP 7, but I think this approach would at least be a good stepping stone IMHO.


I think times like this also present a good opportunity to encourage new people to become active in the development of PHP.  It is an open-source project, after all, and I've long felt that what it needs more than anything right now is some fresh blood; an infusion of some new people who are a little more open-minded about new ideas.  So if any of you have an interest in this and have at least some familiarity with ANSI C, drop me an email!  Being able to contribute code to PHP core and vote on new features is definitely a nice feather to have in one's cap.  =)

--Kris




On Thu, Mar 1, 2012 at 9:38 AM, Ryan Parman <[address removed]> wrote:
If the suggestion is simply to optionally type hint, well that's not so bad.

If the suggestion is to require typing (i.e., make the language strongly typed), you can't make this change without properly addressing the polymorphic model of the language. In which case, why not simply choose a different language in the first place.



On Mar 1, 2012, at 9:01 AM, Ian Dunn wrote:

If the proposal is just for the additional keywords, and the default behavior wouldn't change, I don't see why anybody would be against it. Am I missing something?


On 2/29/2012 5:42 PM, Kris Craig wrote:
Hey guys,

For many years now, a very heated debate has taken place within the PHP community about the role of variable types.  Every so often, the topic flares-up, ultimately resulting in a lot of heated emotions but not much else.  In recent years, some people in the community who actually support a change now vote against it because they're tired of this coming up.  I, on the other hand, see this pattern as evidence that this question is not going to simply go away if we ignore it long enough.  So, when this topic once again resurrected itself on the PHP Internals list, I decided to take an active role in keeping this conversation going until a resolution one way or another is finally agreed upon.  Needless to say, the last time I wandered into a shitstorm this big was when I encouraged my highschool social studies teacher to make abortion the topic of the next in-class debate....

So here's the issue:  Most veteran programmers I've worked with say their biggest objection to PHP is its total lack of variable typing.  While they understand it wouldn't add much on a performance level because it's a scripted language, they argue that allowing a coder to assign types to variables can make code easier to read and more compact because it dramatically reduces the need for bulky sanity checks.

Here's an example:  I've been working on a PHP app that someone else wrote (it's an internal company thing so I'm gonna fudge the details a bit just to keep things nice and kosher).  This person apparently has the annoying habit of reusing PHP variables ad nauseum, often for completely different purposes as different types.  For example, depending on any number of different factors, the $progress variable could be a multidimensional array that contains a "percent" key, which I can then use to track the task progress.  But at a different stage in the workflow, that same $progress variable is an integer representing something completely different.  At other times, it's a string or NULL.  If an error occurs, it becomes a boolean.  This is all well and good, but then imagine how much code I have to write just to get the progress percent without causing PHP to throw any notices or other errors (they've got error_reporting stuck on E_ALL lol).

If variable typing was present, the various sanity checks would be handled at a lower level instead, allowing for much cleaner and simpler code.


Mind you, the idea of "strict" typing is not being advocated, though some people keep bringing it up as a scare tactic.  C-like strict typing would essentially cause something like:  int $i = "1"; to throw an exception.  Obviously, that would be utterly ridiculous in PHP.

Instead, an idea that I and others have floated is to allow for optional weak variable typing.  Essentially, this is how it would look:

/* The first 3 here basically behave exactly as they already do now.  Nothing would change here. */
$a = 1; // No error, can be treated as 1 or "1" depending on the context.
$b = "1"; // No error, can be treated as 1 or "1" depending on the context.
$c = "Whatever"; // No error.  If used as an integer, PHP treats it as 0.

/* These 3 would represent the new "weak" typing. */
weak int $a = 1; // No error, can be treated as 1 or "1" depending on the context.
weak int $b = "1"; // No error, converts to 1 but can be treated as "1" if the context requires it (being appended to a string, for example).
weak int $c = "Whatever"; // Throws an E_NOTICE error and resolves to 0.

/* These 3 would represent the new "strong" typing; basically the same as weak but with a heavier error level on failure. */
strong int $a = 1; // No error, can be treated as 1 or "1" depending on the context.
strong int $b = "1"; // No error, converts to 1 but can be treated as "1" if the context requires it (being appended to a string, for example).
strong int $c = "Whatever"; // Throws an E_RECOVERABLE_ERROR (i.e. script execution is terminated unless the error is handled in a try/catch statement) and resolves to 0.


As you can see, the difference between "strong" and "weak" would essentially be the same as the difference between "require" and "include", respectfully.  I.e. they only differ in the severity of the error thrown if an incompatible, non-convertable type is assigned.

This is something that I've been advocating for inclusion in PHP 6.  Much like stronger OO adherence in PHP 5, this is a very contentious issue.


So, what do you all think about this issue?  Given how controversial and fundamental to PHP this debate is, I thought it might be interesting to mirror the discussion on the Meetup list.  This group is generally comprised more of PHP end-users while the Internals list is much more dominated by the core developers, so I'd be fascinated to see what sorts of opinions are raised here and if/how they contrast with those expressed on Internals.

Just remember:  This is variable typing we're talking about, not Roe v. Wade.  ;P

--Kris





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Kris Craig ([address removed]) from The Seattle PHP Meetup Group.
To learn more about Kris Craig, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Ian Dunn ([address removed]) from The Seattle PHP Meetup Group.
To learn more about Ian Dunn, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Ryan Parman ([address removed]) from The Seattle PHP Meetup Group.
To learn more about Ryan Parman, visit his/her member profile

Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Kris Craig ([address removed]) from The Seattle PHP Meetup Group.
To learn more about Kris Craig, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]

Our Sponsors

  • TUNE

    Meeting space and food

  • PluralSight

    PluralSight subscriptions for developer training

  • O'Reilly

    Disc Code: PCBW is good for 40% off print and 50% off ebooks and videos

  • JetBrains PhpStorm

    Occasional free licenses to raffle off at meetups

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy