On Tuesday, 5 March 2013 at 18:16:41 UTC, Dmitry Olshansky wrote:
>
> Leverage UDAs ?
>

Yes that's one possible method, tagging the interface with recognized attributes that guide the generation of the .di files. If the generation is smart enough that we can do without, even better.

The other need expressed in here is to have a means to benefit from a separation of interface from implementation inside the source base. I'll admit that bundling the two together is somewhat of a pain as it can hide away the interface. However I wonder if this is not best served through automatic documentation, ie, if the .di generation can figure out the interface, then why can't DDoc do it too? Then again, this may be more of a coding convenience issue more than a documentation issue, so I'm not strongly opposed to separating interface from implementation, rather my main concern was seeing manual maintenance of .di files being taken seriously. From my POV it's akin to having to hex edit your .o files to keep them in sync with source code changes.

If there's to be a method of interface-implementation separation, I think whatever is devised should minimize code duplication as much as possible, and the .di files should always be generated and maintained automatically.

--rt

On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
> Perhaps then, what I think is the most significant point of all is being missed. I can see a very clear reason why in terms of source code, the interface and implementation must not be be separated. Automated .di generation is a means to solve the need for separation when distributing libraries, whoever what goes in the .di should not be considered as your "source code" because it should be auto generated from the source (eg your .o files are not source code in the same way). I

I agree with Rob T on this point. Being free from the burden of maintaining an interface file was one of the selling points of D vs. C++ for me - repeating the same changes over and over in the .cpp and .h file was a pointless distraction and strain on my productivity, especially during prototyping.

Even though the feature, if introduced, will be optional, sooner or later it will end up in a library (likely, written by a misguided programmer coming from C++), and I will have to debug it - so I don't consider "don't use it if you don't like it" a real argument.

Also, I don't think that we should consider that a class declaration is the same thing as the class interface - for the simple reason that a class declaration must also contain private fields and methods. Having to recompile half of my program just because of a signature change in a class's private method makes no sense, and is the reason why hacks like PImpl emerged.

On Tuesday, 5 March 2013 at 18:00:59 UTC, H. S. Teoh wrote:
[...]
>
> I've actually seen (and fixed) a case of two C functions that were
> declared with the same name in two different libraries, and in one
> module, the wrong library was linked in, thus linking the call to the
> wrong function, causing strange runtime problems that no amount of
> staring at the source code would reveal the reason for. The #include was
> perfectly correct; but the problem was that the declaration was detached
> from the implementation, so the compiler has no way to check for this
> kind of problem.
>

I have been the victim of this sort of insanity enough times to never want to have to suffer through it again, that's why I'm taking the time to make a case against manual .di maintenance.

Note that one of the main points Andrei wanted to address is the desire to prevent unnecessary recompilations if the interface does not change despite the implementation changing. Such a thing can possibly be achieved by specifying to the compiler a path where the .di files are located, the compiler can search and parse through the files for matching module names (the files may be named differently than the associated module) and compare if the interface has changed or not, if not then do not overwrite with a fresh copy.

--rt

On Tuesday, 5 March 2013 at 20:40:41 UTC, Vladimir Panteleev wrote:
>
> Also, I don't think that we should consider that a class declaration is the same thing as the class interface - for the simple reason that a class declaration must also contain private fields and methods. Having to recompile half of my program just because of a signature change in a class's private method makes no sense, and is the reason why hacks like PImpl emerged.

Yes I fully agree with that point. D should be adjusted to solve the problem since it makes working on large projects much more practical.

--rt

On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
> On Tuesday, 5 March 2013 at 19:14:08 UTC, Dicebot wrote:
>>
>> Do you consider necessity to duplicate method signature when overriding in descendant to be a significant code duplication too? Because I fail to see the difference in this two cases.
>
> I think there is a difference. For example the compiler will complain when there's a typo, as opposed to getting obfuscated linker errors. No matter if there *is* a sane way to prevent duplication of function overrides, then I'll support it over duplication. This is a common concept, you should *allays* want to avoid unnecessary duplications as every line of extra code you add will exponentially increase the amount of effort required to maintain bug free code.

As far as I get spirit of this proposal, compiler should do the very same checks and complain on mismatch between interface and implementation. Because it knows it is his interface, contrary to C. And there is no sane way to avoid it in the same sense as with inheritance - if you want to keep sync between entities in two places, some duplication is inevitable. And that is acceptable if it is minimal and not error-prone (== verified by compiler).

>> I do not object better automatic .di generation, that is good for sure. But I do object opposing proposed simplification of going other way around. Why do you call it "regressing" if it changes nothing in current behavior? It will considerably improve my usage scenario (start with .di, write .d after) and won't affect yours (write only .d)
>
> You'll need to explain more what you are trying to accomplish because I sincerely cannot understand what you are arguing for. Why would anyone ever want to start off with a .di interface?

> ...

Ye, probably this is the root cause of disagreement. My use case is not closed-source distribution, it is more of design philosophy/approach for large projects.

This is somewhat similar to normal interfaces - it helps abstraction to have a single place with all information about your module someone out there needs to know : public interface, definitions and documentation. Not because your implementation source is closed in licensing sense, but because that is the very point of abstraction to make your implementation a black-box so it may change in any possible way.

It sometimes considered a good approach (which I agree with) to start writing module from public interface, before you actually know anything about your upcoming implementation and your thinking is closer to someone who will later use this module. So you write down this single file that can be thrown at other programmer with words "Here. It is all you need to know about my module to use it. Don't even try to learn more". Then, once you are satisfied, actual implementation starts.

