Dart says to avoid equality on mutable classes, that's reasonable. But what about classes with an immutable part like an unique id on which hashcode and equality shall be calculated with and other mutable attributes which shall be ignored. Is that not possible?
Related
The current collection framework favors the use of to method in order to convert to the target collection type, and with an implicit conversion available from various collection companion objects to the Factory argument, this creates a neat, uniform interface. It unfortunately makes very hard optimisations which were easy in the old framework with CanBuildFrom. Lets say I have a custom collection type Unique[T], which is a combination of Set and Seq in that the order in which elements follows the order of insertion, but any element can occur only once. Because it offers fast indexOf, apply(i :Int) and contains, conversions to both Set and Seq can be O(1) with a simple wrapper. I can override toSet and toSeq, but I see no way of determining inside to (other than extremely questionable reflection) that the target factory builds Seq or Set, because the Factory implementation used by the implicit conversion is generic and not a prototype instance like old ReusableCBF.
I am in trouble trying to create an indefinite hashed map, as I want as a key specific objects that inherits from an abstract class, so the Key_Type is the parent class-wide, but I do not know what to do with the Hash that the container requires, as the Hash_Type is a modular type.
How can I deal with the hash of a class-wide key?
First thing that comes to mind is to add a "Hash" primitive function to the Key_Type abstract class, to be implemented in each concrete derived key type using the components of that concrete type, and then to make the Hash function for the map call this primitive Hash function with redispatch according to the actual type of the key.
I need a map-like mutable data structure in Scala that is covariant in it's value type parameter. This is impossible to implement in Scala because mutable data structures are invariant in their type parameters. I understand the rationale for that decision, however, since that data structure will not be publicly exposed I need some "unsafe" variant of this data structure. How would you implement an alternative for this in Scala?
According to the docs ObjectIdentifier is:
A unique identifier for a class instance or metatype.
Is this uniqueness guaranteed to apply to only existing (i.e. not disposed of) objects? Or does extend through the whole application lifetime (i.e. no matter how long the app runs and how many objects it creates/destroys there will be never a collision)? Obviously, I suspect the former, but would like to get some confirmation. (E.g. it seems that the implementation is that ObjectIdentifier is somehow derived from the address of an object in memory.)
The use case is that I consider to use ObjectIdentifier for hashValue for the Set of weak objects, but if there is a possible collision of ids for existing and already destroyed objects then that won't work.
GWT-RPC requires that transfer objects to be serialized must have a default (zero-argument) constructor. Similarly, final fields will not be serialized (see issue 1054).
On the other hand, I know I am supposed to "minimize mutability". My tendency is to want my TOs to be immutable, with final fields, no default constructor, and no mutators.
How can I use GWT-RPC while respecting the immutable paradigm as much as possible. Do I have to convert to a mutable object to marshall, and then back to an immutable one? Is this even worthwhile?
Item 13 in Effective Java (item 15 in second edition) gives strategies on how to minimize mutability or to favor immutability.
Suppose we remove mutators but retain non-final fields and a default constructor. The effect will be a theoretically mutable object, but a practically immutable one. Yes, one could mutate the object via reflection with a bit of effort, but by simply closing off the exposed methods we can at least discourage mutating it in cases like this where it's impractical to make the object truly immutable.