[
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406447#comment-13406447
]
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 letter.
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: https://issues.apache.org/jira/browse/CASSANDRA-3647
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
