[
https://issues.apache.org/jira/browse/HDFS-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15007150#comment-15007150
]
Bob Hansen commented on HDFS-9117:
----------------------------------
[~wheat9]: thanks for the review.
bq. In the first cut maybe we can remove it from the API and keep the version
that only takes string?
Will do.
bq. I suggest making Configuration as an immutable object.
Always a good choice unless performance demands otherwise. We will also need
a non-static method to load another batch of settings on top of currently
loaded ones.
{quote}
{code}
template<class Type>
optional<Type> get(const string& key) const;
{code}
{quote}
I think this would be a superior interface if we could make a generic
implementation across the types, or if templates could be inferred by return
type.
I don't think we can re-use implementations in this case (the generic
implementations being exception-throwing), nor can we infer the return type, so
the call sites will need to look like:
{code}
int64_t foo = config.get<int64_t>("foo");
int64_t bar = config.get<int64_t>("bar");
{code}
vs.
{code}
int64_t = config.getInt("foo");
int64_t = config.getInt("bar");
{code}
The explicit types have the advantage of being able to tell from the
declaration which types are supported without looking into the implementation.
With the templated getter, there is no way to tell whether or not
config.get<int>("") is implemented.
bq. That gives a minimal exposure from the API prospective.
I don't see how it reduces the API exposure; we need to define what types we
support etiher way, and continue supporting them either way.
Does that seem compelling to you?
bq. It's preferable to move the details of on implementing final in the .cc
file.
I agree, but if we want to keep a map of values, the value space needs to be
completely defined in the declaration. Given that they are marked in the
private section, I don't think this increases the footprint of the API, and
we'd be free to re-implement them however we want at a later time.
Do you have a suggestion for a compelling alternative that allows us to
efficiently look up values without declaring the storage?
Please feel free to respond to the comments while I implement the immutability
and loading methods.
> Config file reader / options classes for libhdfs++
> --------------------------------------------------
>
> Key: HDFS-9117
> URL: https://issues.apache.org/jira/browse/HDFS-9117
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Affects Versions: HDFS-8707
> Reporter: Bob Hansen
> Assignee: Bob Hansen
> Attachments: HDFS-9117.HDFS-8707.001.patch,
> HDFS-9117.HDFS-8707.002.patch, HDFS-9117.HDFS-8707.003.patch,
> HDFS-9117.HDFS-8707.004.patch, HDFS-9117.HDFS-8707.005.patch,
> HDFS-9117.HDFS-8707.006.patch, HDFS-9117.HDFS-8707.008.patch,
> HDFS-9117.HDFS-8707.009.patch, HDFS-9117.HDFS-8707.010.patch,
> HDFS-9117.HDFS-8707.011.patch, HDFS-9117.HDFS-8707.012.patch,
> HDFS-9117.HDFS-8707.013.patch, HDFS-9117.HDFS-8707.014.patch,
> HDFS-9117.HDFS-9288.007.patch
>
>
> For environmental compatability with HDFS installations, libhdfs++ should be
> able to read the configurations from Hadoop XML files and behave in line with
> the Java implementation.
> Most notably, machine names and ports should be readable from Hadoop XML
> configuration files.
> Similarly, an internal Options architecture for libhdfs++ should be developed
> to efficiently transport the configuration information within the system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
