Saaa Wrote:

> Thats what you get with a systems programming language ; ) But I understand where you are coming from.

D is very flexible, everything that i want to do at the time, is possible to do with D.

I have only listed things that can be enhanced.

I used .NET for some utilities, (nothing big, and with Visual Basic), but it was surprised me the quick development that it provides.

"Fractal" <d294934@bsnow.net> wrote in message news:gtlihm$tt0$1@digitalmars.com...
>
> The namespaces: i used them with C++, and the idea of separation between the uses of types, makes a very good layout. Because some namespaces requires more types, always i write each class in separate files. D simply breaks it, making a big amount of lines for imports.
>

That is easy to work around. Instead of this (which doesn't work in D):

-------------------------------------
//File: foo/fooA.d
module foo;
class fooA {}

//File: foo/fooB.d
module foo;
class fooB {}

//File: foo/fooC.d
module foo;
class fooC {}

//File: main.d
import foo;
void main() {...}
-------------------------------------

Do this:

-------------------------------------
//File: foo/fooA.d
module foo.fooA;
class fooA {}

//File: foo/fooB.d
module foo.fooB;
class fooB {}

//File: foo/fooC.d
module foo.fooC;
class fooC {}

//File: foo/all.d
module foo.all;
public import foo.fooA;
public import foo.fooB;
public import foo.fooC;

//File: main.d
import foo.all;
void main() {...}
-------------------------------------

This works fine and does exactly what you want.

Also, there are tools (rebuild, bud) that you give *just* the main file, and they automatically find and compile all of files needed. (ie, "rebuild main.d" instead of "cpp main.c fooA.c fooB.c...etc..."). These tools would not be possible if D allowed you to split a module across multiple files.

> Templates: i dont use templates or mixins. they really confuses me and i think so that they only should be used for "array classes" or something similar.
>

You really should use them. If you don't, you will be writing A LOT of duplicate code.

> Foreach ranged: it cannot be added to D1? it simplies the life, and not breaks any existing code
>

There are a lot of features that could be added to D1 and people want added to D1. But that's not going to happen. That's what D2 is for. New features go into D2. If you want the new features, you should use D2.

> Tango and Phobos: Tango is good, but the File class makes more problems than it solves. And i dont like the Phobos design, but I really need the XML... just writing other API?
>

I agree, Tango's file routines are very confusing (or maybe just the documentation for Tango's file routines) and D1's Phobos is a mess. Hopefully this will all improve.

Nick Sabalausky wrote:
> -------------------------------------
> //File: foo/fooA.d
> module foo.fooA;
> class fooA {}
> 
> //File: foo/fooB.d
> module foo.fooB;
> class fooB {}
> 
> //File: foo/fooC.d
> module foo.fooC;
> class fooC {}
> 
> //File: foo/all.d
> module foo.all;
> public import foo.fooA;
> public import foo.fooB;
> public import foo.fooC;
> 
> //File: main.d
> import foo.all;
> void main() {...}
> -------------------------------------
> 
> This works fine and does exactly what you want.
> 

How well will this work if there is fairly tight coupling between these three classes?

Saaa wrote:
>> void main()
>> {
>> C c = new C();
>> I i = c;
> I didn't know an interface could hold the data of an class or am I seeing this wrong?

In this case, both c and i are pointers to the data.

Ellery Newcomer wrote:
> Nick Sabalausky wrote:
>> -------------------------------------
>> //File: foo/fooA.d
>> module foo.fooA;
>> class fooA {}
>>
>> //File: foo/fooB.d
>> module foo.fooB;
>> class fooB {}
>>
>> //File: foo/fooC.d
>> module foo.fooC;
>> class fooC {}
>>
>> //File: foo/all.d
>> module foo.all;
>> public import foo.fooA;
>> public import foo.fooB;
>> public import foo.fooC;
>>
>> //File: main.d
>> import foo.all;
>> void main() {...}
>> -------------------------------------
>>
>> This works fine and does exactly what you want.
>>
> 
> How well will this work if there is fairly tight coupling between these three classes?

Not well at all :-). Technically, it should work the same as if they were in the same module, but compiler bugs dealing with forward references keep this from happening. I think a while back there was a version of LDC that pretty much fixed forward reference issues, but it introduced a bunch of regressions.

Nick Sabalausky Wrote:

> "Fractal" <d294934@bsnow.net> wrote in message news:gtlihm$tt0$1@digitalmars.com...
> >
> > The namespaces: i used them with C++, and the idea of separation between the uses of types, makes a very good layout. Because some namespaces requires more types, always i write each class in separate files. D simply breaks it, making a big amount of lines for imports.
> >
> 
> That is easy to work around. Instead of this (which doesn't work in D):
> 
> -------------------------------------
> //File: foo/fooA.d
> module foo;
> class fooA {}
> 
> //File: foo/fooB.d
> module foo;
> class fooB {}
> 
> //File: foo/fooC.d
> module foo;
> class fooC {}
> 
> //File: main.d
> import foo;
> void main() {...}
> -------------------------------------
> 
> Do this:
> 
> -------------------------------------
> //File: foo/fooA.d
> module foo.fooA;
> class fooA {}
> 
> //File: foo/fooB.d
> module foo.fooB;
> class fooB {}
> 
> //File: foo/fooC.d
> module foo.fooC;
> class fooC {}
> 
> //File: foo/all.d
> module foo.all;
> public import foo.fooA;
> public import foo.fooB;
> public import foo.fooC;
> 
> //File: main.d
> import foo.all;
> void main() {...}
> -------------------------------------
> 
> This works fine and does exactly what you want.
> 


The namespaces is better !!!

Liang Du wrote:
> Nick Sabalausky Wrote:
> 
>> "Fractal" <d294934@bsnow.net> wrote in message news:gtlihm$tt0$1@digitalmars.com...
>>> The namespaces: i used them with C++, and the idea of separation between the uses of types, makes a very good layout. Because some namespaces requires more types, always i write each class in separate files. D simply breaks it, making a big amount of lines for imports.
>>>
>> ...
>>
>> This works fine and does exactly what you want.
>>
> 
> The namespaces is better !!!

That's debatable.  The hateful thing about namespaces is that they give you absolutely ZERO clue as to where any particular thing is coming from.

If I see "tango.io.device.File", I know exactly where the source for that module is.

  -- Daniel

Hello Saaa,

> mixins are just code in string form, right?

No that's "mixin(string)", there is also "mixin Template!();" that plops the template content into its scope.

Hello Fractal,

> Templates: i dont use templates or mixins. they really confuses me and
> i think so that they only should be used for "array classes" or
> something similar.


I'm biased (as I love playing with them) but templates can be used for a LOT more than that. Most of the time the end user doesn't need to understand how it works, just how to use it and that generally isn't hard to figure out.

Ah, ok thanks.

I should really start reading about those template things :)

> Hello Saaa,
>
>> mixins are just code in string form, right?
>
> No that's "mixin(string)", there is also "mixin Template!();" that plops the template content into its scope.
>
>