On Mon, 22 Nov 2010 22:17:46 +0100
Pelle Månsson <pelle.mans...@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
