View mode: basic / threaded / horizontal-split · Log in · Help
February 26, 2006
Re: DMD 0.148 - scope guard
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
Re: DMD 0.148 - scope guard
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
Re: DMD 0.148 - scope guard
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
Re: DMD 0.148 - scope guard
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
Re: DMD 0.148 - scope guard
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
Re: DMD 0.148 - scope guard
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
Re: DMD 0.148 - scope guard
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
Re: DMD 0.148 - scope guard
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
Re: DMD 0.148 - scope guard
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
Re: DMD 0.148 - scope guard
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
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home