If you don't get a satisfactory answer here, try gamedev.stackexchange.com ; there are some tools programmers there. (I wish I could help you myself but we're a Maya shop.) — Crashworks47 secs ago
@KitZ.Fox Why don't I? It wouldn't look proper for me to be doing that. I'd probably get them in trouble with unions or something too. I'm not even supposed to pick up a computer and move it to another desk due to union rules.
When Michael O'church talks about wanting to unionize programmers, I know that no programmers are going to want to deal with that kind of crap. No programmer wants to deal with programmers who can't be fired, for one.
ok, quick architecture question - put a .gitignore file in a repo or no?
alternative being like a global one: ~/.config/git/ignore
I'm pretty sure there was a question on SO or Programmers about this, but the lack of an interface for generating custom hashCode or equals methods in Java and then being able to pass that into a collection sucks.
It should be kind of like the sort(List<T>, Comparator<? super T>) method, except in the constructor of things like HashSet.
So you can have some kind of Equalitor<T> or Hasher<T> interface that you implement for a given T. You can then access methods to perform custom hashCode and equals implementations without actually relying on the class's implementation (or lack thereof) of equals and hashCode.
Am I missing something as to why neither Oracle nor Apache Commons Collections don't have this implementation?
This issue is most apparent when you have different implementations of an interface, and for the purposes of a particular collection you only care about the interface-level view of the objects. For example, suppose you had an interface like this:
public interface Person {
int getId();
}
Th...
I'm just starting to use Java 8, so there may be a better way that I'm describing. But I think a good step 1 would be to provide a Hasher<T> and Equalizer<T> (or <? extends T?>) interface.
And then implementing sets and hash-based collections using Hasher and Equalizer instead of the object hashCode and equals methods.
I am actually playing with it since I saw your question. I have a basic working sample so far but trying to improve it to learn how to achieve this. Perhaps other programmers knows better, let's see if we'll get something working. — smozgur51 secs ago
"If you need to need to make your python code more readable for Java or C# programmers..." that is a really interesting take on "is it bad practice to do X" — Tadhg McDonald-Jensen16 secs ago
I don't know if I've ever mentioned it before, but if you are unsatisfied with the quality of answers on a particular Python question, bring it up, and if it interests me, I'll write a high-quality answer on it. If I can keep interested long enough to write it up... :D
Over time, I've noticed an increasing practice among moderators of the smaller sites (i.e. not in the Trilogy) to move extended comment chains to chat, just because they're too long.
Is this a good idea?
In the past, I've taken the position on many occasions that I believe that comments serve t...
I think 61 comments are pointless and should be purged. If there is interesting discussion, it should be in a chat and the comments should be purged. If there is relevant information, it should be incorporated into either the question or an answer, and the comments should be purged.
Comments on StackExchange sites are like drawings in the sand - and subject to deletion or moving to chat at the whim of any mod.
Comments should help clarify, then get out of the way of the answers.
To the mods: I'd appreciate seeing more comment deletion on StackExchange sites, not less.
C...
You make the argument that moving them to a chat room is pointless because it kills the discussion, but the discussion is over once the "show 9000 more comments" shortens the list anyway.
Once the comments are truncated, discussion continues between the people who were originally involved (2-5 users maybe) and is highly likely to dissolve into something non-constructive.
@KitZ.Fox That's not true. I see people regularly contribute to collapsed comment chains, and even upvote hidden comments to make them visible. That's not true at all of the chat rooms.
@KitZ.Fox Well, given the choice, preserving a good conversation in a chat room is better than just wiping it out. Those two things aren't remotely the same.
Comments get in the way of the answers. Most annoying comments are something like: "NB, <something obvious that belongs in an answer>" with a 200 on the side of it because it's sat there for 8 years. On a related note, I usually find any phrase along the lines of "Note well, Pay attention, etc..." to be insulting to the reader.
Don't forget the thousands of "Me too!" "I agree with that" "Here's my anecdote about something sort of related!" "<joke>" "You're joke isn't funny." "It's 'your', dickwipe." "Don't talk like that" "Where's the policy that says I can't?" "Random point"
@ThomasOwens that's because you looked in the wrong place. :) Instead of rejector comment, look at JIRA description which offers a clue with the reference to IdentityMap which javadoc says "it intentionally violates Map's general contract, which mandates the use of the equals method when comparing objects..." This probably refers to contract of containsKey, containsValue, get, remove, replace methods in java.util.Map
@gnat I don't understand. The JIRA issue says "The semantics of an EquatorMap would collide with the Map contract, thus closing as Won't fix for now."
Why would a map that takes an Equator to define a custom equals and hashcode conflict with the generic Map contract?
I don't see how it does. It would be inconsistent if you were able to change the implementation of equals and hashcode after instantiating the map. You could, in theory, end up with two equal keys if you did that.
But defining the algorithms to determine equality of keys and values doesn't appear to violate the Map contract. It also wouldn't violate the contract of other data structures that rely on hash or equals, like Set.
I guess it depends on how specific you view the contract (key==null ? k==null : key.equals(k)).
I consider (key==null ? k==null : key.equals(k)) to be the same as (key==null ? k==null : Equator.equals(key, k)), especially if I don't have source-code access to the class K.
That is assuming that Equator.equals adheres to the same contract as Object.equals(), which it would have to.
Although the Map contract isn't so sacred since Sun/Oracle even broke it in their implementation of IdentifyMap. Providing a native Equator method that can call object.equals(), use ==, or a custom implementation of equality checking would be better. That way, you never break the map's contract. The contract just becomes "each key must be unique".
@gnat I guess it depends on what you consider Map's general contract. I don't consider the "general contract" to depend on the object's equals() method. I consider the general contract to be a statement about equality of keys and values.
@ThomasOwens look into the text of request, not into comment. It suggests - "implementation could be similar to the previous IdentityMap" - and I think this made rejector pull the point of collision with contract (because this is openly acknowledged in IdentityMap javadocs). as for what would be general contract, in this particular case you'd have a hard time arguing about it because Map javadocs for methods I listed all explicitly refer equals method of keys and values...
...the very moment that your Equator.equals will return something different, be prepared to handle complaints from API users whining "oh but we were promised in javadocs". Library developers probably don't want to handle this or, more precisely don't see the pressing need to introduce API that would cause such complaints (I guess folks who introduced IdentityMap had such a pressing need, otherwise they wouldn't do it)
The Equator would be an optional argument to a constructor. If you don't give it, then it's the standard object equals.
A lot of times, you don't have access to the class source code to change the definition of equals.
So being able to inject a new Equals implementation is a good thing.
Specifically, in my case, I'm working with JAXB-generated object models. JAXB uses the Object equals() implementation, which is not good for me. Using JAXB2-Basics or something similar to generate an equals method also isn't suitable, since my definition of what makes two object equal is different than other people's definition of what makes two objects equal.
Being able to define my application-specific definition of how to take these objects and define equality, especially for the purposes of putting into a Collection, would be much better than my current solution of a Map to Map to Object.
@ThomasOwens then you pass the map around and the knowledge of custom equator gets lost, so that users start believing it falls under usual promises in Map javadocs. And they start believing that when they compare their objects with these objects equals, they will be able to make conclusions about how your map will behave (at this moment they only see a Map implementation, not knowing it's your map), and then, they will suddenly find that what they see in object equals doesn't match your map
Clearly, injecting an Equality operation into a Map or a Set is inherently useful.
So, this feature request has been rejected by both Guava and Apache Commons Collections. Yet I see a need for it. What would you do? I could make a new library that depends on Apache Commons Collections.
All the original Java interfaces are insane, and not just because they predate generics. In particular, the optional methods e.g. in the Iterator interface are a popular target of my ire.
@amon I guess what it boils down to is the inclusion of (key==null ? k==null : key.equals(k)) in the Map interface.
That should have read, for example in the containsKey() method: Returns true if this map contains a mapping for the specified key. More formally, returns true if and only if this map contains a mapping for a key k.
Full stop, to mention of the use of the object equality operator.
It seems clear that Apache Commons Collections wouldn't accept a contribution of this implementation.
The usual workaround is to wrap your actual keys with a custom type that overrides .equals() to use object identity for comparison, and only use that wrapper in your specific map.
@amon When you are dealing with a few dozen objects...eh. I'd rather write 12 Equator instances than 12 wrappers.
If you were going to implement a sane collection, would you have a dependency on Apache Commons Collections, and use their Equator interface and maybe some of their implementation detail? Or would you have your own interfaces and only use core Java classes and interfaces? If I write this, I'd release it under Apache License 2.0, since it's my favorite license.
@ThomasOwens You can probably make that wrapper generic. class IdentityEquated<T>{ public final T value; public IdentityEquated(T value){ this.value=value } public boolean equals(Object that) { return value == that; }; public int hashCode() { return value.hashCode(); } }, though this requires that all code using those maps goes through this wrapper.
@amon I'd have to think about it. Part of it is that there may be more than one definition of equality for given objects.
I still think having collections that let you inject a equality algorithm would be extremely useful to me and lots of people, yet it seems like the major collections frameworks are rejecting this idea.
Theoretically, you could even use Reflection to implement equals and hashCode based on non-public methods and fields of the object.
I think I'm going to make my library dependent on Apache Commons Collections if I do this.
the best part is most people don't even realize they're using them, so if you call them out on it they'll get annoyed at your for derailing the argument with meta nonsense
@ThomasOwens I bet library designers thought any possible inconvenience would be okay to handle with wrappers. Collections framework was introduced in Java 2 - back then it was supposed to be primarily used in small, slow applications. It's only in Java 4 it became popular for larger, server-scale stuff
Parametrizing a collection over the required operations makes a lot of sense, and this is how the C++ standard library does it (though through template parameters: can be optimized away entirely but doesn't support a common interface).
Java's approach also makes a little sense since you can override the necessary operations for the values. Of course, Java deviates from this approach with the TreeMap, which can take a Comparator<T> in the constructor (though I'm surprised they passed up the opportunity to call it a ComparisonStrategy…)
@gnat According to the post on Programmers, part of it has to do with equals and hashCode being implemented as methods on Object in Java 1. When Comparator was created, they did it right.
But they favored maintaining backwards compatibility over fixing the problem.
@ThomasOwens yeah that's a good point. Maybe they could do it better and maintain backward compatibility (eg not making Map to backward-include Hashtable) but I think they didn't care back then. It was for small and slow apps so any problem that could be solved with wrappers was probably considered non-critical
Just because equals and hashCode are rather poorly defined by the List interface doesn't mean that it doesn't make sense to have a Set that allows for indexed access like a List. I've needed that before, too.
Although that one is a little trickier.
It's hard because add(int index, E element) returns void and not boolean in the List interface.
Please tell me, Why you didn't ask this on StackOverflow? Were you blocked from asking there, or did someone tell you this site would be better for this question? — Aaron Hall11 secs ago
A response!
I thought this was the right place to ask, if it's not I apologize. I will ask on StackOverflow from now on — John Keeper1 min ago
Well this seems to be a debugging question, and debugging is specifically off limits for Programmers. — Aaron Hall20 secs ago
@AaronHall if you look to this guy profile, it shows Physics, and MichaelT mentioned that folks there (along with Math) have this funny theory, 'my friends told me that "stack exchange" is undergraduate or master level, and "stack overflow" is PhD or research level. I think my question is very basic, so I asked here'. Or more precisely they developed this theory when triage started burying their questions at SO
@RobertHarvey I just wanted it to be clear to people who think that you have to get to 25,000mph to get to space because 'escape velocity is 25,000mph' that it doesn't work like that. — Steve Ives18 mins ago
OMFG!
@SteveIves: If you really want to be a public benefactor, then explain in detail precisely why "escape velocity is 25,000 mph" is an invalid statement, without explaining in a way that requires strapping a giant rocket onto a 747 and pointing it straight up (which, by the way, is decidedly not what the OP asked about). Take your time. — Robert Harvey54 secs ago
This issue is most apparent when you have different implementations of an interface, and for the purposes of a particular collection you only care about the interface-level view of the objects. For example, suppose you had an interface like this:
public interface Person {
int getId();
}
Th...
Over time, I've noticed an increasing practice among moderators of the smaller sites (i.e. not in the Trilogy) to move extended comment chains to chat, just because they're too long.
Is this a good idea?
In the past, I've taken the position on many occasions that I believe that comments serve t...
Comments on StackExchange sites are like drawings in the sand - and subject to deletion or moving to chat at the whim of any mod.
Comments should help clarify, then get out of the way of the answers.
To the mods: I'd appreciate seeing more comment deletion on StackExchange sites, not less.
C...
