Serg Kovrov wrote:
> 
> IMHO 'on scope exit' approach is not much different from 'one return at end of function' with condition flag(s).

True.  But if the function is complex and has multiple return points, scope(success) is easier to maintain.

> And it is kind of obscure code for me - it can be anywhere in function, maybe even may times, etc... It's hard to maintain (just like goto's), and as so, it's no use for me at this point.

It's a matter of opinion, I suppose.  I find scope declarations more visible and more meaningful than the alternatives.  And I like that I can place them next to the declarations of data they're meant to affect, thus making the code more meaningful.


Sean

>> And it is kind of obscure code for me - it can be anywhere in function, maybe even may times, etc... It's hard to maintain (just like goto's), and as so, it's no use for me at this point.
>
> It's a matter of opinion, I suppose.  I find scope declarations more visible and more meaningful than the alternatives.  And I like that I can place them next to the declarations of data they're meant to affect, thus making the code more meaningful.
>
> Sean

Are you using them in practice? Is there a link I can follow to see the
code?
TIA

Ben Hinkle wrote:
>>> And it is kind of obscure code for me - it can be anywhere in function, maybe even may times, etc... It's hard to maintain (just like goto's), and as so, it's no use for me at this point.
>> It's a matter of opinion, I suppose.  I find scope declarations more visible and more meaningful than the alternatives.  And I like that I can place them next to the declarations of data they're meant to affect, thus making the code more meaningful.
> 
> Are you using them in practice? Is there a link I can follow to see the code?

scope(success)?  Not yet.  I've only used scope(failure) and scope(exit) so far:

http://svn.dsource.org/projects/ares/trunk/src/ares/std/array.d
http://svn.dsource.org/projects/ares/trunk/src/ares/std/thread.d

I do think the use of scope(success) is fairly limited--the DB example is one of the I can think of--but it's a nice option to have.

Sean

Regan Heath wrote:
> On Tue, 9 May 2006 22:36:03 -0400, Ben Hinkle <ben.hinkle@gmail.com> wrote:
> 
>>> Maybe... self documenting functions, listing all return values at the  top?
>>>
>>> int foobar( ..etc.. )
>>> {
>>>   scope(success) return 1;
>>>   scope(failure) return 0;
>>>
>>> }
>>
>>
>> Does scope(failure) continue unwinding the stack? I wonder what the  behavior
>> is of returning from a scope(failure).
> 
> 
> Good question. No idea. :(
> 
>> I believe writing "scope(success) foo;" followed by the end of the  current scope is equivalent to just writing "foo;". Maybe I'm  misunderstanding the example.
> 
> 
> You're right. For some reason I got it in my head that scope(success)  happened when the function itself returned, as opposed to the current  scope closing.
> 
> So, what about in this case:
> 
> int foobar( ..etc ..)
> {
>   if (a) scope(success) a.foo();
>   //A: immediately after if
> }
> //B: at function return
> 
> when does a.foo() get executed? at A or B? I get the impression it's A.
> 
> Regan

Evidence from testing is that a.foo() is executed at point A.  Which I think is a shame, really.  It limits the usefulness of the scope() statement, which I feel is otherwise full of potential.  Maybe its a little silly to say aloud, but certain statements just shouldn't "be a scope" for the sake of the scope() statement.  Maybe different scopes should have "weights" or something... I don't know how it should be done, just that it should, or else a way created to say which scope you are anchoring on, but what on earth would the syntax be?

-- Chris Nicholson-Sauls

Regan Heath wrote:
> On Tue, 9 May 2006 22:36:03 -0400, Ben Hinkle <ben.hinkle@gmail.com> wrote:
>> I believe writing "scope(success) foo;" followed by the end of the  current scope is equivalent to just writing "foo;". Maybe I'm  misunderstanding the example.
> 
> You're right. For some reason I got it in my head that scope(success)  happened when the function itself returned, as opposed to the current  scope closing.
> 
> So, what about in this case:
> 
> int foobar( ..etc ..)
> {
>   if (a) scope(success) a.foo();
>   //A: immediately after if
> }
> //B: at function return
> 
> when does a.foo() get executed? at A or B? I get the impression it's A.
> 
> Regan

if statements do not create a scope without { }, therefore it should be at B.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

James Dunne wrote:
> 
> if statements do not create a scope without { }, therefore it should be at B.

They don't?


Sean

On Wed, 10 May 2006 00:39:30 -0400, Regan Heath <regan@netwin.co.nz> wrote:

> You're right. For some reason I got it in my head that scope(success) happened when the function itself returned, as opposed to the current scope closing.
>
> So, what about in this case:
>
> int foobar( ..etc ..)
> {
>    if (a) scope(success) a.foo();
>    //A: immediately after if
> }
> //B: at function return
>
> when does a.foo() get executed? at A or B? I get the impression it's A.
>
> Regan

This gives me an idea, how about if there was scope(none) that is just like a regular block, but doesn't create a new scope. This would be for when you only need to group statements but have no interest in a new scope.

void foo()
{
   if(a) scope(none) { stuff(); scope(success) bar(); }
   baz();
}

bar() would execute after baz();

- Chris

Chris Miller wrote:
> 
> This gives me an idea, how about if there was scope(none) that is just like a regular block, but doesn't create a new scope. This would be for when you only need to group statements but have no interest in a new scope.
> 
> void foo()
> {
>    if(a) scope(none) { stuff(); scope(success) bar(); }
>    baz();
> }
> 
> bar() would execute after baz();

It's a nasty hack, but:

if(!a) goto blah;
scope(success) a.foo();
blah:
...


Sean

On Thu, 11 May 2006 08:13:37 +1000, Sean Kelly <sean@f4.ca> wrote:

> Chris Miller wrote:
>>  This gives me an idea, how about if there was scope(none) that is just like a regular block, but doesn't create a new scope. This would be for when you only need to group statements but have no interest in a new scope.
>>  void foo()
>> {
>>    if(a) scope(none) { stuff(); scope(success) bar(); }
>>    baz();
>> }
>>  bar() would execute after baz();
>
> It's a nasty hack, but:
>
> if(!a) goto blah;
> scope(success) a.foo();
> blah:
> ...

And I guess this is just as nasty ...

   scope(success) if (a) a.foo();

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:
> On Thu, 11 May 2006 08:13:37 +1000, Sean Kelly <sean@f4.ca> wrote:
> 
>> Chris Miller wrote:
>>>  This gives me an idea, how about if there was scope(none) that is just like a regular block, but doesn't create a new scope. This would be for when you only need to group statements but have no interest in a new scope.
>>>  void foo()
>>> {
>>>    if(a) scope(none) { stuff(); scope(success) bar(); }
>>>    baz();
>>> }
>>>  bar() would execute after baz();
>>
>> It's a nasty hack, but:
>>
>> if(!a) goto blah;
>> scope(success) a.foo();
>> blah:
>> ...
> 
> And I guess this is just as nasty ...
> 
>    scope(success) if (a) a.foo();

Preferable so long as the state of a is maintained until scope exit. But all of this smacks as an attempt to use the scope feature in a manner that wasn't intended.


Sean