SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 82
  1. #51
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    122
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ROFL! I can't tell whether you're taking the piss or not.

  2. #52
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,130
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    Isn't that already possible by throwing an extension?

    Right, sure, this labeled break is better for procedural apps.
    Assuming you mean an exception (), then yes.

    However, using an exception to control execution flow is kind of abusing the purpose behind the exception theory no?

  3. #53
    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 Viflux
    However, using an exception to control execution flow is kind of abusing the purpose behind the exception theory no?
    Not as I see it. Python developers use the maxim that says "it's easier to ask forgiveness than permission".

    Also, "exceptions" are not intended to be used only for handling errors, althought that's what they are mostly used for, especially in Java-land. Their purpose is to provide behavior under exceptional circumstances; exceptions are full-fledged classes, that can be used to call upon other classes etc, although I've rarely seen them being used for anything more than printing error messages.

  4. #54
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmmmm interesting, but i dont know if ppl can handle this, how about the zend fuse with Sun, has anybody heard anything about that yet, and for that matters, is this gonna be the latest release of PHP in which we know it today ?

    IMHO PHP6 is just an point release, nothing more there then a few fixes and some add-ons, so where's that HUGE BIG change we are all waiting for ?

    I think im gonna look for another main language, gotta look at that future ;-)
    Business as usual is off the menu folks, ...

  5. #55
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    Also, "exceptions" are not intended to be used only for handling errors, althought that's what they are mostly used for, especially in Java-land. Their purpose is to provide behavior under exceptional circumstances; exceptions are full-fledged classes, that can be used to call upon other classes etc, although I've rarely seen them being used for anything more than printing error messages.
    Not really. In Java land only beginners or mediocre programmers use exceptions for flow control, BECAUSE throwing exceptions around translates in a huge performance drop. Throwing exceptions costs performance and maintainability. The same is true for .NET (just ask on their forum).

    Exceptions were invented for error handling ONLY. If you use them for anything else, you violate structured programming, and it's the same as using GOTO. By violating structured programming you get lots more `secondary effects`.

  6. #56
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Take the language Pascal for example, that I have some experience with. You would be lost without the use of GOTO, due to the very nature of that language.
    I do have lots of experience with Turbo Pascal and I never had to use GOTO.
    And Pascal does have all structures in structured programming, well, the only thing that's annoying is that there is no return keyword in functions, but that doesn't mean you have to use GOTO.
    What are you talking about ? What's the nature of Pascal ?

  7. #57
    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 bonefry
    Exceptions were invented for error handling ONLY. If you use them for anything else, you violate structured programming, and it's the same as using GOTO. By violating structured programming you get lots more `secondary effects`.

  8. #58
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Funny isn't it ?
    Because I'm a nice guy, I will quote a paragraph from "Efective Java" by Joshua Bloch which is btw a great book and you should read it.

    Item 39:Use exceptions only for exceptional conditions

    Someday, if you are unlucky, you may stumble across a piece of code that looks something like this:
    Code:
    // Horrible abuse of exceptions. Don't ever do this!
    try {
        int i = 0;
        while(true)
            a[i++].f();
    } catch(ArrayIndexOutOfBoundsException e) {
    }
    What does this code do? It's not at all obvious from inspection, and that's reason enough not to use it. It turns out to be a horribly ill-conceived idiom for looping through the elements of an array. The infinite loop terminates by throwing, catching, and ignoring an ArrayIndexOutOfBoundsException when it attempts to access the first array element outside the bounds of the array. It's supposed to be equivalent to the standard idiom for looping through an array, instantly recognizable to any Java programmer:
    Code:
    for (int i = 0; i < a.length; i++)
        a[i].f();
    So why would anyone use the exception-based idiom in preference to the tried and true? It's
    a misguided attempt to improve performance based on the faulty reasoning that, since the VM
    checks the bounds of all array accesses, the normal loop termination test (i < a.length) is
    redundant and should be avoided. There are three things wrong with this reasoning:
    • Because exceptions are designed for use under exceptional circumstances, few, if any, JVM implementations attempt to optimize their performance. It is generally expensive to create, throw, and catch an exception.
    • Placing code inside a try-catch block precludes certain optimizations that modern JVM implementations might otherwise perform.
    • The standard idiom for looping through an array does not necessarily result in redundant checks; some modern JVM implementations optimize them away.

    In fact, the exception-based idiom is far slower than the standard one on virtually all current JVM implementations. On my machine, the exception-based idiom runs seventy times slower than the standard one when looping from 0 to 99.

    Not only does the exception-based looping idiom obfuscate the purpose of the code and reduce its performance, but it's not guaranteed to work. In the presence of an unrelated bug, the idiom can fail silently and mask the bug, greatly complicating the debugging process.

    Suppose the computation in the body of the loop contains a bug that results in an out-ofbounds access to some unrelated array. If a reasonable loop idiom were used, the bug would generate an uncaught exception, resulting in immediate thread termination with an appropriate error message. If the evil exception-based looping idiom were used, the bug-related exception would be caught and misinterpreted as a normal loop termination.

    The moral of this story is simple: Exceptions are, as their name implies, to be used only for exceptional conditions; they should never be used for ordinary control flow. More generally, you should use standard, easily recognizable idioms in preference to overly clever ones that are purported to offer better performance. Even if the performance advantage is real, it may not remain in the face of steadily improving JVM implementations. The subtle bugs and maintenance headaches that come from overly clever idioms, however, are sure to remain.

    This principle also has implications for API design. A well-designed API must not force its client to use exceptions for ordinary control flow. A class with a “state-dependent” method that can be invoked only under certain unpredictable conditions should generally have a separate “state-testing” method indicating whether it is appropriate to invoke the first method.

  9. #59
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And in case you don't know what structured programming is -
    quite simple realy, programs are split into sub-sections, each with a single point of entry and of exit:
    http://en.wikipedia.org/wiki/Structured_programming

    This paradigm appeared to make the control flow of programs easier in order to proove their correctness. OOP was the further development that enriched structured programming with philosophical ideeas taken from real life.

    But only with functional programming you can really proove an alghoritm is correct because functional programming it is based on the "no side-effects" rule:
    http://en.wikipedia.org/wiki/Functional_programming

    Thus, it is considered that structured programming and OOP are attempts at better controlling `side-effects` in imperative programming:
    http://en.wikipedia.org/wiki/Imperative_programming
    - which btw, was popular because of the way computers work - load var from memory / modify value / save variable to memory

  10. #60
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very nice, bonefry. OK, I apologize for laughing.

    Anyway, you just used a whole bunch of links and quotes in order to disprove something I never said. Actually, I was saying the opposite, which is nicely summed by this sentence quoted in your post:
    Exceptions are, as their name implies, to be used only for exceptional conditions; they should never be used for ordinary control flow.
    I mean, chill out, man.

  11. #61
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Seems I have goten the wrong message then

  12. #62
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    While I agree that exceptions should not be used for ordinary control flow and that structured or OOP constucts should be used before GOTO -- I think it is imposing both an intellectual straightjacket and blinders to say "never" use them. Even if you have or will never use them yourself, your assumption that the definition of "ordinary control flow" is so black and white that it is always a clear cut decision. Likewise your assumption that structured or OOP constucts best cover every programming problem is self-deception.

    Though I agree with you, I think the examples are much better persuaders than pedantic statements.
    Christopher

  13. #63
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    While I agree that exceptions should not be used for ordinary control flow and that structured or OOP constucts should be used before GOTO -- I think it is imposing both an intellectual straightjacket and blinders to say "never" use them. Even if you have or will never use them yourself, your assumption that the definition of "ordinary control flow" is so black and white that it is always a clear cut decision.
    Yes, we all know stupid programmers will always do stupid things, even if the language is trying to protect them. We've seen it all with Java.
    But anyway, why are we arguing ? If I say *never* does it change your beliefs ?

    Quote Originally Posted by arborint
    Likewise your assumption that structured or OOP constucts best cover every programming problem is self-deception.
    No, I think functional programming works better for *some* problems and I do intend to study CLISP for that reason.

    But YES, as long as there is no alghorithm that cannot be expressed without GOTO or similar constructs.
    In fact the only problems you could encounter would be for error handling, but that problem is handled by expressions these days.

    If you can provide only 1 example of where an alghorithm cannot be expressed without a GOTO statement, I will bow to you.

    Otherwise, I think it would be best to hear the man that practicaly invented structured programming:
    Go To Statement Considered Harmful, Edsger W. Dijkstra

  14. #64
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here is a thread where this was discussed last June. I thought the relevant portion is to this conversation is:

    Quote Originally Posted by php internals email
    > I think there are only two cases where goto is really interesting:
    > a) Error handling.
    > b) Auto-generating code or compiler compilers (Sterling mentioned these=
    =20
    > two).

    c) File parsers
    c) State machines

    Although, I guess it comes down to how you define 'interesting'.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  15. #65
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    If you can provide only 1 example of where an alghorithm cannot be expressed without a GOTO statement, I will bow to you.
    I think Jason points to the usual examples. The general class of problems where you have to do lots of interesting things all the while iterating through data in an interesting way. You would have to have solved one of these rare problems to understand how a few (well commented) GOTOs can slice through the Gordian Knot of well structured spagetti code -- artfully reducing already complex code.
    Quote Originally Posted by bonefry
    Otherwise, I think it would be best to hear the man that practicaly invented structured programming:
    Go To Statement Considered Harmful, Edsger W. Dijkstra
    I honestly blame that article for preventing a generation of programmers from thinking outside the box. The problem is that programmers only every heard it quoted. He even says, "I do not claim that the clauses mentioned are exhaustive in the sense that they will satisfy all needs," meaning that sometimes you need to to a GOTO. But who ever reads that far down.

    A pox on that article anyway, even for all the good it did.
    Christopher

  16. #66
    SitePoint Enthusiast
    Join Date
    Aug 2002
    Posts
    54
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    After a very huge positive improvement from PHP 4 to PHP 5 , i see that PHP 6 Will be a negative step in PHP life in comparing with other Scripting/Programming languages improvements , just take a look at ASP .NET 2 , JSP , and new Cold Fusion engine.

    For example GOTO statement will add a very loosely structure to PHP , where the modern development techniques based on the complete structred code ( That is why we use OOP as much as we can)

    I hope these notes will just be a notes and nothing more than that !

    Regards

  17. #67
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    there is no GOTO statement.. it is a break with a label. we don't called exceptions goto statements... we don't refer to function calls as goto and return statement.. its not a goto.. and its not where the work in php6 is going into, its a minor thing they were thinking about adding.. php is a language that is designed any many ways to offer a quick an easy means of throwing dynamic content into a website..if that means adding a fancy break statement, then so be it.

    the whole goto thing is getting way too much attention.. they are not forcing anyone to use it, i may never use it, and probably many other people here won't bother to use it as well.. but it could come in handy sometime..

  18. #68
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've pretty much covered everything there is to say about Goto in PHP on my blog.

    The lesson of structured programming isn't "Gotos are harmful." The lesson of structured programming is that a block of code should have exactly one entry point and exactly one exit point. Seriously, I'm old enough to remember structured programming zealots every bit as fervent as todays OO purists. One entry point and one exit point. For example, structured programming purists would have only one return statement in a function and it would always be at the end. Holy indented else clauses, batman!

    Today we don't consider multiple exit points to be all that harmful, in fact, they can be simplifying.

    However, multiple entry points are still bug bait. The modern example is the fall through of a switch statement. Useful sometimes? Sure. Easy to mess up by accident? Oh, yeah. Fall through is what you want in about 2% of your cases, but its up to you to specify that you don't want it in 98% of the time.

    While goto can be useful in some cases, those cases are rare in practice.

    Except that the people who want to use it want to use it for error handling, which is not rare. However, we already have exceptions for that, which, BTW, adhere to the single point of entry rule.

    This is really a culture clash between C programming and OO programming. Unfortunately, the core PHP developers are probably more immersed in the C culture than OO culture.

  19. #69
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    This is really a culture clash between C programming and OO programming. Unfortunately, the core PHP developers are probably more immersed in the C culture than OO culture.
    There could be a refactoring called Replace Goto with Return. Starting with this:

    PHP Code:
    function foo() {
        
    // Code chunk A
        
    goto some_label;
        
    // Code chunk B
        
    some_label:
        
    // Code chunk C

    We can extract a method or function to get this:

    PHP Code:
    function foo() {
        
    extracted();
        
    // Code chunk C
        
    }

    function 
    extracted() {
        
    // Code chunk A
        
    return;
        
    // Code chunk B

    This is no problem in object-oriented, well-factored code. But in procedural code, every new function adds to the cognitive load of keeping track of and naming functions.
    Last edited by dagfinn; Nov 28, 2005 at 03:25.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  20. #70
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The main clash between goto adherents and detractors is one where they are talking at cross-purposes. The detractors disavow goto because it makes code less readable and sometimes more complicated. The adherents want it because it is a useful optimisation for certain specialized types of code. There is no common ground in these two viewpoints. One is about making things faster, damned-be-readability. The other is about making things more readable damned-be performance. There is a limit to each desire: the fastest code in the world is worthless if it is not maintainable and the best factored code is worthless if it is non-performant.

    So does the general population need goto? Not by a long shot. Are there valid uses for it? Absolutely! Should it be included in PHP? I for one work on at least one project where it would help performance (for parsers) and so I would welcome it. Its not that we can't live without it -- we can and do. The real question is whether it is worth supporting a few valid but corner cases at the risk of introducing a construct that can be wildly abused. That said, exceptions can be wildly abused and yet they get a lot of traction. The difference I see is that goto comes from the old-fart-procedural world while exceptions are the latest candy for the OOP crowd. I think both groups should get catered to.

    I also noticed that no one is mentioning the fact that it is planned to remove the E_STRICT warning from "var" allowing it to be a standard alias to "public". Personally, I never understood why the E_STRICT was thrown for that case and I would like that change to be made now rather than have to wait for PHP6.

    Cheers.

  21. #71
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Lots of discussion since the webcast about the Zend Framework (which I missed). A picture is worth a thousand words.

    Christopher

  22. #72
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    A picture is worth a thousand words.
    And a nice picture it is too!

    Is there any code out yet?

    Douglas
    Hello World

  23. #73
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Brooklyn, NY
    Posts
    359
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In addition to that image, there are a few code samples on my blog:

    http://shiflett.org/archive/171
    Chris Shiflett
    http://shiflett.org/

  24. #74
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    Rome
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by n0other
    Dr Livingston, could you explain why do we need type hinting?
    Just an example coming to my mind that induces me to think it can be very useful if we are designing high-level enough: lightweight container, dependency injection - like Marcus Baker's Phemto...

    p.s. Marcus, I was wondering why you say hinting is not needed being the author of that piece of software.... can you explain?

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

    While it was there anyway, I thought I might as well use it . The DI tools in Ruby and Python work fine without hinting, it's just a nice to have in this case. I'd have traded that feature for an earlier release of PHP5 with fewer bugs and a language that was easier for newcomers to learn.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


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
  •