Boost logo

Boost :

From: Jonathan Wakely (cow_at_[hidden])
Date: 2005-10-02 16:00:42


Larry Evans wrote:

> On 09/27/2005 05:05 PM, Calum Grant wrote:
> > An early RML did use tuples indexed in the way you describe. I did use
> > enums - writing magic numbers is very bad for readibility and
> ^^^^^^^^^^^^^ I guess you mean an enumeration here?

I read it to mean he used enums *because* writing magic numbers is bad.
However, he prefers to read ...

> > maintainability. Personally I prefer to read
> >
> > customers.name
> >
> > instead of
> >
> > column<name>(customers)
> >
> Or, customers.get<customers::name>()
>
> OK, that's a little less readable :( , but I guess you believe the
> disadvantage of macro use is not as bad as the disadvantage of
> prefixing customers:: to the enumerator. I'm not that sure.

I'm very interested in this library and have some thoughts on Larry's
reply.

A benefit of Domain-Specific Languages is that you can provide a more
natural and expressive syntax for the domain. Since most people's
experience of relational models involves SQL I think a syntax that
(even vaguely) resembles SQL is better than what is pretty exclusively
C++ syntax. Try getting a developer who prefers java to write all those
angle brackets and double colons when they could just connect to an
RDBMS with JDBC and run SQL queries at runtime (several orders of
magnitude slower, of course :)

Then, if you wanted to refer to the column from within a template you'd
have to say "customers.template get<customers::name>()" which is syntax
that no library should require from its users unless really unavoidable.

Also, many queries have a large number of conditions, so the C++ syntax
will get very long and so is *much* harder to read (and write!)

As for avoiding macros, IMHO using macros is fine in this context.
Macros are code-generators, and that's exactly what Calum's using them
for. Again, there's no reason a declaration of a table in the DSL has
to look like a C++ declaration.

jon


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk