Skip to main content
12 events
when toggle format what by license comment
Jan 27, 2018 at 1:57 comment added gnasher729 "stringly typed" is bad enough. But if I have methods getLocation and setLocation, the result of getLocation should be immediately usable as a parameter for setLocation, without any change.
S Oct 24, 2012 at 16:04 history suggested Kazark CC BY-SA 3.0
Replacing dead link with one that was expressly written to maintain some of the content of the dead link
Oct 24, 2012 at 15:58 review Suggested edits
S Oct 24, 2012 at 16:04
Sep 26, 2011 at 7:07 vote accept user
Sep 22, 2011 at 9:23 comment added user As for changing the API; this is computer software, so it is virtually always possible to change things. (If nothing else you can always write an abstraction layer.) However, sometimes doing so involves way too much effort both short- and long-term to be justifiable. Then, it might be perfectly possible to make such changes, but still impractical.
Sep 22, 2011 at 9:20 comment added user The question, however, is not so much about this specific case as it is about where one should draw the line. Notice that toward the end of the question, I ask Would it make any difference if this was about something slightly more exotic than calling toString() on a standard type?
Sep 22, 2011 at 9:19 comment added user I'd give this +1 even if just for "stringly typed". In my code, I try to pass types that express meaning/intent as much as possible, but when working with third-party libraries and APIs, sometimes you are kind of stuck using what the authors of that API decided on. And IIRC, a location can indeed be "any kind of textual data", but for the implementation I am working on, a non-URL location is totally meaningless.
Sep 21, 2011 at 18:21 comment added Paul Nathan agreed, the core issue is that location is not a string, it needs to be a Location (or some other thingie representing a location idea).
Sep 21, 2011 at 16:23 comment added jhocking well +1 anyway for "is less a call than actually just noise generated by Java's demand for explicitness"
Sep 21, 2011 at 15:54 comment added back2dos @jhocking: He didn't say he can't. He said it's impractical. I disagree. Trying to apply best practices to code that works around flaws in API design really only makes sense if such workarounds are the only possible option. However here setting the API straight is the best option. Removing deficiencies is always preferable to working around them.
Sep 21, 2011 at 15:48 comment added jhocking I would tend to agree with you, but he already said he cannot modify the service API.
Sep 21, 2011 at 15:25 history answered back2dos CC BY-SA 3.0