February 26, 2006
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

Concept is really promising. Syntax ... well ... :D

I try to come with some other syntaxs.

ORYGINAL:

void LongFunction()
{
    State save = UIElement.GetState();
    on_scope_success UIElement.SetState(save);
    on_scope_failure UIElement.SetState(Failed(save));
    ...lots of code...
}

Why not:


VERSION A:
void LongFunction()
{
    State save = UIElement.GetState();
    on (success) {
         UIElement.SetState(save)
    }
    on (failure) {
        UIElement.SetState(Failed(save))
    }
    ...lots of code...
}

(not that success and failure could be recognized only as "on" keyword's
argument.)


VERSION B:
void LongFunction()
{
    State save = UIElement.GetState();
    scope (success) {
        UIElement.SetState(save);
    }
    scope (failure) {
        UIElement.SetState(Failed(save));
    }
    ...lots of code...
}

VERSION C:
void LongFunction()
{
    State save = UIElement.GetState();
    scope_success UIElement.SetState(save);
    scope_failure UIElement.SetState(Failed(save));
    ...lots of code...
}


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

VERSION D:
void LongFunction()
{
    State save = UIElement.GetState();
    onscope (success) UIElement.SetState(save);
    onscope (failure) UIElement.SetState(Failed(save));
    ...lots of code...
}

VERSION E:
void LongFunction()
{
    State save = UIElement.GetState();
    onscope {
        case success: UIElement.SetState(save);
    }
    onscope {
        case failure: UIElement.SetState(Failed(save));
    }
    ...lots of code...
}
February 26, 2006
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...
}
February 26, 2006
Dawid Ciężarkiewicz wrote:
> 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
> 
> Concept is really promising. Syntax ... well ... :D
> 

<snip>

> 
> VERSION B:
> void LongFunction()
> {
>     State save = UIElement.GetState();
>     scope (success) {
>         UIElement.SetState(save);
>     }
>     scope (failure) {
>         UIElement.SetState(Failed(save));
>     }
>     ...lots of code...
> }
> 

<snip>


I like something similar to the "scope" keywords. That looks quite promising.

VERSION B +1

-JJR
February 26, 2006


Tom S wrote:
> Cris wrote:
>>
>> Yes I agree with Kyle but not to overuse simple keywords, what about something like "onSuccess:", "onFailure:", etc...
> 
> Then it would look like an ordinary label, wouldn't it ? That's a different thing.

Are there labels in D?


> 
> 
>> To me all "_" look ugly. Perhaps the author could ask the community for suggestions when naming new features?
>> Or perhaps just "onScopeSuccess", "onScopeFailure"...
> 
> And these don't stand out enough IMO
> 
> 
> 


I don't say my suggestions are the best :) you can always suggest something better.
February 26, 2006
Walter Bright escribió:
> 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
> 
> 

I like the idea, but I don't like the names. Can something else be used instead?

-- 
Carlos Santander Bernal
February 26, 2006
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();
    }
}
February 26, 2006
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?
February 26, 2006
Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> bobef schrieb am 2006-02-26:
> 
>>Knud S�rensen wrote:
>>
>>
>>>Freshmeat is the slashdot equivalent for software.
>>
>>Forgive my ignorance, but what is slashdot?
> 
> 
> http://slashdot.org
> 
> Thomas
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFEAX4/3w+/yD4P9tIRAjvuAJwPvtROSVZvxhiVZkzrJK+5zq2hDQCeI3Bt
> ThkzHvadOtJAdWlCXR6c6zc=
> =sWOz
> -----END PGP SIGNATURE-----

Still, what is it? I've been there before .. didn't quite get it. Why is it so popular?!
February 26, 2006
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.

-- 
Regards,
James Dunne