On Thu, 11 Dec 2014 12:02:43 +0000 Tobias Pankrath via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 11 December 2014 at 11:46:50 UTC, ketmar via > Digitalmars-d wrote: > > > > you can't see how this can help 'cause we don't have such > > AST-companions yet. i can see how this will help 'cause i have > > alot of > > expirience with turbo/borland pascal and BlackBox Component > > Builder. > > think a-la BCB can be a killer app for D, but it's very hard to > > build > > it without good AST-companions. > > And we're back to parsing speed. nope. at least not more than in my "we don't need to generate native binaries" example. it's not about "code suggestions" at all. > So, using an preparsed ast yields me nothing > today, but might brake all the tools that work with object files. how can it break any tool? and what tool is going to break? it's incredibly easy to convert "precompiled module file" to ".o" file which ld wants, but not vice versa. > Giving the amount of manpower available, I'd say we have better > things to do. But I guess no one would mind if you just make it > happen. i'm slowly working on it. as i really want my component system to work into, i *have* to write all the things i need for it. yet i'm a lone developer with alot of other things to do, and any slight change in D frontend means that i have to change my code too. with "AST-companions" integrated into frontend it's much easier to keep such system alive, 'cause the one who changes frontend will fix the "companion generator" too. it's not that hard (we have to fix .di generators now, for example), but almost impossible for lone independend developer who have to do payed work for living. as i'm pretty sure that such work will never be integrated into mainline code, i'm just hacking it sometimes, but never tried to keep it up with DMD developement.
signature.asc
Description: PGP signature
