Jarrett Billingsley wrote:
> On Sat, Feb 28, 2009 at 11:05 AM, Yigal Chripun<yigal100@gmail.com>  wrote:
>> I agree with the above but there is still a small issue here:
>> A module is a single file and when you have several large classes that are
>> tightly coupled you can get a very big file with thousands of lines. what if
>> i want to put each class in its own file?
>> besides, the notion of a module is somewhat redundant - it's functionally a
>> static struct.
>>
>> this is related to D's compilation model which is copied from C/C++ and it
>> seems to me that this model is outdated. C#'s model of assemblies and
>> metadata seems more capable. for instance there's no need for header files,
>> that info is stored in the metadata of the assembly.
>>
>
> Preciiiisely.  I've been toying with the concept of a compiler which
> doesn't actually emit object files until it has to link its code into
> some form of executable.  Instead it produces these sort of
> platform-independent internal representation files, which can contain
> all the metadata and symbol information needed.  They can be as small
> as a single module or as large as an entire multi-level package.  It
> sounds a lot like the model C# has adopted.

I also think that source code organization should be orthogonal to the organization of the deployment executables (assemblies in .net)
something simillar to namespaces in C#.

other useful metadata to include in those files is the documantation and versioning info.

On 2009-02-28 14:54:26 +0100, Christopher Wright <dhasenan@gmail.com> said:

> Lutger wrote:
>> grauzone wrote:
>> 
>>> Lars Ivar Igesund wrote:
>>>> Eldar Insafutdinov wrote:
>>>> 
>>>>> We faced a bug that module static constructors don't work with cyclic
>>>>> imports. Currently it's fixed with a dirty hack which is not really
>>>>> acceptable. Is there any chance for this to be fixed?
>>>> IMO it is the cyclic import that is the bug ;)
>>> Maybe all cyclic dependency bugs are on purpose, to teach people not to use this evil D feature? Yeah, that must it be. I can't explain why else these bugs/issues aren't fixed, and why people only reply with incredibly useful statements like "but you shouldn't use this feature anyway!".
>>> 
>>> Broken features should be either fixed or removed. This half-assedness about it isn't really going to help D.
>> 
>> Well it's about cyclic dependency of initialization via module constructors only right? Cyclic imports in general aren't (supposed to be) broken, nor are module constructors.
>> 
> 
> And in point of fact, you can modify the runtime so it will not throw exceptions on cyclic dependencies:
> 
> Index: genobj.d
> ===================================================================
> --- genobj.d    (revision 4339)
> +++ genobj.d    (working copy)
> @@ -1098,11 +1098,7 @@
>           if (m.ctor || m.dtor)
>           {
>               if (m.flags & MIctorstart)
> -            {   if (skip || m.flags & MIstandalone)
> -                    continue;
> -                throw new Exception( "Cyclic dependency in module " ~ (from is null ? "*null*" : from.name) ~ " for import " ~ m.name);
> -            }
> -
> +               continue;
>               m.flags |= MIctorstart;
>               _moduleCtor2(m,m.importedModules, 0);
>               if (m.ctor)
> 
> This opens you up to certain bugs, but they should be relatively rare.
> 
> I've tried it, and it appears to work.

Tango has it (thanks to lindquist) your change removes it :)

Yigal Chripun wrote:
> this is related to D's compilation model which is copied from C/C++ and it seems to me that this model is outdated. C#'s model of assemblies and metadata seems more capable. for instance there's no need for header files, that info is stored in the metadata of the assembly.

D can do the same thing - it can use the source of the module directly, or it can use a hand-generated 'header' file, or an automatically generated 'header' file. The latter is semantically indistinguishable from compiling the source module to a "metadata" file.

I originally considered having D write such a "metadata" file, until I realized I didn't have to invent a format and a writer and reader for that format. I could just use the D source code notation as a "metadata" file and reuse the existing code.

Yigal Chripun wrote:
>> On Sat, Feb 28, 2009 at 11:05 AM, Yigal Chripun<yigal100@gmail.com> wrote:
>>> I agree with the above but there is still a small issue here:
>>> A module is a single file and when you have several large classes
>>> that are
>>> tightly coupled you can get a very big file with thousands of lines.
>>> what if
>>> i want to put each class in its own file?
>>> besides, the notion of a module is somewhat redundant - it's
>>> functionally a
>>> static struct.

You can do this with mixins or aliases.

Honestly, something I'd like to see is to extend the import syntax to allow you to import symbols from other symbols.  For example:

> module foo;
>
> struct bar
> {
>   static void baz();
> }

> module main;
>
> import foo.bar;
>
> void main() { baz(); }

>>> this is related to D's compilation model which is copied from C/C++
>>> and it
>>> seems to me that this model is outdated. C#'s model of assemblies and
>>> metadata seems more capable. for instance there's no need for header
>>> files,
>>> that info is stored in the metadata of the assembly.

Given that D name mangling contains most if not all of a function's interface, it sometimes makes me wonder why we can't just import a .lib file.

Heck, stick an extra symbol on the end called _D_Interface if you must. :)

