5 ms·

The ability to convert any object to a string is very useful for debugging and most languages support this. Even in C it's frequently useful to print %p to iden

• drainyard 7y ago
  It should be opt-in though. A compiler-flag for debug builds or similar.
  • chris_overseas 7y ago
    Why so, what are the downsides? It's not like it introduces any meaningful overhead at all, and there are plenty of situations where it is useful even in production (eg for logging in catchall "can't happen" top level exception handlers). Adding yet another compiler flag seems like a worse solution to me.
    • mrkeen 7y ago
      What you lose is the ability to model objects based on the behaviours that they can perform. I want to be able to design objects that have toString() and I want to be able to design objects that don't have toString(). The same goes for clone(), hash(), getPtr(), getEndian(), equals(), toBytes(), toJson(), encrypt(), delete(), isNumeric(), toXml(), serializationVersion() or compare().
      • Bartweiss 7y ago
        I suppose you could define toString() to throw an error, but obviously that's a messy hack in place of having that control. I can definitely appreciate the logic for making nothing intrinsic, and I can also see an argument for making equals() the only method of Object. (i.e. everything should have an identity function, but nothing more.) Now I'm wondering... are there languages which formalize "implement with a throw" into some kind of explicit refusal to implement a method? Obviously there are method-sharing approaches other than inheritance, but I've never heard of "you must implement this, or explicitly choose not to".
        • iudqnolq 7y ago
          I'm not quite sure what you mean, but it's standard in python if you have a method in a class that must be subclassed and overridden you can have the default raise a NotImplementedError
          • Bartweiss 7y ago
            I was thinking about a condition that's specifically for "inherited but not supported", but that's pretty close to what I had in mind, yes. Java doesn't have a language-level exception that's specifically for unusable methods, which can be a bit awkward. UnsupportedOperationException is the recommended answer, but it's relatively nonspecific as to why your operation wasn't supported. Apache's Commons extends that with NotImplementedException for cases where the call isn't definitionally impossible (e.g. adding to an unmodifiable map), but no implementation exists.
• ThePadawan 7y ago
  Which is why C# (and apparently other .NET constituents) has the excellent, but separate DebuggerDisplay API [0]. IIRC it also makes it possible to define a private implementation to communicate to clients that this pseudo-serialization is not part of the public API (like ToString() implicitly would be). [0] https://docs.microsoft.com/en-us/visualstudio/debugger/using-the-debuggerdisplay-attribute?view=vs-2019 https://docs.microsoft.com/en-us/visualstudio/debugger/using...
• mrkeen 7y ago
  That %p approach sounds perfect. If they wanted to make it worse, they could make it so you could call %s on any object, and if it wasn't defined, it would "conveniently" fall back to %p instead. Then someone could could write an article called "Never Use %s for Behaviour"