• Boris Kolar (24/24) Oct 22 2006 Two features will make this already great language even better:
• =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= (17/42) Oct 22 2006 I love this feature as implemented on C#. It's a nice way to keep the
• Boris Kolar (27/44) Oct 23 2006 Deterministic destruction is exactly why I want auto classes. In C++, yo...

Boris Kolar <boris.kolar globera.com> writes:

Two features will make this already great language even better:

1. Explicit interface implementation
  interface IFoo {
    void bar();
  }
  class Foo: IFoo {
    ...
    override void IFoo.bar() {
      ...
    }
  }

2. Make auto classes useful and allow them to be returned from functions,
passed to other functions, or be fields in other auto classes. Current
restrictions make them useless. I think auto class should behave like object
on stack, except default constructor (this() {...}) should be called it's
declared and destructor when it goes out of scope. The object itself may
reside on stack or heap, it doesn't really matter as long as stack semantics
applies. Also, I would remove requirement that auto class variables must be
explicitly declared "auto", so the following should be allowed:

auto class Foo { ... }
...
Foo x; // equivalent to "auto Foo x;"?

... or perhaps this:
Foo x; // equivalent to "auto Foo x = new Foo();"

=?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= writes:

Boris Kolar wrote:
 1. Explicit interface implementation
   interface IFoo {
     void bar();
   }
   class Foo: IFoo {
     ...
     override void IFoo.bar() {
       ...
     }
   }


interface of a class clean from the user's stand point and still 
implement needed interfaces without using inner classes or other cruft.

Also, currently there's no way to implement two different interfaces 
that expose the same method if the behavior should be different.



 2. Make auto classes useful and allow them to be returned from functions,
 passed to other functions, or be fields in other auto classes. Current
 restrictions make them useless. I think auto class should behave like object
 on stack, except default constructor (this() {...}) should be called it's
 declared and destructor when it goes out of scope. The object itself may
 reside on stack or heap, it doesn't really matter as long as stack semantics
 applies. Also, I would remove requirement that auto class variables must be
 explicitly declared "auto", so the following should be allowed:
 
 auto class Foo { ... }
 ....
 Foo x; // equivalent to "auto Foo x;"?
 
 .... or perhaps this:
 Foo x; // equivalent to "auto Foo x = new Foo();"

I think that this isn't the intended purpose of auto classes in D. They 
are with us to allow deterministic destruction of an instance at the end 
of scope.


implement IDisposable and are created inside a "using" statement. Their 
life-time spans until the closing brace and then the destructor is 
called. This is very useful technique, specially if you are using a 
Database or other resources witch are scarce.


allows stack allocation (thus improving performance) I'm very happy with 
it and my only complaint it's the type-inference issue.

Boris Kolar <boris.kolar globera.com> writes:

== Quote from Julio César Carrascal Urquijo (jcesar phreaker.net)'s article
 auto class Foo { ... }
 ....
 Foo x; // equivalent to "auto Foo x;"?

 .... or perhaps this:
 Foo x; // equivalent to "auto Foo x = new Foo();"

 I think that this isn't the intended purpose of auto classes in D. They
 are with us to allow deterministic destruction of an instance at the end
 of scope.

 implement IDisposable and are created inside a "using" statement. Their
 life-time spans until the closing brace and then the destructor is
 called. This is very useful technique, specially if you are using a
 Database or other resources witch are scarce.

 allows stack allocation (thus improving performance) I'm very happy with
 it and my only complaint it's the type-inference issue.

Deterministic destruction is exactly why I want auto classes. In C++, you also
have deterministic destruction with structs/classes (in case of classes you must
not use the "new" keyword). For example, this C++ code achieves the desired
result
of deterministic destruction:

#include "stdio.h"

class Test {
public:
	Test() {
		printf("ctor\n");
	}
	~Test() {
		printf("dtor\n");
	}
};
void test() {
	Test t;
}
int main() {
	printf("Running test\n");
	test();
	printf("Done testing\n");
	return 0;
}

In C++, however, "auto classes" are much more usefull because they can be passed
as parameters, returned as results, or part of other classes. I'm 100% sure we
can
have both: usability without current restrictions and deterministic destruction.