Can it be generated? Somewhat. But as this is intended for human reading, I'll need to verify result anyway with all attention. To make sure function definition order is as planned, no extra functions are made public by an accident, documentation formatting fits and so on. Especially verifying no extra stuff leaked there is hell of a work, much more than any definition duplication.

And than there is also other way around. Lets pretend you have got your public interface design in same .d file and then started digging all the real stuff. It is so easy to forget what was intended to be known by outside world and tweak definitions here and there a bit, leaking implementation details in process. When interface is separate, you need a clear conscious effort to change anything about it.

Funny thing, there have been link to a cool presentation about OOP and ADT somewhere in this newsgroup (http://www.infoq.com/presentations/It-Is-Possible-to-Do-OOP-in-Java) and author there actually mentions C separation of header and translation unit as a good example of OOP, as opposed to Java. Ironically but pretty damn seriously.

tl;dr: I see no additional error-prone cases with this feature if implemented with proper compiler verification but it helps for maintenance and improves learning curve of project source.

On Tuesday, 5 March 2013 at 20:47:11 UTC, Rob T wrote:
> On Tuesday, 5 March 2013 at 20:40:41 UTC, Vladimir Panteleev wrote:
>>
>> Also, I don't think that we should consider that a class declaration is the same thing as the class interface - for the simple reason that a class declaration must also contain private fields and methods. Having to recompile half of my program just because of a signature change in a class's private method makes no sense, and is the reason why hacks like PImpl emerged.
>
> Yes I fully agree with that point. D should be adjusted to solve the problem since it makes working on large projects much more practical.
>
> --rt

That I agree for sure, too. That may be not that trivial, but it is a big whole in abstraction model of C++-like languages.

On Tuesday, 5 March 2013 at 20:40:41 UTC, Vladimir Panteleev wrote:
> On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
>> Perhaps then, what I think is the most significant point of all is being missed. I can see a very clear reason why in terms of source code, the interface and implementation must not be be separated. Automated .di generation is a means to solve the need for separation when distributing libraries, whoever what goes in the .di should not be considered as your "source code" because it should be auto generated from the source (eg your .o files are not source code in the same way). I
>
> I agree with Rob T on this point. Being free from the burden of maintaining an interface file was one of the selling points of D vs. C++ for me - repeating the same changes over and over in the .cpp and .h file was a pointless distraction and strain on my productivity, especially during prototyping.
>
> Even though the feature, if introduced, will be optional, sooner or later it will end up in a library (likely, written by a misguided programmer coming from C++), and I will have to debug it - so I don't consider "don't use it if you don't like it" a real argument.
>
> Also, I don't think that we should consider that a class declaration is the same thing as the class interface - for the simple reason that a class declaration must also contain private fields and methods. Having to recompile half of my program just because of a signature change in a class's private method makes no sense, and is the reason why hacks like PImpl emerged.

And what issues may arise exactly? So far all stuff mentioned is C-approach specific, everyone is speaking about possible problems without specific example.

On Tuesday, 5 March 2013 at 20:51:02 UTC, Dicebot wrote:
> As far as I get spirit of this proposal, compiler should do the very same checks and complain on mismatch between interface and implementation. Because it knows it is his interface, contrary to C. And there is no sane way to avoid it in the same sense as with inheritance - if you want to keep sync between entities in two places, some duplication is inevitable. And that is acceptable if it is minimal and not error-prone (== verified by compiler).

Yes complier verification has to be done between interface and the implementation. The ,di file however should be auto generated and not considered a part of the source code. The only verification I could think of for a .di file, is to make sure that the ,di is not overwritten if there's no change to the interface so as to prevent triggering unnecessary rebuilds. Such a thing would be useful for large projects.

>> You'll need to explain more what you are trying to accomplish because I sincerely cannot understand what you are arguing for. Why would anyone ever want to start off with a .di interface?
>
>> ...
>
> Ye, probably this is the root cause of disagreement. My use case is not closed-source distribution, it is more of design philosophy/approach for large projects.
[snip]

Perhaps the idea of allowing separate interfaces for modules is what you are asking for. I don't oppose adding better interface abilities to D, and from the discussion in here I think valid arguments were made in favor of that. For your use case, you should get what you want if real interfaces were added to D, so if you are to make a case to meet your specific needs, then please push for adding better interfaces to D, rather than support suggestions that we can solve interface problems through direct manual maintenance of .di files.

--rt

On Tuesday, 5 March 2013 at 00:41:23 UTC, Andrej Mitrovic wrote:
>  3/5/13, Rob T <alanb@ucora.com> wrote:
>> In that case it would be nice to avoid most of the class name
>> duplication, that's one of the things I really disliked about C++.
>
> I guess you meant:
>
> class A
> {
>     class B;
> }
>
> class A.B
> {
>     // implementation
> }
>
> Ideally both styles would be supported.

Actually I had meant this instead, which reduces duplication

class A
{

}

class A.B
{
    // implementation
}

There should be no need to define class B inside class A, because the compiler can easily know that class A.B means that B is included inside A. It adds on some more work for the compiler, but it's doable.

However, I'm not so sure how useful such a thing really is if all it does is save on adding indentations for sub classes.

--rt

On 3/6/13, Rob T <alanb@ucora.com> wrote:
> Actually I had meant this instead, which reduces duplication
>
> class A
> {
>
> }
>
> class A.B
> {
>      // implementation
> }

I don't like this idea at all. It again makes the class unreadable because you can't tell at a glance what it contains.