[stringtemplate-interest] ST 4.0 planning

[Roman Odaisky]

Hi,

> Doh...would that beOverly burdensome? In other words, should I abandon
> targeting languages that have no reflection?

That depends.

Reflection is dangerous in tempting to write poorly extensible code.

Something like

[[store_in_table]]
class some_class
{
    [[store_in_field]]
    int something;

    [[store_in_field_as("class")]]
    some_type css_class;

    [[do_not_store]]
    int temporary;
};

will work fine... until the need to store the class in another storage arises.

It would be ideologically correct to have classes, DB tables and mappings as 
distinct entities, but that’s not for the lazy ones :-)

struct point
{
    double x, y;
};

typedef sql::table<
    "table_point",
	sql::field<"field_x", sql::decimal<6, 4>>,
	sql::field<"field_y", sql::decimal<6, 4>>
> table_point;

typedef sql::mapping<
    sql::field_mapping<&point::x, "field_x">,
    sql::field_mapping<&point::y, "field_y">
> mapping_point;

Something like that is what one _might_ write in C++09. This separates data 
and its storage, and it’s trivial to add mappings for something else. Or if 
we’re speaking about templates, different templates can be expecting the same 
data under different names (perhaps they were written by different people for 
different purposes).

Tedious, for sure, but avoids shooting oneself in the foot later.

You have been advocating separation for so long, you should understand me :-)

> Well, we don't want to turn it into Lisp (i.e., remove all syntax
> except function call) ;) ha!

Why not?

Or at least half the Common Lisp ;-)

-- 
WBR
Roman.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2286 bytes
Desc: not available
Url : http://www.antlr.org:8080/pipermail/stringtemplate-interest/attachments/20080908/48c1bb71/attachment-0001.bin