FunkyM escribió:
> 
> I still have trouble to fully understand why you check gtk vs gtk.gtk.
> Assuming you try to point out a possible problem when multiple package levels
> have the same name, after having name mangling applied.
> 

Consistency. In /gtk.d you're asking the compiler to treat it just as gtk, but in /gtk/window.d you're asking it to be gtk.window. So, if the rules are not clearly defined, the compiler could think that /gtk.d is gtk.gtk.

> The compiler generates (I made a simple test to verify) the one dependent on
> your qualification like this:
> 
> /gtk.d        -> _D3gtk5fooi
> /gtk/gtk.d    -> _D3gtk3gtk5fooi
> /gtk/window.d -> _D3gtk5fooi (since the file used "module gtk;")
> 
> That does not look problematic to me regarding locating which member belongs to
> which package? (Did I overlooked something?)
> 
> Now I think all the implementation seems more and more trivial and somehow
> reflects the "already indirectly supported" stuff showing up.
> 

I'm not really sure about what you did because you're using "module" in a different way than it's supposed to be right now.

Anyway, try this: add /gtk/button.d (or whatever) and also use in it "module gtk;". Now try to compile button and window, and pretty sure the compiler will give you an error message (module gtk is multiple defined, or something like that).

> --- Martin Szulecki



-- 
Carlos Santander Bernal

FunkyM wrote:
> 
> Yeah, infact it is a basic change mainly on the "module" keyword. My "extended"
> explaination might be a bit too much information on one shot.
> 
> Right now you for a file "/foo/bar.d" you would have to write "module foo.bar;"
> and you can NOT have a file "/foo.d" with "module foo;".
> 
> These changes make it possible to say "module foo;" in "/foo/bar.d" and use
> "/foo.d" with "module foo;" which results in "merging" the two scopes.
> 

What happens when both "module foo;"'s have module constructors/destructors ?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

In article <e42g7v$2pfk$1@digitaldaemon.com>, Bruno Medeiros says...
>
>FunkyM wrote:
>> 
>> Yeah, infact it is a basic change mainly on the "module" keyword. My "extended" explaination might be a bit too much information on one shot.
>> 
>> Right now you for a file "/foo/bar.d" you would have to write "module foo.bar;" and you can NOT have a file "/foo.d" with "module foo;".
>> 
>> These changes make it possible to say "module foo;" in "/foo/bar.d" and use "/foo.d" with "module foo;" which results in "merging" the two scopes.
>> 
>
>What happens when both "module foo;"'s have module constructors/destructors ?
>

Not absolutely sure about that.

If the changes for the "solution" would get applied, I guess by roughly judging from the DMD frontend sources, the static constructors/destructors would get called per "module file".

Their order in that case remains: "The order of static initialization is implicitly determined by the import declarations in each module.", as from D language spec and judged by DMD frontend sources. (In above scenario you still write "import foo, foo.bar;")

I am trying myself in altering the DMD frontend adding my proposal in order to strive upon all impacts of a change. This is sure one to be discussed/defined.

--- Martin Szulecki

Bruno Medeiros wrote:
> FunkyM wrote:
>>
>> Yeah, infact it is a basic change mainly on the "module" keyword. My "extended"
>> explaination might be a bit too much information on one shot.
>>
>> Right now you for a file "/foo/bar.d" you would have to write "module foo.bar;"
>> and you can NOT have a file "/foo.d" with "module foo;".
>>
>> These changes make it possible to say "module foo;" in "/foo/bar.d" and use
>> "/foo.d" with "module foo;" which results in "merging" the two scopes.
>>
> 
> What happens when both "module foo;"'s have module constructors/destructors ?

My guess is that one of the ctor/dtor pairs would either be thrown out during library assembly (or linking), or that a duplicate symbol error would be generated.  I think the 'ld' tool on Linux could be made to do either, but I'm not sure how flexible the Windows tools are.



Sean

Bruno Medeiros wrote:
> FunkyM wrote:
> 
>>
>> Yeah, infact it is a basic change mainly on the "module" keyword. My "extended"
>> explaination might be a bit too much information on one shot.
>>
>> Right now you for a file "/foo/bar.d" you would have to write "module foo.bar;"
>> and you can NOT have a file "/foo.d" with "module foo;".
>>
>> These changes make it possible to say "module foo;" in "/foo/bar.d" and use
>> "/foo.d" with "module foo;" which results in "merging" the two scopes.
>>
> 
> What happens when both "module foo;"'s have module constructors/destructors ?
> 

Why not just execute both?  Almost makes me wonder, why not have multiple module ctors/dtors in the same file?  I tend to use them as a convenient way to execute starttime code.  It could be advantageous to be able to place pieces starttime code next to logically related runtime code, instead of lumping it all together at the top of the file or some such.

Chad J wrote:
> Bruno Medeiros wrote:
>> FunkyM wrote:
>>
>>>
>>> Yeah, infact it is a basic change mainly on the "module" keyword. My "extended"
>>> explaination might be a bit too much information on one shot.
>>>
>>> Right now you for a file "/foo/bar.d" you would have to write "module foo.bar;"
>>> and you can NOT have a file "/foo.d" with "module foo;".
>>>
>>> These changes make it possible to say "module foo;" in "/foo/bar.d" and use
>>> "/foo.d" with "module foo;" which results in "merging" the two scopes.
>>>
>>
>> What happens when both "module foo;"'s have module constructors/destructors ?
>>
> 
> Why not just execute both?  Almost makes me wonder, why not have multiple module ctors/dtors in the same file?  I tend to use them as a convenient way to execute starttime code.  It could be advantageous to be able to place pieces starttime code next to logically related runtime code, instead of lumping it all together at the top of the file or some such.

