Thread overview
Idea - implicit static module ctors?
May 27, 2005
Derek Parnell
May 27, 2005
John Demme
May 27, 2005
Hasan Aljudy
May 27, 2005
Hasan Aljudy
May 28, 2005
David Medlock
May 28, 2005
Hasan Aljudy
May 27, 2005
Sometimes you have a group of module-level variables or objects which need to be global, but also need to be initialized at runtime.  This is handled with a static this() in D:

File f;

static this()
{
    f=new File("out.txt",FileMode.Out);
}

My question is: why can't the compiler understand something like:

File f=new File("out.txt",FileMode.Out);

At module level, and simply place the initialization code (the 'new' expression) in an implicit static this()?

Order of execution would be based on order of declaration.

Thoughts?


May 27, 2005
On Thu, 26 May 2005 20:52:16 -0400, Jarrett Billingsley wrote:

> Sometimes you have a group of module-level variables or objects which need to be global, but also need to be initialized at runtime.  This is handled with a static this() in D:
> 
> File f;
> 
> static this()
> {
>     f=new File("out.txt",FileMode.Out);
> }
> 
> My question is: why can't the compiler understand something like:
> 
> File f=new File("out.txt",FileMode.Out);
> 
> At module level, and simply place the initialization code (the 'new' expression) in an implicit static this()?
> 
> Order of execution would be based on order of declaration.
> 
> Thoughts?

I have had this exact thought. It seems that the compiler could be a useful tool by doing this. It's just removing one more tedious task from the coder.

-- 
Derek
Melbourne, Australia
27/05/2005 10:58:56 AM
May 27, 2005
Based on questions I've seen like this before, it's my impression that this is just one of those things that hasn't been done yet, but is on the list.

John Demme

On Thu, 2005-05-26 at 20:52 -0400, Jarrett Billingsley wrote:
> Sometimes you have a group of module-level variables or objects which need to be global, but also need to be initialized at runtime.  This is handled with a static this() in D:
> 
> File f;
> 
> static this()
> {
>     f=new File("out.txt",FileMode.Out);
> }
> 
> My question is: why can't the compiler understand something like:
> 
> File f=new File("out.txt",FileMode.Out);
> 
> At module level, and simply place the initialization code (the 'new' expression) in an implicit static this()?
> 
> Order of execution would be based on order of declaration.
> 
> Thoughts?
> 
> 

May 27, 2005
Jarrett Billingsley wrote:
> Sometimes you have a group of module-level variables or objects which need to be global, but also need to be initialized at runtime.  This is handled with a static this() in D:
> 
> File f;
> 
> static this()
> {
>     f=new File("out.txt",FileMode.Out);
> }
> 
> My question is: why can't the compiler understand something like:
> 
> File f=new File("out.txt",FileMode.Out);
> 
> At module level, and simply place the initialization code (the 'new' expression) in an implicit static this()?
> 
> Order of execution would be based on order of declaration.
> 
> Thoughts? 
> 
> 

I'm all for it, but there maybe few concerns ..

#File f1 = new File("out.txt", FileMode.Out);
#
#static this()
#{
#    File f2 = new File("out.txt", FileMode.Out);
#}
#
#File f3 = new File("out.txt", FileMode.Out);

what is the order of execution?
May 27, 2005
"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:d76h0p$11jo$1@digitaldaemon.com...
> I'm all for it, but there maybe few concerns ..
>
> #File f1 = new File("out.txt", FileMode.Out);
> #
> #static this()
> #{
> #    File f2 = new File("out.txt", FileMode.Out);
> #}
> #
> #File f3 = new File("out.txt", FileMode.Out);
>
> what is the order of execution?

Personally I'd think f1, then f2, then f3.  All static this()es in a module are combined together into a single function anyway, in the order that they're defined.  So statements at module level would simply be concatenated together with statements in static this()es, in the defined order.


May 27, 2005
Jarrett Billingsley wrote:
> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:d76h0p$11jo$1@digitaldaemon.com...
> 
>>I'm all for it, but there maybe few concerns ..
>>
>>#File f1 = new File("out.txt", FileMode.Out);
>>#
>>#static this()
>>#{
>>#    File f2 = new File("out.txt", FileMode.Out);
>>#}
>>#
>>#File f3 = new File("out.txt", FileMode.Out);
>>
>>what is the order of execution?
> 
> 
> Personally I'd think f1, then f2, then f3.  All static this()es in a module are combined together into a single function anyway, in the order that they're defined.  So statements at module level would simply be concatenated together with statements in static this()es, in the defined order. 
> 
> 

The problem with my example is that it's small, and there's only one line per segment.
But the problem with that is, in a big file, one may see the "static this" and assume it to be the first thing that'll get executed, and so will assume that f2 will handle "out.txt".

Of course, I'm assuming here that only one handle-per-file is allowed (I maybe wrong though).

It may also make sense to some people that "static this" is executed first, then all initializations outside statis this would be executed by order of declaration.

so f2 is executed first, then f1, then f3.

Of course the same issue exists with class member variable initializations outside the constructor. (java does that)

#class Thing
#{
#    private int r = 4;
#    private int x;
#
#    public this()
#    {
#        x = 5;
#    }
#....

But once a rule is set for the language, all concern is probably gone .. except for those who don't know what the rule for language is.


Ah well, I guess it's not really an issue.
May 28, 2005
Hasan Aljudy wrote:
> Jarrett Billingsley wrote:
> 
>> Sometimes you have a group of module-level variables or objects which need to be global, but also need to be initialized at runtime.  This is handled with a static this() in D:
>>
>> File f;
>>
>> static this()
>> {
>>     f=new File("out.txt",FileMode.Out);
>> }
>>
>> My question is: why can't the compiler understand something like:
>>
>> File f=new File("out.txt",FileMode.Out);
>>
>> At module level, and simply place the initialization code (the 'new' expression) in an implicit static this()?
>>
>> Order of execution would be based on order of declaration.
>>
>> Thoughts?
>>
> 
> I'm all for it, but there maybe few concerns ..
> 
> #File f1 = new File("out.txt", FileMode.Out);
> #
> #static this()
> #{
> #    File f2 = new File("out.txt", FileMode.Out);
> #}
> #
> #File f3 = new File("out.txt", FileMode.Out);
> 
> what is the order of execution?

Java uses the order of appearance in the file.
-DavidM
May 28, 2005
David Medlock wrote:
> Hasan Aljudy wrote:
> 
>> Jarrett Billingsley wrote:
>>
>>> Sometimes you have a group of module-level variables or objects which need to be global, but also need to be initialized at runtime.  This is handled with a static this() in D:
>>>
>>> File f;
>>>
>>> static this()
>>> {
>>>     f=new File("out.txt",FileMode.Out);
>>> }
>>>
>>> My question is: why can't the compiler understand something like:
>>>
>>> File f=new File("out.txt",FileMode.Out);
>>>
>>> At module level, and simply place the initialization code (the 'new' expression) in an implicit static this()?
>>>
>>> Order of execution would be based on order of declaration.
>>>
>>> Thoughts?
>>>
>>
>> I'm all for it, but there maybe few concerns ..
>>
>> #File f1 = new File("out.txt", FileMode.Out);
>> #
>> #static this()
>> #{
>> #    File f2 = new File("out.txt", FileMode.Out);
>> #}
>> #
>> #File f3 = new File("out.txt", FileMode.Out);
>>
>> what is the order of execution?
> 
> 
> Java uses the order of appearance in the file.
> -DavidM

heheh, just had a thought .. if this gets implemented, it'll be yet another reason why some people would think that D == Java.