Overriding of inherited class static methods?

[monkyyy]

On Friday, 24 July 2026 at 08:09:14 UTC, ShadoLight wrote:
> 
> ```D
> class base{
>     static int count;
>     static int foo(int i)=>count+1;
> }
> ```
> How would you handle a static member like ```count``` now?
>

I dont use classes, and dont care, but as a static int that 
should be a effectively a global and be "god object", if you 
remove static from int, then static on foo shouldnt work because 
the most important part of static is removing `this` and 
`context` errors.

> Then these is the issue of calling the static method through 
> the name i.e. if you have multiple instances of type A...

only to oo theory, I actively seek out ways to make more global 
state

> I don't think adding polymorphic behavior to static methods can 
> be done in a way that is sensible - it will be massively 
> confusing.

"the expression problem" has 2 common views, oo wants a 
"rotation" functional typethoery and while I dont have a way to 
articulate it imperative is of course out there with all of game 
dev wanting very very different things; so a implied 3rd.

Big "static"(made global) values is just part of "imperative" and 
real world polymorphism. If your in a tourist trap the shop keeps 
will likely accept 2 currency's, the two currencies are 
"polymorphic" of "money" in reference to a global exchange rate 
which is just "bad style" for oo's encapsulation and functional 
purity; blah blah, monads.

But real world, you have the option of not caring, the shop 
keeper dealing with the "polymorphic currency's" is just going to 
keep two tallys, have the cash register hooked up to a daily spot 
price and when doing their numbers setup an excel cell to grab 
the exchange rate and while they will lose a penny here or there 
it will be fine. Youd want to minimize unnecessary conversions 
between the dual currency's, but hiding it, outlawing it citing 
math and telling the shopkeep (in their 2nd language) about 
monads; would be silly. A tiny bit of global state can 
drastically simplify a problem. Its ok that most of excel is 
"pure" but deleting the features that grab magic numbers from the 
internet would make for a worse product.

If you want the class keyword to be owned by oo, ok; but I dont 
see any of this as hard to deal with or very scary.