I'm just in the midst of working with a bunch of Python scripts, where the following pattern is used heavily:

    hql_init = '''
      CREATE TABLE IF NOT EXISTS
      {table_name}_xyz_{method}(id string, name string,
                                     id2 string, name2 string);
    '''.format(**locals())

Such a construct occurs in a random script I'm using at every 12 lines of code. It replaces {name} with the value of the variable called "name". The script would grow in size if a more awkward (e.g., manual or with printf) interpolation were used.

So here's what I think. Expansion like the above will be used much more heavily than expansion for the sake of code generation. The latter is an advanced activity that we should support, but not give it pole position.

So I suggest we call the more popular usage "expand" and the more advanced usage "expandCode". Or in general give the popular use a shorter, simpler name, and the advanced use a more explanatory, longer name.


Andrei

On 11/6/10 6:45 AM, kenji hara wrote:
Thanks, all.

Through the discussion, I supported following suggestions:
- Add non-string values formatting. (Andrei)
- Add type formatting. (Robert)
- Identifier expression can ommit braces. (Andrei)
- Add expandSplit makes comma separated code-sting.
   (i.e. expandSplit!"call $n times" generates q{`call `, n, ` times`}.)

And, I decided keeps expand's name.

If no other comments, I'd like to post to issue-tracker, and commit.

Kenji

2010/11/1 kenji hara<[email protected]>:
I wrote a trivial utility template for generating code string.
This provides some easiness and viewability of metaprogramming.
(This is currently used in my adaptTo.)

http://github.com/9rnsr/scrap/blob/master/expand/expand.d

Sample:
----
template GenFunc(string name)
{
  mixin(
    mixin(expand!q{
      int ${name}(){ return 10; }
    }));
  // result of expand! is:
  //   q{`int ` ~ name ~ `(){ return 10; }`}
}
mixin GenFunc!("test");   // generates function "test" returns int
unittest{
  assert(test() == 10);
}
----

expand!q{ codes... } parses D code string, and expands ${ expr } for
embedding expr that is expression evaluated as string in compile-time.

do you think?

Kenji

_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos

Reply via email to