No reason not to.  Multiple unittests are already allowed.


Sean

On Sat, 13 May 2006 09:53:10 +1000, Sean Kelly <sean@f4.ca> wrote:

> Chad J wrote:
>> Bruno Medeiros wrote:

...
>>>
>>> What happens when both "module foo;"'s have module constructors/destructors ?

>>  Why not just execute both?  Almost makes me wonder, why not have multiple module ctors/dtors in the same file?
...

> No reason not to.  Multiple unittests are already allowed.

There are already precedents for this type of coding. Not only the 'unittest' idea but 'scope()' also allows us to physically separate code that is executed linearly. So the concept is not foreign to D or Walter.

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:
> 
> 
> There are already precedents for this type of coding. Not only the  'unittest' idea but 'scope()' also allows us to physically separate code  that is executed linearly. So the concept is not foreign to D or Walter.
> 

While I'm at it, I'd also like to see the ability to set a variable to the result of some function at starttime, like so:

int[] squares = initSquares();

int[] initSquares()
{
    int[] result = new int[20];
    for ( int i = 0; i < 20; i++ )
        result[i] = i * i;
    return result;
}

void main()
{
    char[] testStr;
    for ( int i = 0; i < squares.length; i++ )
        testStr ~= toString(i)~" squared is "~toString( squares[i] ) ~ "\n";

    writefln( testStr );
}

This is something I used in C# and enjoyed.  Any particular reason this doesn't exist already?  Maybe I am supposed to write my code a different way, if so please enlighten me.  My current workaround is to use static ctors, but that doesn't seem as readable to me.

Chad J wrote:
> Derek Parnell wrote:
>>
>>
>> There are already precedents for this type of coding. Not only the  'unittest' idea but 'scope()' also allows us to physically separate code  that is executed linearly. So the concept is not foreign to D or Walter.
>>
> 
> While I'm at it, I'd also like to see the ability to set a variable to the result of some function at starttime, like so:
> 
> int[] squares = initSquares();
> 
> int[] initSquares()
> {
>     int[] result = new int[20];
>     for ( int i = 0; i < 20; i++ )
>         result[i] = i * i;
>     return result;
> }
> 
> void main()
> {
>     char[] testStr;
>     for ( int i = 0; i < squares.length; i++ )
>         testStr ~= toString(i)~" squared is "~toString( squares[i] ) ~ "\n";
> 
>     writefln( testStr );
> }
> 
> This is something I used in C# and enjoyed.  Any particular reason this doesn't exist already?  Maybe I am supposed to write my code a different way, if so please enlighten me.  My current workaround is to use static ctors, but that doesn't seem as readable to me.

This is the natural functional area for template functions.

Simply change your code to this:

int[20] squares = initSquares!(int, 20)();

template initSquares(T, int C)
{
    T[] initSquares()
    {
         T[C] result;
         for ( int i = 0; i < C; i++ )
             result[i] = i * i;
         return result;
    }
}

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

On Sun, 14 May 2006 16:43:08 -0700, Kyle Furlong wrote:

> Chad J wrote:
>> Derek Parnell wrote:
>>>
>>>
>>> There are already precedents for this type of coding. Not only the 'unittest' idea but 'scope()' also allows us to physically separate code  that is executed linearly. So the concept is not foreign to D or Walter.
>>>
>> 
>> While I'm at it, I'd also like to see the ability to set a variable to the result of some function at starttime, like so:
>> 
>> int[] squares = initSquares();
>> 
>> int[] initSquares()
>> {
>>     int[] result = new int[20];
>>     for ( int i = 0; i < 20; i++ )
>>         result[i] = i * i;
>>     return result;
>> }
>> 
>> void main()
>> {
>>     char[] testStr;
>>     for ( int i = 0; i < squares.length; i++ )
>>         testStr ~= toString(i)~" squared is "~toString( squares[i] ) ~
>> "\n";
>> 
>>     writefln( testStr );
>> }
>> 
>> This is something I used in C# and enjoyed.  Any particular reason this doesn't exist already?  Maybe I am supposed to write my code a different way, if so please enlighten me.  My current workaround is to use static ctors, but that doesn't seem as readable to me.
> 
> This is the natural functional area for template functions.
> 
> Simply change your code to this:
> 
> int[20] squares = initSquares!(int, 20)();
> 
> template initSquares(T, int C)
> {
>      T[] initSquares()
>      {
>           T[C] result;
>           for ( int i = 0; i < C; i++ )
>               result[i] = i * i;
>           return result;
>      }
> }

Have you actually tried this, Kyle?

I understood the issue to be that the only way that D allows one to call a function to initialize a module-scoped static array is during the 'static this()' function. However this means that the declaration and the initialization code are physically separated. I think the OP wanted a mechanism that had the initialization code and the declaration code to be together.

Your response was illustrating templates but that is not relevant to the problem at hand.

The best I think that one can come up using templates is ...

// --------------- code starts -----------
import std.string;
import std.stdio;

int[] squares;
static this()
{
    squares = initSquares!(int, 20);
}

template initSquares(T, int C)
{
     T[] initSquares()
     {
          T[] result = new T[C];
          foreach ( int i, inout T item; result )
              item = i * i;
          return result;
     }
}

void main()
{
    for ( int i = 0; i < squares.length; i++ )
        writefln("%s squared is %s", i, squares[i]);
}
// --------------- code ends -----------

Still the declaration and initialization are separated. And if one wants to use something other than 'int' you have to change two lines rather than one.

What would be *nice* is to have D see ...

  int squares = initSquares!(int, 20);

at the module-level and automatically generate the initialization code to go into the module's ctor.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
15/05/2006 3:28:41 PM