defining in a module symbols for export

[spir]

On Mon, 22 Nov 2010 22:17:46 +0100
Pelle Månsson <pelle.mansson at gmail.com> wrote:

> On 11/22/2010 08:18 PM, spir wrote:
> > Hello,
> >
> > Let us say I have a parsing library. Now, I want to define parsers in stand-alone modules -- for code structuration and reusability. Then, import them from apps that need them.
> > Is there another way than defining the parser (== list of patterns) at the module's top-level. I have nothing against this, since the module is dedicated to this anyway -- but dmd refuses.
> > More generally, I find myself unable to define structured objects at a modules's top level. for instancz:
> >
> > === mod.d ==
> > import std.stdio;
> >
> > struct S {
> >      int i;
> >      void speak() {writeln("i: ",this.i);}
> > }
> > === __trials__.d ===
> > import mod;
> >
> > auto s = S();
> > s.speak();
> > s.i = 1;
> > writeln(s.i);
> >
> > void main () {
> > }
> >
> > === compilation ===
> > __trials__.d(19): no identifier for declarator s.speak
> > __trials__.d(20): no identifier for declarator s.i
> > __trials__.d(21): found '.' when expecting ')'
> > __trials__.d(21): semicolon expected, not 'i'
> > __trials__.d(21): no identifier for declarator i
> > __trials__.d(21): semicolon expected, not ')'
> > __trials__.d(21): Declaration expected, not ')'
> >
> > Why does dmd refuse? If I put the code in a function, I can compile, link, and run it. But this does not match my use case: I need to export symbols (patterns) defined there; so, i guess, they must be defined at the top of the module. Is there another solution?
> >
> > I take the opportunity to ask whether it is possible to define which symbols are to be _ex_ported.
> >
> >
> > Denis
> > -- -- -- -- -- -- --
> > vit esse estrany ☣
> >
> > spir.wikidot.com
> >
> 
> To initialize at runtime:
> 
>      S s;
>      static this() {
>          s.i = 1;
>      }
> 
> to initialize at compile time:
> 
>      S getS() { S s; s.i = 1; return s; }
>      S s = getS();
> 
> Use public/private to control which symbols are availible. 
> Unfortunately, this doesn't really work at the moment :-)

Thank you very much!
Unfortunately, a parser is typically a bunch a definitions. I cannot expect the user (first, myself) to write a func for every little setting needed.
I could write setters on classes that require the user to set attributes, but as shown in the example, method calls are also refused.
Where is the issue, actually?


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com