D - Q: modules attributes
I tried: module leds; const char[] aboutText = "blah blah blah"; module workspace; class A { void someFunction() { leds.aboutText; } } just to find out that I need the static attribute on the const aboutText. hmmm... Is this right? Ant
Dec 01 2003
On Mon, 01 Dec 2003 23:44:25 -0500, Ant wrote:I tried:oops, no! the compilation also faild with static and I just run the previous compiled version... so, let me see what's the problem... Ant
Dec 01 2003
On Mon, 01 Dec 2003 23:53:08 -0500, Ant wrote:so, let me see what's the problem...never mind I got it (my fault). The problem is that I still get confused by the module thing. I have: module leds.Leds; public: static const char[] aboutText = "blah blah blah"; class Leds { ... } module leds.Workspace; import leds.Leds; class Workspace { Leds leds; this(Leds parentLeds) { this.leds = parentLeds; } void someFunction() { <something> leds.aboutText; // does not compile <something> Leds.aboutText; // does not compile <something> leds.Leds.aboutText; // does not compile } } as you can see the choice of names and capitalization alone shows how confused I am... finally I added alias leds.Leds ledsM; to the workspace module and the thing compiles with <something> ledsM.aboutText; but... even if I named the module "leds.leds" it's not wise to declare a variable Leds leds; I can't say I like this. I'm sure I want to have a class Leds on a module leds.leds. I'm also sure that the best name for an instance of class "Leds" is "leds". I'm also sure that that's not a good idea... so: leds.leds - module leds.leds.Leds - class hmmm I just saw today that Oberon uses something like private <type?> ledsM = import leds.leds; that look cleaner then private import leds.leds; alias leds.leds ledsM; (I'm gonna post this as a separate post 'cause I doubt anyone read this mess until here) maybe this helps others to avoid this trap (I hate to thing I wasted your time for nothing... sorry) Ant
Dec 01 2003