cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3647) Support set and map value types in CQL
Date Wed, 04 Jul 2012 11:13:35 GMT


Sylvain Lebresne commented on CASSANDRA-3647:

bq. Every time instanceof is used it indicates that components' OO design is broken.

Ok fine. I don't agree (more precisely I don't think perfect OO design at all cost is necessarily
superior) but I'm not interested in that debate, at least not on that ticket. So do you have
concrete proposition for that ticket? If not, I suggest we consider it good enough for now,
and feel free to open a follow up ticket with a clean refactor that follow OO design to the

bq. That means that you are confusing semantics of the "literal"

Please Pavel, let's stop with that. I don't fucking care about wikipedia definitions and thanks
but I'm not confused by any semantic.

So yes, when I say Literal it's a name for the class used to represent the collection literals.
If you find the naming confusing, then fine, we can call the class CollectionLiteral (that's
even a good idea).

Now the fact is that we need a class to represent those collection literals and we *need*
a common ancestor to that class and the Term class. Making the literals being of class Term
(or a subclass) would be ugly because none of the method of Term apply to the (collection)
literals. But the literals also have methods that make no sense for Term (namely validateType,
isEmpty and constructFunction), so we don't want to put those methods in the interface shared
with Term either.

So I don't see a cleaner to having Term, Value and Literal (though again, I'm fine changing
the naming) and I'm not confused about that.

And if we're being pedantic on naming, Term should not be renamed to UnaryLiteral because
it does not only represent literals, but also bind variables.
> Support set and map value types in CQL
> --------------------------------------
>                 Key: CASSANDRA-3647
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Jonathan Ellis
>            Assignee: Sylvain Lebresne
>              Labels: cql
>             Fix For: 1.2
> Composite columns introduce the ability to have arbitrarily nested data in a Cassandra
row.  We should expose this through CQL.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message