> I also think that source code organization should be orthogonal to the organization of the deployment executables (assemblies in .net) something simillar to namespaces in C#.

There are times where I hate this.  The problem is that this seems to encourage very flat hierarchies in .NET code, with everything jammed together.  What really exacerbates the situation is that namespaces can be added to by any library at any time.

For example, I had some code in C#, and I couldn't for the life of me figure out what I was supposed to link to.  Because the examples had multiple libraries all dumping their stuff into the same namespace, it was impossible to work out where any given symbol was coming from.

I ended up having to manually go through every goddamn library with the object browser to figure it out.

Enforcing the module<->file thing can be annoying at times, but nowhere near as bad as having no indication whatsoever where something is defined.

  -- Daniel

Walter Bright wrote:
> Yigal Chripun wrote:
>> this is related to D's compilation model which is copied from C/C++ and it seems to me that this model is outdated. C#'s model of assemblies and metadata seems more capable. for instance there's no need for header files, that info is stored in the metadata of the assembly.
> 
> D can do the same thing - it can use the source of the module directly, or it can use a hand-generated 'header' file, or an automatically generated 'header' file. The latter is semantically indistinguishable from compiling the source module to a "metadata" file.
> 
> I originally considered having D write such a "metadata" file, until I realized I didn't have to invent a format and a writer and reader for that format. I could just use the D source code notation as a "metadata" file and reuse the existing code.

The D system has a major limitation, though -- you can't split the source for a module across multiple files. Which pushes you towards enormous source files. It's more restricted than both C# and C++ in this respect.

On Sun, Mar 1, 2009 at 10:16 AM, Don <nospam@nospam.com> wrote:
>
> The D system has a major limitation, though -- you can't split the source for a module across multiple files. Which pushes you towards enormous source files. It's more restricted than both C# and C++ in this respect.
>

Yeah.  Imagine if DMDFE were written in D; how big would those modules have to be?

Jarrett Billingsley wrote:
> On Sun, Mar 1, 2009 at 10:16 AM, Don <nospam@nospam.com> wrote:
>> The D system has a major limitation, though -- you can't split the source
>> for a module across multiple files. Which pushes you towards enormous source
>> files. It's more restricted than both C# and C++ in this respect.
>>
> 
> Yeah.  Imagine if DMDFE were written in D; how big would those modules
> have to be?

The current organization of DMDFE is totally inconducive to D's module system, which I find ironic.

Eldar Insafutdinov wrote:
> It didn't take very long after previous post to make a first
> implementation of signals and slots(thanks to great people from #d)
> which means that you can actually start doing something useful. 0.1
> is probably most suitable tag for this release. Again - see tutorials
> for how to use signals.

I read on http://code.google.com/p/qtd/ the following:


"QtD requires tango. Those who use phobos should try tangobos or modify qtd(that should not be very difficult)."


I bet quite some of the non-Tango users ignore QtD because they don't want to install Tango just for one thing.

If you can find a Phobos user who has done this "not very diffcult" QtD modification, he might write a short description. And a link to that could be on the page, next to the sentence.


Even better would of course be to make QtD work with both already.

Georg Wrede Wrote:

> Eldar Insafutdinov wrote:
> > It didn't take very long after previous post to make a first implementation of signals and slots(thanks to great people from #d) which means that you can actually start doing something useful. 0.1 is probably most suitable tag for this release. Again - see tutorials for how to use signals.
> 
> I read on http://code.google.com/p/qtd/ the following:
> 
> 
> "QtD requires tango. Those who use phobos should try tangobos or modify qtd(that should not be very difficult)."
> 
> 
> I bet quite some of the non-Tango users ignore QtD because they don't want to install Tango just for one thing.
> 
> If you can find a Phobos user who has done this "not very diffcult" QtD modification, he might write a short description. And a link to that could be on the page, next to the sentence.
> 
> 
> Even better would of course be to make QtD work with both already.
> 

of course once there is somebody to do this job, it will appear in repos. Moreover there will be starting a job to port it to D2. Most probably there won't be D1+phobos support. I don't use phobos myself and the trend is that some projects I like use tango. DWT is one of them and it also uses tango. So the main concentration will be on D1-tango and D2-phobos I guess.

On Fri, 06 Mar 2009 18:34:19 +0200, Georg Wrede <georg.wrede@iki.fi> wrote:

>Eldar Insafutdinov wrote:
>> It didn't take very long after previous post to make a first implementation of signals and slots(thanks to great people from #d) which means that you can actually start doing something useful. 0.1 is probably most suitable tag for this release. Again - see tutorials for how to use signals.
>
>I read on http://code.google.com/p/qtd/ the following:
>
>
>"QtD requires tango. Those who use phobos should try tangobos or modify qtd(that should not be very difficult)."
>
>
>I bet quite some of the non-Tango users ignore QtD because they don't want to install Tango just for one thing.
>
>If you can find a Phobos user who has done this "not very diffcult" QtD modification, he might write a short description. And a link to that could be on the page, next to the sentence.
>
>
>Even better would of course be to make QtD work with both already.

I'm planning to make it work with D2 sooner or later. No plans for D1+phobos.