questions about module names and D 2.0 compatibility

schveiguy Joined: 08/02/07 Posts: 128

Posted: 09/17/07 17:48:50 Hi, I have two questions regarding tango: First, one of the confusing aspects of Tango is the module names all being the same or similar to the class names contained within the file. For example, the Conduit class is not tango.io.Conduit, but tango.io.Conduit.Conduit. I sort of understand the reasoning behind doing it this way, because D only allows you one file per module declaration, but has there been any effort to either: Change the way D imports modules (preferred) Come up with module names that are not the same as class names The reason I bring this up is because it is especially confusing to java developers. i.e.: import tango.io.Conduit; Conduit x = ...; A Java developer looks at this and says "I imported the *class* tango.io.Conduit", when in fact, they are loading a header file that describes the class tango.io.Conduit.Conduit. The point really becomes confusing in instances such as tango.text.convert.Integer: import Integer = tango.text.convert.Integer; Second question, I know that tango has avoided being compatible with D 2.0 because it is a changing beast. However, are the changes so vast that tango cannot keep up with them? I would like to try out some of the changes in the language that are ongoing (const comes immediately to mind), but as a tango user, I am stuck with D 1.0 until D 2.0 is released. My question is simply, is it a principle thing, where you don't want to base a library on an unreleased language, or is it a effort thing, where it would be too much effort to change all the tango code, and therefore not worth it since D 2.0 is changing? I seem to recall reading that phobos had little or no changes when porting to D 2.0... -Steve

Author

Message

larsivi Joined: 03/27/04 Posts: 614

Posted: 09/17/07 18:13:48 1) Regarding module and class names In Java this is not a problem, because a module/file is a class. To not have a one-to-one relationship is not allowed. In D, a module may not need to have a class at all, or it can have several. This is why importing a module is not the same as importing a class in Java. From a design perspective, it very often makes sense to keep it to one class per module, and then to have the class be named differently than the module itself would also be confusing (unless you go for the lowercase module/uppercase class solution, which the bigger C++ libraries seems to be moving from too (at least Qt)). To provide the same D functionality and change the import system to make this "easier" would probably only lead to corner cases and confusing rules, although several have tried to find better solutions (without success so far). If the language is improved in this respect, or some other solution is found, we may consider it, but I think we're pretty close to an optimal solution. 2) Regarding 2.0 compatibility It is mostly a workload thing. As long as D 2.0 is not stable, we are obliged to keep Tango for D 1.0 up to date. Thus we would end up with two branches, and this quite soon becomes a maintainance nightmare. There is also the likelihood of quite a bit of work just to get Tango working with D 2.0, especially if new features like const are going to be used like they should be. This don't mean that we are not interested in hosting patches or branches from people willing to make such an effort at this point, though. This far, I don't think anyone have stepped up for such a task.