I am very against the idea of runtime failures. That's the whole point
of a type safe fluent API.
I would rather put the effort on the framework side than on the
developer side.
A string query language or a dynamic language is better if you are not
bothered with helping the developer to write the query.
On 20 nov. 2009, at 12:31, Navin Surtani <nsurtani(a)redhat.com> wrote:
Heya,
I was just thinking last night about a couple of things about the DSL.
Mainly, instead of having lots of return types, for example you
created a BooleanContext and a Negatable version if the Occur clause
was MUST. I was wondering, instead of having separate contexts, is
it easier to have one - and then if a user calls a buildQuery()
without sufficient information to actually build one we throw an
exception?
I think this is cleaner in some ways because we don't have to create
so many different types of class, and we're always returning the
same instance. However, the drawback is that by this method we
"allow the user to make a mistake" and will be needing to throw
exceptions. So here's where the discussion starts - what are pros/
cons of each system and which wind up being a better one to build?
Personally, I think having a single class context is better because
1 - it's simpler to build and 2 - as long as classes are documented
properly and exceptions thrown are clear as to what the issue is
then we're okay.
Ideas? Thoughts?
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable