Why members of static class are not implicitly static?

static class Test
{
 void foo() {}
}

> Error: need 'this' for foo type void()

On 2/17/13, Michael <pr@m1xa.com> wrote:
> Why members of static class are not implicitly static?
>
> static class Test
> {
>   void foo() {}
> }
>

That's not the meaning of static in that context. The above is useful in nested classes.

Instead you can use:

class Test
{
static:
    void foo() { }
}

> That's not the meaning of static in that context.
As I understand a static class can't be instantiated.

> The above is useful in nested classes.
I just read it. Holy s.. cow.

> Instead you can use:
>
> class Test
> {
> static:
>     void foo() { }
> }

So in mine case if I want purely static class I need to use:

static Test
{
  static void foo();
}

right?

On Sun, 17 Feb 2013 17:00:19 -0500, Michael <pr@m1xa.com> wrote:

>
>> That's not the meaning of static in that context.
> As I understand a static class can't be instantiated.

Static in that position is a no-op.  The compiler (infuriatingly sometimes) accepts attributes that have no meaning silently.

> So in mine case if I want purely static class I need to use:
>
> static Test
> {
>    static void foo();
> }

A class that can't be instantiated has a private constructor.  In addition, if you want to make all the functions static, in D you can either put them in a static scope, or use the colon:

class Test
{
   private this() {}; // will never be instantiatable
   static: // all members after this will be static.  Could also use static { ... }

   void foo(); // a static function
   int x; // a static variable
}

-Steve

On Sunday, February 17, 2013 23:00:19 Michael wrote:
> > That's not the meaning of static in that context.
> 
> As I understand a static class can't be instantiated.

I have no idea how you came to that conclusion. That's not what it means for a class to be static at all. The only place that static has any effect on classes is for nested classes. A static, nested class is like any other class except that it's inside another class, which affects its path. e.g.

module b;

class C
{
    static class W
   {
   }
}

W is therefore b.C.W, whereas if it were not nested inside of C but next to it within the same module, then it would be b.W.

However, non-static nested classes are associated with an instance of the outer class, and therefore only one can exist per class instance. However, it also has access to that outer class instance through the property outer. e.g.

class C
{
    class R
    {
        void func()
        {
            //Sets the variable in the instance of
            //C that it's associated with.
            outer.i = 7;
        }
    }

    int i;
}

- Jonathan M Davis

On 2/17/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> A class that can't be instantiated has a private constructor.

An alternative to that is:

final abstract class C
{
    static:
}

You can't derive from it and you can't instantiate it.

On Sun, Feb 17, 2013 at 11:46:24PM +0100, Andrej Mitrovic wrote:
> On 2/17/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> > A class that can't be instantiated has a private constructor.
> 
> An alternative to that is:
> 
> final abstract class C
> {
>     static:
> }
> 
> You can't derive from it and you can't instantiate it.

Nice idiom!

This could be D's equivalent to C++ namespaces. ;-)


T

-- 
Obviously, some things aren't very obvious.

On Sunday, February 17, 2013 14:47:12 H. S. Teoh wrote:
> On Sun, Feb 17, 2013 at 11:46:24PM +0100, Andrej Mitrovic wrote:
> > On 2/17/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> > > A class that can't be instantiated has a private constructor.
> > 
> > An alternative to that is:
> > 
> > final abstract class C
> > {
> > 
> >     static:
> > }
> > 
> > You can't derive from it and you can't instantiate it.
> 
> Nice idiom!
> 
> This could be D's equivalent to C++ namespaces. ;-)

It's the closest that we've got, and Phobos uses it in a couple of places (like std.datetime.Clock), but it gets complained about quite a bit every time it comes up (particularly with regards to std.datetime.Clock). So, while it's useful upon occasion and some people like it, it's generally shunned. For the most part, it's considered better to just declare a free function and be done with it.

- Jonathan M Davis

On 17/02/2013 22:25, Jonathan M Davis wrote:
> On Sunday, February 17, 2013 23:00:19 Michael wrote:
>>> That's not the meaning of static in that context.
>>
>> As I understand a static class can't be instantiated.
>
> I have no idea how you came to that conclusion.

In fairness, it is the natural guess you'd make if you haven't actively used nested instance classes and understood how the outer instance pointer is stored. We use Java at work (same mechanism as D), and hardly anyone actually knows to write 'static' when they create a nested class that they intend to be POD. :)

> That's not what it means for a
> class to be static at all. The only place that static has any effect on classes
> is for nested classes. A static, nested class is like any other class except
> that it's inside another class, which affects its path. e.g.
>
> module b;
>
> class C
> {
>      static class W
>     {
>     }
> }
>
> W is therefore b.C.W, whereas if it were not nested inside of C but next to it
> within the same module, then it would be b.W.
>
> However, non-static nested classes are associated with an instance of the
> outer class, and therefore only one can exist per class instance.

That's not true, is it? You can make as many nested instances as you like. It's just that there must be some outer instance available at the time of construction (which can be a new one each time or the same one every time or anything in between).

> However, it
> also has access to that outer class instance through the property outer. e.g.
>
> class C
> {
>      class R
>      {
>          void func()
>          {
>              //Sets the variable in the instance of
>              //C that it's associated with.
>              outer.i = 7;
>          }
>      }
>
>      int i;
> }

Is it possible to write someInstanceOfR.outer? I've occasionally wanted Java to have that feature, and ended up storing the 'outer' reference manually. Though this probably means I was writing bad code; I can't remember. :D

On Sunday, February 17, 2013 23:26:37 Ben Davis wrote:
> On 17/02/2013 22:25, Jonathan M Davis wrote:
> > However, non-static nested classes are associated with an instance of the outer class, and therefore only one can exist per class instance.
> 
> That's not true, is it? You can make as many nested instances as you like. It's just that there must be some outer instance available at the time of construction (which can be a new one each time or the same one every time or anything in between).

I stand corrected (I just looked it up again in TDPL). I don't think that I've ever used a non-static inner class in D. I think that used them in Java all of once, but that was quite some time ago, so I don't remember for certain. It's not exactly the most useful feature ever. So, clearly I misremembered.

> Is it possible to write someInstanceOfR.outer? I've occasionally wanted Java to have that feature, and ended up storing the 'outer' reference manually. Though this probably means I was writing bad code; I can't remember. :D

Probably. I don't know. It's not a feature that I ever use.

- Jonathan M Davis