[
https://issues.apache.org/jira/browse/HADOOP-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617762#action_12617762
]
Alejandro Abdelnur commented on HADOOP-1230:
--------------------------------------------
> > If you want to have your own MapContext implementation you'd extend
> > MapContextWrapper [ ...]
>
> Sorry if I'm being thick, but I don't understand the point of having the
> MapContext interface if no one is to implement it directly.
> We cannot remove methods from it without breaking all callers. We could add
> methods if all implementations always implement
> an abstract base class ( MapContextWrapper) instead, but how can we guarantee
> that folks don't directly implement the interface?
You recommend extending the wrapper class instead implementing the interface.
Again this is the pattern followed by the Servlet API for developers to replace
the request/response objects that are used downstream.
>> you cannot have a class extending 2 abstract classes, you can do that with
>> interfaces
>
> This feature is over-rated. One can easily define two classes that share
> state.
>
Take the {{OutputCollector}} and {{Reporter}} interfaces, you could have a
single class implementing both. Then use your class as parameter to methods
that expect either and {{OutputCollector}} or a {{Reporter}}, you cannot do
that if you are using abstract classes.
>> convenience methods in your abstract class become part of the contract when
>> they should not.
>
> Why should they not? What problems does this cause?
IMO the contract should be as spartan as possible. But doing that is very clear
what the container responsibilities are.
Take the {{Servlet}} interface, it defines 5 methods {{init, getServletConfig,
getServletInfo, service, destroy}} that is the contract with the container.
{{GenericServlet}} abstract class adds 7 convenience methods. {{HttpServlet}}
adds another 9 convenience methods.
peace!
> Replace parameters with context objects in Mapper, Reducer, Partitioner,
> InputFormat, and OutputFormat classes
> --------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-1230
> URL: https://issues.apache.org/jira/browse/HADOOP-1230
> Project: Hadoop Core
> Issue Type: Improvement
> Components: mapred
> Reporter: Owen O'Malley
> Assignee: Owen O'Malley
> Attachments: context-objs-2.patch, context-objs-3.patch,
> context-objs.patch
>
>
> This is a big change, but it will future-proof our API's. To maintain
> backwards compatibility, I'd suggest that we move over to a new package name
> (org.apache.hadoop.mapreduce) and deprecate the old interfaces and package.
> Basically, it will replace:
> package org.apache.hadoop.mapred;
> public interface Mapper extends JobConfigurable, Closeable {
> void map(WritableComparable key, Writable value, OutputCollector output,
> Reporter reporter) throws IOException;
> }
> with:
> package org.apache.hadoop.mapreduce;
> public interface Mapper extends Closable {
> void map(MapContext context) throws IOException;
> }
> where MapContext has the methods like getKey(), getValue(), collect(Key,
> Value), progress(), etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
