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" <cmcc...@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? > >best, >Colin > >--------------------------------------------------------------------- >To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org >For additional commands, e-mail: common-dev-h...@hadoop.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
