scope keyword - a maintenance nightmare?

[Sean Kelly]

Guenther Brunthaler wrote:
> 
> * While the closed source Digital Mars compiler really created small and nice executables, the GCC-backend created executables multiple times that size

Valid point, though this isn't really a problem with D.

> * There is is no equivalent to MODULA 2s "Definition Modules". While I think it is a good idea to get rid of C++'s primitive "header" files, there must still be some means of separating interface descriptions from the actual code. Otherwise, you always have to ship the complete source code to anyone who just wants to use some interface as a client. Consider writing a plugin for OpenOffice.org that way...

Sure there are.  In fact, DMD offers the -H option to generate header 
files during compilation.

> * Maintenance-Nightmare with "auto" (now "scope").

I'm not sure I understand, but more later I suppose.

> When checking http://www.digitalmars.com/d/class.html for the new "scope"-class feature in more detail, I unfortunately had to learn that only half of my critique on D's synchronous destructors has been rendered obsolete by the new D 2.0 design.
> 
> What they have actually done was renaming "auto" into "scope", and forcing to add the "scope" declarator to both the class declaration as well as to object variable definitions.

It is exactly the same in 1.0, unless I'm missing something.  The only 
change I am aware of regarding this was the switch from "auto" to 
"scope" as the qualifier to use.

> While this is clearly an improvement, because the compiler can now detect missing "scope" declarators in object variable definitions and give an error message, it still does not solve the problem that it is necessary to write "scope" at the object variable definitions.
> 
> This can and will become a problem in evolving projects.

How so?  Personally, I think that not requiring "scope" at the point of 
declaration would be more of a maintenance problem.  Without some sort 
of visual cue that a reference variable is scoped, it would be easy to 
unknowingly return references to destroyed objects from functions, etc.

> It is quite common to add functionality to classes later which no-one has thought of when they have been designed in the first place.

Certainly.  But it is generally a fundamental change in behavior to make 
a non-scoped class scoped.  Also, I don't believe it is always necessary 
to place the "scope" qualifier on the class definition.  In fact, I 
rarely use it (possibly a mistake on my part).

> As adding something as a logfile feature to a class in a well-co-ordinated way usually requires some cleanup to be done in the destructor (such as closing the logfile) and this cleanup should be done in a predictable manner, it is necessary to convert the non-"scope" class into a "scope"-class.

I disagree.  There are many instances where the lifetime of an object 
must be deterministic but must also exist beyond the scope of a function 
call.  The scope qualifier does not apply here.

> But in contrary to C++, it is not enough to add "scope" to the class declaration in D.
> 
> No, in addition to that, all the source files of all the 50 programmers in the project have to be scanned for object variables defined for this class, and "scope" has to be added to any such instances found.
> 
> Just consider the "fun" those programmers might have, especially in a distributed development scenario, when they note their code no longer compiles after each couple of updates they receive from the main version control repository, and forces them to add dozens of "scope" declarations to their variable definitions, because "scope" has been added to the declaration of some class they are using.
> 
> I consider such a situation to be a maintenance nightmare.

I think a greater maintenance nightmare would the the lack of "scope" at 
the point of declaration, as it would be likely to cause a segfault if 
the maintainer is not aware that a particular type is scoped.

> Another problem of D is inherent from its design decision to use garbage collection: As http://www.digitalmars.com/d/garbage.html states,
> Zitat:
> All threads other than the garbage collector thread must be halted while the collection is in progress.
> 
> In other words, even the most high-sophisticated multi-threaded web-server written in D must be expected to take a nap at any time - and all threads running will have to take a nap, too. Great - that was exactly what multi-threading was made for. :( And no-one can say how long this nap will actually take, because
> Zitat:
> 
> The time it takes for a collection to run is not bounded. While in practice it is very quick, this cannot be guaranteed.

This is true of the current garbage collector implementation.  There are 
real-time garbage collectors available which do provide guarantees about 
delay however.  That said, it's not entirely clear how easily such a GC 
would map into D.

> Such interruptions of normal service might be tolerable in many situations, but not in all.
> 
> D is therefore especially not well suited for real-time applications.

See above.  For what it's worth, the GCs to which I am referring are 
implemented for Java.

> Or let's put it the other way: D might be a valid competitor to JAVA, but it still has not got what it takes to replace C or C++ as system programming languages. It just takes more to challenge C++ than D can provide at the moment.

Since C++ will be adding garbage collection in the next iteration of its 
standard, I don't see its presence in D as a particularly strong 
argument for why D cannot compete with C++.


Sean