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