Jacob Carlborg schrieb: > On 10/11/09 20:58, Yigal Chripun wrote: >> On 11/10/2009 15:23, Ary Borenszweig wrote: >>> Walter Bright wrote: >>>> In my discussions with companies about adopting D, the major barrier >>>> that comes up over and over isn't Tango vs Phobos, dmd being GPL, >>>> debugger support, libraries, bugs, etc., although those are important. >>>> >>>> It's the IDE. >>>> >>>> So, while I'm not going to be writing an IDE, I figure that dmd can >>>> help. dmd already puts out .doc and .di files. How about putting out >>>> an xml file giving all the information needed for an IDE to implement >>>> autocompletion? There'd be one .xml file generated per .d source file. >>>> >>>> What do you think? >>> >>> What I think is that even with an xml representing the parse tree (maybe >>> with some semantic stuff resolved) it'll be still incomplete for a real >>> IDE (the kind of thing users expect from an IDE). You can see this >>> video, for example: >>> >>> http://www.youtube.com/watch?v=KQbTT605ags >>> >>> So you have: >>> >>> --- >>> module one; >>> >>> class Foo(T) { >>> static if (is(T == class)) { >>> T property; >>> } else { >>> T someMethod() { return T.init; } >>> } >>> mixin(guessWhat!(T)()); >>> } >>> --- >>> >>> You want to define an xml for that module that'll help IDEs. Can you >>> think what it'll look like? >>> >>> Now the user writes in another module: >>> >>> class Bar { >>> } >>> >>> void x() { >>> auto foo = new Foo!(Bar)(); >>> foo. <-- what does the IDE do here? >>> } >>> >>> Now, the correct thing for the IDE to do is to suggest the field "Bar >>> property". How can the IDE do that just with an xml? It can't. It need >>> to perform some kind of semantic anlysis to Foo's argument to see if >>> it's a class, match the static if in the template, replace template >>> parameters, etc. It also needs to evaluate the string mixin. >>> >>> Of course you could say "Bah, just show all the declarations inside the >>> template in the autocomplete", but that's wrong. That'll lead to files >>> that don't compile. You could ommit supporting autocompletion or other >>> nice features, but that's exactly the big features of D. If you don't >>> support that then it's like using Java or C# from within the IDE: you >>> could use the advanced features but the IDE won't help you. And in your >>> discussions with companies adopting D, I'm sure they were talking about >>> great IDEs like JDT Eclipse or Visual Studio, not just some tool that >>> helps you a little but not anymore when things get interesting. >>> >>> Oh, and you need to have some kind of semantic analysis to know the type >>> of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new >>> Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have: >>> >>> auto b = foo.property; >>> b. <-- and here? >>> // remember "property" is templated and depends on static analysis >>> // or the IDE could need to resolve alias this or other things >>> >>> So... my opinion (like some others, I see) is to either ask things to >>> the compiler directly (but here the compiler lacks some info, like exact >>> source range positions), or to have a compiler (not a full-blown one, >>> just the front-end) built into the IDE, and that's what Descent is. >>> Unfortunately Descent is sometimes slow, sometimes buggy, but that's >>> normal: just a few people develop and maintain it (so I can see a >>> similarity with dmd here, where each day I see two or three new bugs >>> reported). If more people were into it, more unit tests were written >>> into it and, most of all, more people would use it, it'll get better. >>> >>> Another problem that people see in Descent (maybe also JDT Eclipse and >>> Visual Studio0 is that it's huge, it consumes a lot of memory and they >>> don't want to open a huge tool just to hack some lines. My answer is: >>> memory performance can be improved (but not a lot), but since an IDE is >>> a huge tool it requires a lof from the computer. And an IDE is not meant >>> to be used to hack some lines, it's meant to help you write big project, >>> huge projects without getting lost in the amount of code. >>> >>> So my bet would be to start supporting an existing IDE that integrates a >>> compiler into it. Updating it is easy: just port the diffs between DMD >>> versions. It's a huge job for one or two people, but if a lot of people >>> were involved it's not that much. Of course I'd recommend you to try >>> Descent since I'm one of it's creators and I do believe it can get >>> pretty good. :-) >> >> well put. >> >> btw, given that we have a port of SWT for D, how hard would it be to >> create our own native D version of eclipse? > > Frank Benoit (who started DWT, the tango version) was think about this. > Quite a big part is already ported, SWT, JFace, Forms, OSGI and so on, > see: http://hg.dsource.org/projects/dwt2/file/88652073d1c2/ .
Sorry, OSGi is just dummy, to make other stuff compile.