2,755 reputation
1230
bio website
location Argentina
age 37
visits member for 3 years, 9 months
seen 3 hours ago

Software developer and science fiction fan.


16h
reviewed Approve suggested edit on Merge sort versus quick sort performance
Nov
21
reviewed Approve suggested edit on What should an object be called that contains only setters and getters?
Nov
21
reviewed Approve suggested edit on How to break these long C++ lines in a neat way?
Nov
20
reviewed No Action Needed Notify about starting event
Nov
20
reviewed No Action Needed Syncing structured data and files in Android App with an ORM?
Nov
20
reviewed Approve suggested edit on Why do so many namespaces start with com
Nov
20
reviewed Approve suggested edit on Bug fixing approach
Nov
13
revised Does releasing a binary work under GPL mean source must be provided?
added actual text of answer
Nov
7
reviewed Reject suggested edit on Should I use the Date type in JAX-RS @PathParam?
Nov
5
comment Using public final rather than private getters
@ThomasJung Private field names are an internal implementation detail and shouldn't be exposed (as a general rule; there may be exceptions). It's not necessary (except for the godawful Java bean convention) to have a getter/setter for every field. One of the points of OOD is to avoid locking clients to your internals. Unfortunately a lot of common Java practices do not follow OOD principles.
Nov
3
reviewed Approve suggested edit on Planning poker with visually impaired colleague
Oct
24
comment Testing for object equality by comparing the toString() representations of objects
@supercat It sounds as if you really want to write an answer instead of commenting in mine :)
Oct
24
comment Testing for object equality by comparing the toString() representations of objects
@supercat I'm sorry, I don't even understand your example anymore, or how it relates to the original question. This would probably something for us to discuss in another place. Feel free to write your own answer if you disagree with my advise that no, in general you shouldn't rely on toString to compare Objects!
Oct
24
reviewed Reject suggested edit on Ship of Theseus applied to GPL - Can I relicense my program if I replace all of the derivative parts?
Oct
24
reviewed No Action Needed How to write tasks in Jira when using Scrum?
Oct
24
reviewed Approve suggested edit on How to write tasks in Jira when using Scrum?
Oct
24
comment Testing for object equality by comparing the toString() representations of objects
@supercat I'm familiar with the limitations of Java's type system. Your example seems very contrived, and I doubt you'll gain much by using Object instead of a different, more useful type. What happens when I put a value in that map that isn't a String or a String[]? Ah, yes: I should have read the javadoc! If only there was a way to somehow tell the compiler that I cannot put an instance of Integer in the map! ... I hope you get my point :)
Oct
23
comment Testing for object equality by comparing the toString() representations of objects
@supercat I know; that's one of its limitations. As a general rule though, and unless you have very specific reasons not to, you should avoid passing Object to Java methods if they will only work with some subclasses (aka "avoid writing partial functions whenever possible"). Of course, lots of existing Java libraries work that way; let us learn from their horrible mistakes :)
Oct
23
comment Testing for object equality by comparing the toString() representations of objects
@supercat To put it another way, whenever it's possible to encode the property "the passed-in Map meets certain criteria" as a type in a statically typed language, please do so!
Oct
22
comment Testing for object equality by comparing the toString() representations of objects
@supercat That would be a poor use of Java's type system. In some cases its limitations make this unavoidable, but whenever possible use real types and avoid the "javadocs-as-types" as you suggest, which is a bad practice. If the method doesn't work correctly for all Objects, then for heaven's sake, don't pass it an Object. Anything else is not taking full advantage of the type system, which you must not do unless you have a good reason. I suppose you could program in Java as if it were Python, but what would be the point? :)