LOL

Derek Parnell wrote:
> On Sun, 26 Feb 2006 19:41:14 +1100, bobef <bobef@lessequal.com> wrote:
> 
>> Knud Sørensen wrote:
>>
>>> Freshmeat is the slashdot equivalent for software.
>>
>>
>> Forgive my ignorance, but what is slashdot?
> 
> 
> It's the equvalent of FreshMeat for I.T. related news and gosip.
> 

James Dunne wrote:
> Kyle Furlong wrote:
> bool LongFunction()
> {
>     bool  passed = false;
> 
>     scope (State save = UIElement.GetState())
>     catch { UIElement.SetState(Failed(save)); writef('0'); }
>     pass { UIElement.SetState(save); writef('1'); }
>     pass { passed = true; writef('2'); }
>     body {
>         ... lots of code ...
>     }
>     exit { writef('3'); }
> 
>     return passed;
> }

This is the best I've seen but:

- Why two "pass" blocks?.
- About "exit" would be better before the "body" block and maybe replace it with "finally" to save one more keyword.

I'm also assuming that we could also do one liners without the braces:


bool LongFunction()
{
    bool  passed = false;

    scope State save = UIElement.GetState();
    catch UIElement.SetState(Failed(save));
    pass UIElement.SetState(save);
    finally writef('3');
    body {
        ... lots of code ...
    }

    return passed;
 }

I don't see how this is marginally better than try - catch - finnaly. Thanks to garbage collection , exception safety is dramatically less complicated in D then in C++ ( in fact other than the mutex lock -- can anyone think of examples for exception safety in D ? ).  I think the problem here is exceptions, not exception safety -- and I think that point is illustrated with all the many work arounds for 'exception safety'.

I love that D is "thinking outside the box" , but I have to vote against this one.  Instead of improving exception safety, we should be improving exceptions.

Charlie


Walter Bright wrote:
> Scope guards are a novel feature no other language has. They're based on Andrei Alexandrescu's scope guard macros, which have led to considerable interest in the idea. Check out the article www.digitalmars.com/d/exception-safe.html
> 
> 

James Dunne wrote:
> I don't like the words 'success' and 'failure' used all over the place.

Yes. I have to agree they are little missused. Changing them to "pass" as success, "fail"/"catch" as "failure" and "default" as exit is good idea.

> void LongFunction()
> {
>      scope (State save = UIElement.GetState())
>      catch {
>          UIElement.SetState(Failed(save));
>      }
>      pass {
>          UIElement.SetState(save);
>      }
>      body {
>          ... lots of code ...
>      }
> }
> 
> This way, it looks like a function contract, except it applies to any scope.  The catch block is reused but only for purposes of noting that there was an exception caught.  The pass block is quite simply the 'else' to the catch block, and should happen only if no exceptions were caught.  Furthermore, there could be a general 'exit' block.
> 
> One could add as many of these blocks as necessary, and the compiler will guarantee to call them in order of definition, much like the original solution but not requiring one to think backwards.
> 
> bool LongFunction()
> {
>      bool  passed = false;
> 
>      scope (State save = UIElement.GetState())
>      catch { UIElement.SetState(Failed(save)); writef('0'); }
>      pass { UIElement.SetState(save); writef('1'); }
>      pass { passed = true; writef('2'); }
>      body {
>          ... lots of code ...
>      }
>      exit { writef('3'); }
> 
>      return passed;
> }
> 

IMHO now it looks overcomplicated. You are explicitly declaring new scope using body {} . This is for what whole idea was invented - to prevent it.

Using "catch" keyword is missleading. Keyword scope (expr.) works now as try { expr. } . And I have to say that I needed to read this code few times to understand it. It looks for me as reinventing try { } catch { } finally {} way of handling exceptions. Sorry, but I don't like it.

"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:dtsfm5$1h2i$1@digitaldaemon.com...
> Why not just reuse "finally"?
>
> void func()
> {
>     init_some_reource();
>     foo(); // foo throws an exception
>     //func doesn't catch the exception
>     //but it has a finally clause
>
>     finally  //aka on scope exit, whether success or fail
>     {
>         release_the_resource();
>     }
> }

finally does work for on_scope_exit, but it leaves on_scope_success and on_scope_failure hanging.

