I'm using a static class member in a parent class, but can't get the compiler to see it.

Class Grid{
  public:
  uint xdim;
}

Class Holder : Grid {
  uint var;
}

Any of the following should work, but none of them do:
Grid.xdim = 0;

grid = new Grid;
grid.xdim = 0;

holder = new Holder;
holder.xdim = 0;

This is the way static class vars were intended to work. What magics have I forgotten?

Platform
DMD latest, Windows 7
Visual D

On Wednesday, 29 June 2016 at 15:18:53 UTC, Guido wrote:
> I'm using a static class member in a parent class, but can't get the compiler to see it.
>
> Class Grid{
>   public:
>   uint xdim;
> }

That's not static.... do `static uint xdim;` if you want it static (in this context, static means it is shared across all objects of the class)

> grid = new Grid;
> grid.xdim = 0;
>
> holder = new Holder;
> holder.xdim = 0;

those DO work if you declare the variable

auto grid = new Grid;
grid.xdim = 0;

auto holder = new Holder;
holder.xdim = 0;

On Wednesday, 29 June 2016 at 15:18:53 UTC, Guido wrote:
> I'm using a static class member in a parent class, but can't get the compiler to see it.
>
> Class Grid{
>   public:
>   uint xdim;
> }
>
> Class Holder : Grid {
>   uint var;
> }
>
> Any of the following should work, but none of them do:
> Grid.xdim = 0;
>
> grid = new Grid;
> grid.xdim = 0;
>
> holder = new Holder;
> holder.xdim = 0;
>
> This is the way static class vars were intended to work. What magics have I forgotten?
>
> Platform
> DMD latest, Windows 7
> Visual D

The problem is actually much more profound. The classes need to be declared outside the main() scope. WTF?!?!?!

I put them in main() so they would be in scope. This seems like a *MAJOR* design flaw with the language, not to mention the compiler not giving useful feedback. This decision, if it is a decision, makes no sense given all the attention to scoping rules.

I'm not interested in trading one set of bad language decisions for another. Can someone fix this?

On Wednesday, 29 June 2016 at 15:33:58 UTC, Guido wrote:
> The problem is actually much more profound. The classes need to be declared outside the main() scope. WTF?!?!?!

Not true.

What are you actually trying to compile?

On Wednesday, 29 June 2016 at 15:33:58 UTC, Guido wrote:
> The problem is actually much more profound. The classes need to be declared outside the main() scope. WTF?!?!?!
>
> I put them in main() so they would be in scope. This seems like a *MAJOR* design flaw with the language, not to mention the compiler not giving useful feedback. This decision, if it is a decision, makes no sense given all the attention to scoping rules.
>
> I'm not interested in trading one set of bad language decisions for another. Can someone fix this?

I wonder which language you usually use in your programming experience.

On Wednesday, 29 June 2016 at 15:33:58 UTC, Guido wrote:

> The problem is actually much more profound. The classes need to be declared outside the main() scope. WTF?!?!?!

It's not going to work anywhere if you type 'Class' as opposed to 'class'. Types can be declared in any scope:

```
void main() {
    class Foo {
        static int x = 10;
    }

    assert(Foo.x == 10);
}
```

On Wednesday, 29 June 2016 at 15:40:57 UTC, Andrea Fontana wrote:
> On Wednesday, 29 June 2016 at 15:33:58 UTC, Guido wrote:
>> The problem is actually much more profound. The classes need to be declared outside the main() scope. WTF?!?!?!
>>
>> I put them in main() so they would be in scope. This seems like a *MAJOR* design flaw with the language, not to mention the compiler not giving useful feedback. This decision, if it is a decision, makes no sense given all the attention to scoping rules.
>>
>> I'm not interested in trading one set of bad language decisions for another. Can someone fix this?
>
> I wonder which language you usually use in your programming experience.

C++

I have all this business generally working in C++. I just wanted to try D for a production level quick project. So, the language is not ready. I'm really sad about this. I had hoped that I could get some useful work done. C++ is painfully slow to write & debug, but what can you do.

As I said, why exchange one set of bad design decisions for another?

On another topic, tuples seem to have a major problem as well.

Tuple!(float, float, float) test;
Tuple!(float, float, float) [] array_data;

test[0] = 1.0;  // works
array_data[i][0] = 1.0; // doesn't work. Compile-time error, probably because the language itself doesn't have a dedicated extension for tuple elements that is distinguished from array dereferencing. This is the logical extension of how to access tuples. I normally use structs in C++, but since pointer arithmetic is really frowned upon in D, I decided to use Tuples. A mistake, I supposed.

So, I've spent a huge amount of time getting ready to write in D. That's all wasted. I'll check back in another 10 years to see if your hobby language is still around. In the mean time, try to think about improving the compiler error messages. I can write code any way the language demands, but it has to make sense and I can't be doing a research project on the language every 10 minutes to figure out the right incantation. I already have that with C++.

Bye

On 06/29/2016 07:00 PM, Guido wrote:
> On another topic, tuples seem to have a major problem as well.
>
> Tuple!(float, float, float) test;
> Tuple!(float, float, float) [] array_data;
>
> test[0] = 1.0;  // works
> array_data[i][0] = 1.0; // doesn't work.

Works just fine for me, if I add the missing pieces (imports, main, set i, put something in array_data).

Please post complete code, the compile command, the compiler version you're using, and the error message you get. This applies to the original post as well.

On Wednesday, 29 June 2016 at 17:00:49 UTC, Guido wrote:
> I have all this business generally working in C++. I just wanted to try D for a production level quick project. So, the language is not ready. I'm really sad about this. I had hoped that I could get some useful work done. C++ is painfully slow to write & debug, but what can you do.
>
> As I said, why exchange one set of bad design decisions for another?
>
> On another topic, tuples seem to have a major problem as well.
>
> Tuple!(float, float, float) test;
> Tuple!(float, float, float) [] array_data;
>
> test[0] = 1.0;  // works
> array_data[i][0] = 1.0; // doesn't work. Compile-time error, probably because the language itself doesn't have a dedicated extension for tuple elements that is distinguished from array dereferencing. This is the logical extension of how to access tuples. I normally use structs in C++, but since pointer arithmetic is really frowned upon in D, I decided to use Tuples. A mistake, I supposed.
>
> So, I've spent a huge amount of time getting ready to write in D. That's all wasted. I'll check back in another 10 years to see if your hobby language is still around. In the mean time, try to think about improving the compiler error messages. I can write code any way the language demands, but it has to make sense and I can't be doing a research project on the language every 10 minutes to figure out the right incantation. I already have that with C++.
>
> Bye

Fun fact: the following does work as expected.

Tuple!(float, float, float) test;
Tuple!(float, float, float) [] array_data = new Tuple!(float, float, float) [3];

test[0] = 1.0;
array_data[2][0] = 1.0;

So... if something does not work, please, have at least the maturity to post the actual code that does not work. Posting code that works and then complaining with your tone doesn't make you look very professional.

But I guess I'm just loosing my time.

Bye.

On Wednesday, 29 June 2016 at 17:00:49 UTC, Guido wrote:
>
> Tuple!(float, float, float) test;
> Tuple!(float, float, float) [] array_data;
>
> test[0] = 1.0;  // works
> array_data[i][0] = 1.0; // doesn't work. Compile-time error, probably because the language itself doesn't have a dedicated
>

It works. Could you post the minimal example and error message it produces?