On Sunday, 3 March 2013 at 13:19:35 UTC, deadalnix wrote:
> ...

Ah, beg my pardon, misunderstood you a bit. Still, difference I am trying to point is that virtual vs final does not rely on actual method implementation at all, while proper CTFE function needs to be written with CTFE in mind as different subset of language can be used. If one function will be found CTFE-able by accident and used in such, any change to its implementation that will add non-CTFE features (preserving public function interface and behavior) will break user code.

On Sunday, 3 March 2013 at 13:24:39 UTC, Dicebot wrote:
> On Sunday, 3 March 2013 at 13:19:35 UTC, deadalnix wrote:
>> ...
>
> Ah, beg my pardon, misunderstood you a bit. Still, difference I am trying to point is that virtual vs final does not rely on actual method implementation at all, while proper CTFE function needs to be written with CTFE in mind as different subset of language can be used. If one function will be found CTFE-able by accident and used in such, any change to its implementation that will add non-CTFE features (preserving public function interface and behavior) will break user code.

Yes both are technically very different. But you argue for CTFEability by default or when choosen with almost the same arguments.

I explained my oppinion before on that : CTFEability can be decoupled from actual source code using some bytecode. Bytecode should be opaque enough to make that work.

On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu wrote:
> A chat in IRC revealed a couple of possible improvements to the development scenario in which the interface file (.di) is managed manually and separately from the implementation file (.d).
>
> After discussing a few ideas with Walter, the following language improvement came about. Consider a very simple scenario in which we have files a.d, a.di, and client.d, all situated in the same directory, with the following contents:
>
> // a.di
> class A { private int x; int foo(); }
>
> // a.d
> import a;
> int A.foo() { return x + 1; }
>
> // client.d
> import a;
> void main() { (new A).foo(); }
>
> To compile:
>
> dmd -c a.d
> dmd -c client.d
> dmd client.o a.o
>
> Currently, in order for a program with separately-implemented methods to work properly, there must be TWO different files for the same class, and the .di file and the .d file MUST specify the same exact field layout. Ironically, the .d file is forbidden from including the .di file, which makes any checks and balances impossible. Any change in the layout (e.g. swapping, inserting, or removing fields) is undetectable and has undefined behavior.
>
> I see this as a source of problems going forward, and I propose the following changes to the language:
>
> 1. The compiler shall accept method definitions outside a class.
>
> 2. A method cannot be implemented unless it was declared with the same signature in the class definition.
>
> Walter is reluctantly on board with a change in this direction, with the note that he'd just recommend interfaces for this kind of separation. My stance in this matter is that we shouldn't constrain without necessity the ability of programmers to organize the physical design of their large projects.
>
> Please discuss here. I should mention that Walter has his hands too full to embark on this, so implementation should be approached by one of our other dmd contributors (after of course there's a shared view on the design).
>
>
> Andrei

One of the main selling points of the module system is to prevent exactly what you are proposing, so I think there must be a better solution.

The biggest disappointment I have with modules, is that you cannot define an interface inside of them, and must instead resort to a .di file.

Manually maintaining a .di file is a bad idea for what should be obvious reasons, and the auto generation of the .di is a failure because you cannot tell the compiler how to generate the .di file from inside the module.

For a solution, what I'd like to see is manual control over what will go into an automatically generated .di placed directly inside the D module.

For example, allow the programmer to specify the separation of interface from implementation directly inside the module through an improvement to how modules are defined, that is to say allow the programmer to specify what is a part of the interface and what is a part of the implementation directly inside the module. The compiler can then auto generate the necessary .di interface files from that information, the obvious benefit being that you'll get interface and implementation separation without the separation of where the control point is, eg it's all done inside the module where it should be done and nowhere else, and do it without a duplication of definitions. This can possibly be done without duplication through the attribute system.

There should be a way for the compiler to determine if previously auto generated interface files are the same or differ to prevent overwriting and forcing unnecessary recompilation. If the .di files are stored in specific locations away from wher the compiler is dumping them, then you could add an "include" switch to tell the compiler where to look for previously generated .di and compare them.

Sure it's a bit of effort to implement, but it seems like a far more useful solution that is safe, scalable, and easy to maintain.

--rt

PS: While we're on the topic of interfaces (or lack thereof), another problem point I have with D is that while you can define an interface for classes, you cannot do the same thing with structs. I don't understand why structs cannot have interfaces.

+1_000_000_000

Yes please!
It's near impossible to get a brief overview of a class at a glance in D!


On 3 March 2013 15:35, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu wrote:
>
>> 1. The compiler shall accept method definitions outside a class.
>>
>
> Sorry to bump this old thread, but after having spent some time with D I like the idea of having the ability to implement class methods outside of the class, but I would like to have this ability in the same file as the module:
>
> module test;
>
> class C
> {
>     void foo1();
>
>     void bar1()
>     {
>         // N1 -- two indents
>     }
>
>     class Inner
>     {
>         void foo2();
>         void bar2()
>         {
>             // N2 -- three indents
>         }
>     }
> }
>
> // if allowed:
>
> void C.foo()
> {
>     // 1 indent
> }
>
> void C.Inner.foo2()
> {
>     // 1 indent
> }
>
> The benefit? Avoiding the indentation tax. I've come to find it really annoying that hundreds of lines of code end up being indented twice or more times. Changing the indentation setting is not a real solution, I like my indentation size the way it is, I just don't like being forced to indent too much because of the requirement to implement everything inline.
>

On Monday, 4 March 2013 at 06:06:14 UTC, Rob T wrote:
> One of the main selling points of the module system is to prevent exactly what you are proposing, so I think there must be a better solution.

Please explain. Main points of module system is to avoid header compilation time hell and control access. I don't how this is relevant to the topic.

On Monday, 4 March 2013 at 06:06:14 UTC, Rob T wrote:
> Manually maintaining a .di file is a bad idea for what should be obvious reasons

No, they are not obvious at all, please explain.

On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu wrote:

[SNIP]

>
> Walter is reluctantly on board with a change in this direction, with the note that he'd just recommend interfaces for this kind of separation. My stance in this matter is that we shouldn't constrain without necessity the ability of programmers to organize the physical design of their large projects.

I agree with Walter here, I have had good success with
interfaces and abstract classes (where speed dictated direct
field access) for largish projects, by separating

This talk[1] made me rethink how to do OO with classes and
interfaces, but as he says at the end is the key take away.
I apply the approach more on the high level architecture of the
program [2] & [3, 4, 5].

Either way the talk is really good, I recommend whole heartily
you take the time to watch it.

Cheers, Jakob.

[1] http://www.infoq.com/presentations/It-Is-Possible-to-Do-OOP-in-Java
[2] https://github.com/VoltLang/Volta/blob/master/src/volt/interfaces.d
[3] https://github.com/Charged/Miners/blob/master/src/miners/classic/interfaces.d
[4] https://github.com/Charged/Miners/blob/master/src/miners/interfaces.d
[5] https://github.com/Charged/Miners/blob/master/src/charge/game/runner.d

>> One of the main selling points of the module system is to prevent exactly what you are proposing, so I think there must be a better solution.

> Please explain. Main points of module system is to avoid header compilation time hell and control access. I don't how this is relevant to the topic.

This is what I read when I first read about D, modules are supposed to be a way to get rid of the need for maintaining separate source files, which as you stated also has the desired side effect of getting rid of separate header files.

here's one source: http://dlang.org/overview.html

The proposal as I read it, moves us more backwards than forwards, and it seems there's a better way as I had described. If there's to be a solution, it should be a solution that retains one source file. If we need a separation, it should be automated to prevent manual duplication and maintenance hell.

> On Monday, 4 March 2013 at 06:06:14 UTC, Rob T wrote:
>> Manually maintaining a .di file is a bad idea for what should be obvious reasons
>
> No, they are not obvious at all, please explain.

I did not think that I would have to explain the difference between manually maintaining two separate source files containing manual duplication of code that must be kept in sync vs manually maintaining only one source file with no manual duplication of code.

--rt

On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
> +1_000_000_000
>
> Yes please!
> It's near impossible to get a brief overview of a class at a glance in D!
>
>

I agree it's very handy to get an overview of a class or struct or module interface, however I think that the IDE should deal with this problem rather than using a duplication of source code as a solution.

The relatively primitive IDE that I use allows me to at least perform function folding, which in some ways helps solve the problem, albeit in a poor way, but it hints that better tools can solve the problem rather nicely without a duplication of code.

--rt

On 3/5/13, Rob T <alanb@ucora.com> wrote:
> The relatively primitive IDE that I use allows me to at least perform function folding, which in some ways helps solve the problem, albeit in a poor way, but it hints that better tools can solve the problem rather nicely without a duplication of code.

Code folding is available in almost every text editor, the problem
(for me) is the indenting.