hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@hortonworks.com>
Subject Re: Compatibility guidelines for toString overrides
Date Thu, 12 May 2016 16:57:08 GMT
I'm in favor of making a statement in the compatibility guidelines that
there is no guarantee of stability or backwards-compatibility for
toString() output.  If a proposed patch introduces new dependencies on a
stable toString() output, such as for UI display or object serialization,
then I'd consider -1'ing it and instead asking that the logic move to a
different method that can provide that guarantee, i.e. toStableString().
There are further comments justifying this on HADOOP-13028 and HDFS-9732.

--Chris Nauroth

On 5/12/16, 9:32 AM, "Colin McCabe" <cmccabe@apache.org> wrote:

>Hi all,
>Recently a discussion came up on HADOOP-13028 about the wisdom of
>overloading S3AInputStream#toString to output statistics information.
>It's a difficult judgement for me to make, since I'm not aware of any
>compatibility guidelines for InputStream#toString.  Do we have
>compatibility guidelines for toString functions?
>It seems like the output of toString functions is usually used as a
>debugging aid, rather than as a stable format suitable for UI display or
>object serialization.  Clearly, there are a few cases where we might
>want to specifically declare that a toString method is a stable API.
>However, I think if we attempt to treat the toString output of all
>public classes as stable, we will have greatly increased the API
>surface.  Should we formalize this and declare that toString functions
>are @Unstable, Evolving unless declared otherwise?
>To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>For additional commands, e-mail: common-dev-help@hadoop.apache.org

To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

View raw message