James Dunne wrote:
> Kyle Furlong wrote:
>> Dawid Ciężarkiewicz wrote:
>>
>>> Dawid Ciężarkiewicz wrote:
>>>
>>>> VERSION E:
>>>> void LongFunction()
>>>> {
>>>> State save = UIElement.GetState();
>>>> onscope {
>>>>         case success: UIElement.SetState(save);
>>>>     }
>>>> onscope {
>>>>         case failure: UIElement.SetState(Failed(save));
>>>>     }
>>>> ...lots of code...
>>>> }
>>>
>>>
>>> Just came to my mind:
>>>
>>> This version is especially neat because it may be simplified to:
>>> void LongFunction()
>>> {
>>>     State save = UIElement.GetState();
>>>     onscope {
>>>         case success: UIElement.SetState(save); break;
>>>         case failure: UIElement.SetState(Failed(save));
>>>     }
>>>     ...lots of code...
>>> }
>>
>>
>> I really like this idea, cons anyone?
> 
> I don't like the words 'success' and 'failure' used all over the place.  The meaning of the function's success isn't based on only if no exceptions were thrown.  Similarly, the function doesn't have to 'fail' if an exception were thrown.
> 
> I think they should be renamed to represent what they actually do.  That is, 'no exception thrown'/'pass', 'exception thrown'/'catch', 'scope exited'/'exit'.  Also, I think it would be more pleasing to the eye (and the maintainer) if the effect of the scope guard were more obvious in the code.  Something like:
> 
> void LongFunction()
> {
>     scope (State save = UIElement.GetState())
>     catch {
>         UIElement.SetState(Failed(save));
>     }
>     pass {
>         UIElement.SetState(save);
>     }
>     body {
>         ... lots of code ...
>     }
> }
> 
> This way, it looks like a function contract, except it applies to any scope.  The catch block is reused but only for purposes of noting that there was an exception caught.  The pass block is quite simply the 'else' to the catch block, and should happen only if no exceptions were caught.  Furthermore, there could be a general 'exit' block.
> 
> One could add as many of these blocks as necessary, and the compiler will guarantee to call them in order of definition, much like the original solution but not requiring one to think backwards.
> 
> bool LongFunction()
> {
>     bool  passed = false;
> 
>     scope (State save = UIElement.GetState())
>     catch { UIElement.SetState(Failed(save)); writef('0'); }
>     pass { UIElement.SetState(save); writef('1'); }
>     pass { passed = true; writef('2'); }
>     body {
>         ... lots of code ...
>     }
>     exit { writef('3'); }
> 
>     return passed;
> }
> 
> So, if an exception were thrown in '... lots of code ...', you'd see '03' and the function would return false.  However, if no exception were thrown you'd see '123' and the function would return true.  This demonstrates the order of execution across multiple blocks.  In this example, the order of the 'exit' block relative to the 'catch' and 'pass' blocks is important.
> 
> Consequently, I don't think the order of the 'body' block should matter at all, relative to the other blocks; and it should be fixed to only allow one instance of it.  Then, it is a matter of personal/project style where the 'body' block would fall.
> 
> Thoughts on this?
> 
> One last thought I had was to remove the parenthesized expression form of scope (expr) ... and use another block name to represent the initialization stage, just to be consistent.
> 
I think this syntax is a bit to busy for my taste. I think that it might work better as a more general proposal:

for any scope:

in
{
}
out
{
}
failure
{
}
success
{
}
body
{
}

Pros: fits into and expands current language structures
Cons: still a bit verbose as compared to current syntax

Dawid Ciężarkiewicz wrote:
> What do you think? Maybe later we'll come with better ideas.

VERSION F:
void LongFunction()
{
    State save = UIElement.GetState();
    register (scopepass) UIElement.SetState(save);
    register (scopefail) UIElement.SetState(Failed(save));
    ...lots of code...
}


VERSION G:
void LongFunction()
{
    State save = UIElement.GetState();
    register (scope) {
        case pass: UIElement.SetState(save); break;
        case fail: UIElement.SetState(Failed(save));
    }
    ...lots of code...
}

VERSION H:
void LongFunction()
{
    State save = UIElement.GetState();
    register {
        case scopepass: UIElement.SetState(save); break;
        case scopefail: UIElement.SetState(Failed(save));
    }
    ...lots of code...
}


P.S.
If I get more ideas I will throw them all (with those already posted) in one
new thread.

Honestly, as ugly as the syntax is, I must admit I like the grouping of the start and end conditions together.

That's one thing I've always thought strange about programming; people talk about functions and classes and all the different aesthetic and linear/non-linear relationships between them, but in the end it is all completely and totally linear, when for many cases that doesn't make sense.

-[Unknown]


> Walter Bright wrote:
>> "John Reimer" <terminal.node@gmail.com> wrote in message news:dtrg0e$c9k$1@digitaldaemon.com...
>>
>>> Nice feature, but rather ugly to look at; although, I'm not sure how something like that could be made to look pretty.
>>
>>
>> I think it's ugly, too, but I just couldn't come up with anything significantly better.
>>
>>
>>> Nonetheless the scope guard looks like something I should read up on.
>>>
>>> Thanks for another good release.
>>
>>
>> You're welcome.
>>
> 
> Why not just reuse "finally"?
> 
> void func()
> {
>     init_some_reource();
>     foo(); // foo throws an exception
>     //func doesn't catch the exception
>     //but it has a finally clause
> 
>     finally  //aka on scope exit, whether success or fail
>     {
>         release_the_resource();
>     }
> }

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dtstki$20os$1@digitaldaemon.com...
> Honestly, as ugly as the syntax is, I must admit I like the grouping of the start and end conditions together.
>
> That's one thing I've always thought strange about programming; people talk about functions and classes and all the different aesthetic and linear/non-linear relationships between them, but in the end it is all completely and totally linear, when for many cases that doesn't make sense.

Consider the for loop:

    for (expr; expr; expr)

The 3rd expression is executed at the *end* of the loop, yet it is placed at the beginning. So there is precedent for the utility of putting code where it conceptually belongs rather than where it is executed.

Why do you need "case" at all?

Dawid Ciężarkiewicz wrote:
> Dawid Ciężarkiewicz wrote:
>> What do you think? Maybe later we'll come with better ideas.
> 
> VERSION F:
> void LongFunction()
> {
>     State save = UIElement.GetState();
>     register (scopepass) UIElement.SetState(save);
>     register (scopefail) UIElement.SetState(Failed(save));
>     ...lots of code...
> }
> 
> 
> VERSION G:
> void LongFunction()
> {
>     State save = UIElement.GetState();
>     register (scope) {
>         case pass: UIElement.SetState(save); break;
>         case fail: UIElement.SetState(Failed(save));
>     }
>     ...lots of code...
> }
> 
> VERSION H:
> void LongFunction()
> {
>     State save = UIElement.GetState();
>     register {
>         case scopepass: UIElement.SetState(save); break;
>         case scopefail: UIElement.SetState(Failed(save));
>     }
>     ...lots of code...
> }
> 
> 
> P.S.
> If I get more ideas I will throw them all (with those already posted) in one
> new thread.