www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Two feature requests

reply 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();"
Oct 22 2006
parent reply =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= writes:
Boris Kolar wrote:
 1. Explicit interface implementation
   interface IFoo {
     void bar();
   }
   class Foo: IFoo {
     ...
     override void IFoo.bar() {
       ...
     }
   }

I love this feature as implemented on C#. It's a nice way to keep the 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. If you are familiar with C# you should think of them as classes that 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. The C# "using" statement it's more logical to me, but since "auto" allows stack allocation (thus improving performance) I'm very happy with it and my only complaint it's the type-inference issue.
Oct 22 2006
parent 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();"

are with us to allow deterministic destruction of an instance at the end of scope. If you are familiar with C# you should think of them as classes that 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. The C# "using" statement it's more logical to me, but since "auto" 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.
Oct 23 2006