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