• Manfred Nowak (42/42) Feb 03 2005 From the theoretical view I know, that using `with'-statements
• Ben Hinkle (5/20) Feb 03 2005 That looks like a compiler bug to me. The doc says
• Manfred Nowak (5/9) Feb 03 2005 But if the docs are right, then the semantic is wrong, because every
• Ben Hinkle (9/18) Feb 03 2005 The expression is only evaluated once before the body is executed. So I
• Ben Hinkle (1/2) Feb 03 2005 ack - that should be Entry - not Class. I hit send without double checki...
• Manfred Nowak (4/6) Feb 03 2005 I see. Agreed.

Manfred Nowak <svv1999 hotmail.com> writes:

From the theoretical view I know, that using `with'-statements 
complicatates every proof of correctness tremendously.

From the practical view I know, that detecting a `with'-statement in 
foreign code let me shudder, because I have to remember in full 
precision the name space, that is opened by the `with'-statement.

Nested `with'-statements let me have visions of devils coming out of 
hell.

D has a `with'-statment. I do not like it. I would prefer to code 
something like this:
<example>
  {
     alias complicated.expressionYou[Can[Imagine]].betterThanMe al;

     al.i= j + al.k;
  }
</example>

But such aliases ( or mixins?) are not possible in D.

Moreover: together with the overloading of operators `with'-
statements are somehow useless, like this example shows, when putting 
an array into a class:
<code>
void main(){
  struct Entry{
    int variable;
  }
  Entry[10] table;

  with( table[ 1]) variable=0;

  class Class{
    struct Entry{
      int variable;
    }
    Entry[10] table;
    Entry opIndex( int inx){
      return table[ inx];
    }
  }
  Class c= new Class;

  with( c[ 1]) variable= 0;
}
</code>

Did you see the "c.opIndex(1) is not an lvalue" error at first 
glance?

-manfred

"Ben Hinkle" <bhinkle mathworks.com> writes:

[snip]
  class Class{
    struct Entry{
.      int variable;
    }
    Entry[10] table;
    Entry opIndex( int inx){
      return table[ inx];
    }
 }
  Class c= new Class;

  with( c[ 1]) variable= 0;
 }
 </code>

 Did you see the "c.opIndex(1) is not an lvalue" error at first
 glance?

That looks like a compiler bug to me. The doc says
with(expr) { ... ident ... }
is semantically the same as
{Object tmp; tmp = expr; ... tmp.ident ...} 

Manfred Nowak <svv1999 hotmail.com> writes:

"Ben Hinkle" wrote:

 That looks like a compiler bug to me. The doc says
 with(expr) { ... ident ... }
 is semantically the same as
 {Object tmp; tmp = expr; ... tmp.ident ...} 

But if the docs are right, then the semantic is wrong, because every 
assignment is made to the `tmp'-object and not forwarded to the 
expression.

-manfred

"Ben Hinkle" <bhinkle mathworks.com> writes:

"Manfred Nowak" <svv1999 hotmail.com> wrote in message 
news:cttta3$fs7$1 digitaldaemon.com...
 "Ben Hinkle" wrote:

 That looks like a compiler bug to me. The doc says
 with(expr) { ... ident ... }
 is semantically the same as
 {Object tmp; tmp = expr; ... tmp.ident ...}

 But if the docs are right, then the semantic is wrong, because every
 assignment is made to the `tmp'-object and not forwarded to the
 expression.

 -manfred

The expression is only evaluated once before the body is executed. So I 
think for your example
 with(c[1]) variable = 0;
should be the same as
 {Class tmp; tmp = c[1]; tmp.variable = 0; }
Since objects have reference semantics the variable tmp shares the reference 
with c[1]. 

"Ben Hinkle" <bhinkle mathworks.com> writes:

 {Class tmp; tmp = c[1]; tmp.variable = 0; }

ack - that should be Entry - not Class. I hit send without double checking. 

Manfred Nowak <svv1999 hotmail.com> writes:

"Ben Hinkle" wrote: 

[...]
 Since objects have reference semantics the variable tmp shares the
 reference with c[1]. 

I see. Agreed.

-manfred