[
https://issues.apache.org/jira/browse/HBASE-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085081#comment-14085081
]
Jonathan Hsieh edited comment on HBASE-11210 at 8/4/14 6:47 PM:
----------------------------------------------------------------
{quote}
I forgot why we turned Filter into a class (Gregory explained it, and it made
sense, but I forgot).
It seems weird to have Filter as a class and have a FilterBase class. Proper
design would have it that Filter is an interface and FilterBase is a
convenience base implementation of it.
{quote}
The main reason for this kind of design is that if new methods are added to the
interface, existing customer filters are not broken if they are derived from
the FilterBase abstract class. FilterBase would implement the new function
with a empty function or default implementation as a place holder. Not sure if
this would provide binary compatibility (no recompile) or would require a
recompile (but no code modification) to work, but it would be better than
having to modify all your custom filters because of an additive change.
was (Author: jmhsieh):
{quote}
I forgot why we turned Filter into a class (Gregory explained it, and it made
sense, but I forgot).
It seems weird to have Filter as a class and have a FilterBase class. Proper
design would have it that Filter is an interface and FilterBase is a
convenience base implementation of it.
{quote}
The main reason for this kind of design is that if new methods are added to the
interface, existing customer filters are not broken if they are derived from
the FilterBase abstract class. FilterBase would implement the new function
with a empty function or default implementation as a place holder. Not sure if
this would provide binary compatibility (no recompile) or would require a
recompile (but no code modification) to work, but it would be better than
having to modify all your custom filters because of an additive the change.
> Consider restoring Filter class back to an interface
> ----------------------------------------------------
>
> Key: HBASE-11210
> URL: https://issues.apache.org/jira/browse/HBASE-11210
> Project: HBase
> Issue Type: Task
> Reporter: Ted Yu
>
> In 0.94, Filter class is an interface.
> From Filter.java in 0.96 :
> {code}
> * Interface for row and column filters directly applied within the
> regionserver.
> ...
> * When implementing your own filters, consider inheriting {@link FilterBase}
> to help
> * you reduce boilerplate.
> {code}
> We should consider restoring Filter class back to an interface.
> Lars first brought up this notion:
> https://issues.apache.org/jira/browse/HBASE-6657?focusedCommentId=13456317&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13456317
> This gives users / developers clear suggestion that custom filters should
> override FilterBase instead of implementing Filter directly.
> Thanks to Anoop who acknowledged this idea during offline discussion.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
