SitePoint Sponsor

User Tag List

Page 1 of 4 1234 LastLast
Results 1 to 25 of 82

Hybrid View

  1. #1
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Springtime for PHP6 in Paris

    Very interesting (and long) notes by Derick Rethans covering the PHP developers discussion of PHP6 in Paris. Interesting reading.

    http://www.php.net/~derick/meeting-notes.html
    Christopher

  2. #2
    SitePoint Enthusiast
    Join Date
    Nov 2004
    Location
    Canberra, Australia
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OMG I nearly died when I saw item 4.2!!

  3. #3
    Web-coding NINJA! silver trophy beetle's Avatar
    Join Date
    Jul 2002
    Location
    Dallas, TX
    Posts
    2,900
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by {RainmakeR}
    OMG I nearly died when I saw item 4.2!!
    They way they are going to implement it isn't totally crazy. You can already do that with javascript, for example.
    beetle a.k.a. Peter Bailey
    blogs: php | prophp | security | design | zen | software
    refs: dhtml | gecko | prototype | phpdocs | unicode | charsets
    tools: ide | ftp | regex | ffdev




  4. #4
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Australia
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Are there any "good" reason to use item 4.2 at all? Are there any wild estimated ETA for php6?

  5. #5
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'd like to see some code that is better implemented with GOTO.
    Someone make me a believer.

  6. #6
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lazy_yogi
    I'd like to see some code that is better implemented with GOTO.
    Someone make me a believer.
    There are a number of examples of programming problems that are not well expressed using only structured programming constructs. Parsers are one of the most common examples, but there are others if you search the literature. Generally they are problems that have multiple conditions for block entrance and exit.

    It is fairly common knowledge that structured programming, or OOP for that matter, while generally very good at most things are are not good at expressing some programming problems (you can't expect perfection). And even structured programming added the switch statement which -- though not that often used -- is just a disguised goto. The warnings against using goto are for beginning programmers (who should only have if and while anyway). Experienced programmers will judiciously use language constructs as appropriate.
    Christopher

  7. #7
    SitePoint Guru dbevfat's Avatar
    Join Date
    Dec 2004
    Location
    ljubljana, slovenia
    Posts
    684
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    ... And even structured programming added the switch statement which -- though not that often used -- is just a disguised goto. ...
    I believe switch is a disguised if statement, not goto.

    I've never seen a single piece of code that would actually benefit from goto, in terms of code clarity, flow and ease of maintenance. Can any of you that disagree with that post an example of such code? I'm always open to different approaches.

    Best regards

  8. #8
    Web-coding NINJA! silver trophy beetle's Avatar
    Join Date
    Jul 2002
    Location
    Dallas, TX
    Posts
    2,900
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lazy_yogi
    I'd like to see some code that is better implemented with GOTO.
    Someone make me a believer.
    The one person I'm sure of who doesn't know everything is the very man to claim just that.

    It's true that a "goto"-like construct may rarely if-ever be useful in the problems most web-application developers face, but I don't pretend to know so much as to say it would never help.
    beetle a.k.a. Peter Bailey
    blogs: php | prophp | security | design | zen | software
    refs: dhtml | gecko | prototype | phpdocs | unicode | charsets
    tools: ide | ftp | regex | ffdev




  9. #9
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Brooklyn, NY
    Posts
    359
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The goto debate is tired, and I doubt anyone can come up with new arguments.

    The reason for having any language feature is to put more power in the hands of developers. This is what I've always loved about PHP. It gives you plenty of rope with which to hang yourself. :-)
    Chris Shiflett
    http://shiflett.org/

  10. #10
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I was interested in a comment by one of those present, Andrei Zmievski:
    ... once 5.1 is out, I think we can concentrate on the implementation of PHP 6, which should be great.
    It sounds like the 5 series may not have quite as long a run as the 4 series -- if the focus after 5.1 is on a 6.0 release.
    Christopher

  11. #11
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks, arborint, really interesting reading!

    There will be two string types: Binary (which is non-unicode) and String (which can be unicode or not, depending on ini setting). Similarly, there will be two integers: Int64 (which is always 64 bit) and Int (which is 32- or 64-bit depending on the current machine's word size). I've a strange feeling this can cause some portability troubles...

    Can anybody explain 5.10? What's so " dangerous" about calling the same function as static and dynamic?

  12. #12
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog
    I've a strange feeling this can cause some portability troubles...
    Yes, that sounds like a recipie for disaster. At least we now have the preservation to come out in two years and say "I told you so".

  13. #13
    SitePoint Enthusiast MstrBob's Avatar
    Join Date
    Dec 2004
    Location
    New York City
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog
    There will be two string types: Binary (which is non-unicode) and String (which can be unicode or not, depending on ini setting). Similarly, there will be two integers: Int64 (which is always 64 bit) and Int (which is 32- or 64-bit depending on the current machine's word size). I've a strange feeling this can cause some portability troubles...
    Isn't that currrently how PHP works anyway? Integers on 64bit systems are 64bits. They're only adding a new int64 which will be 64bits regardless of the system.

    I don't know, from the discussions it looks pretty good. They're cleaning up the language, which is a good thing. Yes, of course that causes compatability issues, it always will. But that's part of upgrading, isn't it? It's not like they're suddenly dropping features, they're removing depreceated, archaic, and unused stuff.

    XMLReader and XMLWriter in the default distribution seems handy as well. All in all this seems like a pretty positive step for PHP. It needs a cleanup, sometimes things just get clunky. Goto support is not decided on yet, so we can't really complain yet.

    My main concern, of course, is this focus to PHP 6. Most of my clients have hosting with PHP 4. With PHP 5 penetration not that deep yet, they're already jumping to another major version?

  14. #14
    SitePoint Addict n0other's Avatar
    Join Date
    Feb 2005
    Posts
    290
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the link aborint.

    Do we really need type-hinting for function return values?

  15. #15
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I was, really, really disappointed seeing that. I was looking forward to them making the OO model better, but all we seem to be going to get is namespace support. Sorta.

  16. #16
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    I was, really, really disappointed seeing that. I was looking forward to them making the OO model better, but all we seem to be going to get is namespace support. Sorta.
    even that looks disappointing.....

    $x = new company\web\class(); or

    import company\web;

    and not one mention of a property keyword ....sigh =(

    i think i need to get rich, then go learn some c/c++ and extend my own version of php. sigh.

  17. #17
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How would you write the following:
    Code:
    if cond1 do action1
    elsif cond2 do action2, then do action1
    elsif cond3 do action3, then do action1
    where conditions are dependant (cannot be reordered)?

    See also often quoted discussion at http://kerneltrap.org/node/553

  18. #18
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Actually I am glad to see the feature set is pretty small. They are taking stuff out at last, moving things to PECL and they rejected a whole bunch of stuff . After all the crap they put in last time (final?, type hints) it would be good to get cleaner. That will speed development in itself.

    Adding dodgy language constructs (like GOTO) will slow development of PHP7. There is a big cost to adding a feature. You can never say GOTO is OK just because you cannot see a reason against it, there is always a hefty cost. It's just dumb management.

    I am not sure what use type hinting on return values will be either. Handy for the Zend IDE, but not much else. PHP could have managed quite happily without type hints in the first place IMO. I'd rather have seen a smooth migration from 4 to 5 higher on the priorities.

    There is one worrying thing about this. The idea that 5.1 is deemphisized in favour of 6. They should make sure they employ the talent on the current version, not just the fun new one. PHP5 has a huge number of very damaging bugs right at the OO core. I noticed that they have removed the OO category from the bug statistics page now and "phpsniper" has got his dream of marking them all bogus, but they are still there. I'd like to see those fixed.

    Unicode is good move though. That will remove a whole load of junk from the language. Shame they couldn't have dome that gradually.

    Regarding namespaces, the number one problem I have is importing legacy bits from all over the web and avoiding nameclashes. Any import faclity has to be able to import unnamed legacy code under a namespace.

    yours, Marcus

    p.s. My favourite useless syntatictic sugar would be defining methods like this...
    PHP Code:
    class WithStuff {
        public 
    $_stuff;
        public 
    $_more_stuff;
        
        function 
    WithStuff($this->_stuff$this->_more_stuff) { }

    Would cut out lot's of useless chains of assignment.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  19. #19
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I haven't even read the link yet, and you guys made me afraid already. Seems I'll really have to dive into Python then...

  20. #20
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just found this in Derick's notes:
    As PHP is a weekly typed language this kind of functionality does not make sense in PHP.
    First, the typo is hilarious.

    However, it makes me sad when I see that the base contributors do not know the difference between weakly and dynamically typed languages.

  21. #21
    SitePoint Addict
    Join Date
    Aug 2002
    Posts
    385
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As PHP is a weekly typed language this kind of functionality does not make sense in PHP.
    HAH. Now that makes sense why php didn't care about types.

  22. #22
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Marcus
    import unnamed legacy code under a namespace.
    wouldn't that possibly just go under the global namespace by default?


    and just in general, how bad would it be to be able initalize an object through a private field when defining fields inside the class?

  23. #23
    SitePoint Evangelist
    Join Date
    Jun 2004
    Location
    California
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I very much enjoy many of the features that are being implemented into PHP6... but I also notice that many of them are core features of Ruby already

  24. #24
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by xmitchx
    I very much enjoy many of the features that are being implemented into PHP6... but I also notice that many of them are core features of Ruby already
    Don't compare apples and oranges. Ruby is a general-purpose language designed ground-up as an OO language. PHP is a scripting language running on top of a Web platform that was originally designed as purely procedural.

  25. #25
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by BerislavLopac
    Don't compare apples and oranges.
    Why not?

    Oranges are more juicy than apples, though the skin on apples tastes better.

    See, we can compare them. Just as we can compare PHP and Ruby. No need to be offended by this.

    You can't claim that two things are incomparable just because ther are different, otherwise there would be little need for comparison in the first place.
    Hello World


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •