Proposed improvements to the separate compilation model

Vladimir Panteleev vladimir at thecybershadow.net
Sat Jul 23 16:21:35 PDT 2011


On Sun, 24 Jul 2011 01:47:32 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

>> Yes, neither of the above are "proper" solutions. But, unless I've lost
>> track of something, you're trying to justify a solid amount of work on
>> the compiler to implement the "proper" solution, when the above
>> alternatives are much simpler in practice. (If you have more
>> counter-arguments, I'd like to hear them.)
>
> I don't think at all these aren't proper. As I said, people are willing  
> to do crazy things to keep large projects sane. The larger question here  
> is how to solve a failure scenario, i.e. what can we offer that senior  
> engineer who fixes the build when the .di files are not in sync anymore.

OK. I'm not going to ask your estimates of how probable this is to happen  
in practice, and if it justifies the implementation effort of going into  
this direction, as I think I've fully elaborated my point already.

One thing that I should have mentioned before, is one of my reasons for  
this argument: the design for implementing verification of  
manually-maintained .di files has been discussed and published by D's  
creators, so now someone just needs to go and implement it. However, there  
is no discussion or consensus about improving .di-file generation. Even  
choosing the name of whatever attribute gets DMD to copy function bodies  
to .di files would be a start.

>>> But wait, there's less. The programmers don't have the option of
>>> grouping method implementations in a hierarchy by functionality (which
>>> is common in visitation patterns - even dmd does so). They must define
>>> one class with everything in one place, and there's no way out of that.
>>
>> Sorry, I don't understand this part. Could you elaborate?
>
> A class hierarchy defines foo() and bar(). We want to put all foo()  
> implementations together and all bar() implementations together.

Ah, so this is a new possibility created by the "method definitions  
outside a class" requirement. But how would this play with the module  
system? Would you be allowed to place method definitions in modules other  
than the class declaration?

-- 
Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net


More information about the Digitalmars-d mailing list