dvm (Was: denv - D version of rbenv)

[Nick Sabalausky]

"Jacob Carlborg" <doob at me.com> wrote in message 
news:jo1jnt$1vfl$1 at digitalmars.com...
>> Last time it was brought up, I was unsure of quite what you had in mind. 
>> I
>> was under the impression that you wanted to redesign the whole way the
>> command system *worked*. It's occurred to me that's maybe not what you
>> meant? Were you thinking that the *system* of commands would work the 
>> same
>> way as now, but just some commands/subcommands need to be moved around, 
>> the
>> stuff that's kind of an ugly "internal psuedo-command" should be promoted 
>> to
>> a true command/subcommand, etc?
>
> I was mostly thinking of how the code is structured internally. Basically 
> nothing would be changed from a user's point of view.
>
> What I don't like is that all functionality is implemented in the command 
> classes. The command classes should only handle the actual command and the 
> flags for that given command. Then it should delegate to other classes for 
> functions.
>
> The "install" command is a perfect example of this. Currently the Install 
> class inherits from Fetch, which is so wrong. It just does that to inherit 
> the implementation, it's not an actual subtype. What should have been done 
> is something like this (in some kind of pseudo code) :
>
> class FetchCommand
> {
>     void execute ()
>     {
>         auto fetcher = new Fetcher;
>         auto result = fetcher.fetch(args ...);
>         store(result);
>     }
> }
>
> class InstallCommand
> {
>     void execute ()
>     {
>         auto fetcher = new Fetcher;
>         auto result = fetcher.fetch(args ...);
>
>         auto installer = new Installer;
>         installer.install(result);
>     }
> }
>
> You can have a look at how Orbit it's structured as well. Structuring the 
> code like this will also make it usable as a library (don't know if that 
> would be useful in this case).
>

Ah, ok, I see now.

> What should be changed from a user's point of view is that flags specific 
> to a command should only be available to that command and not globally.
>

Totally agree.

> I was also hoping to factor out any compiler specific code in it's own 
> classes/functions. This would make it possible handle other compilers like 
> GDC, LDC and SDC. Although I don't think they provide pre-compiled 
> binaries in the same way as DMD does.
>

Probably a good idea. Having support for those other compilers would be 
fantastic.