Question on layer/peeling
vitalyd at gmail.com
Tue Jan 6 04:37:55 UTC 2015
I suppose the workaround for #3 would be to take a Hasher<T> (or whatever
name you pick) instance as a ctor arg; this would provide equals/hashCode
for your type T.
Sent from my phone
On Jan 5, 2015 10:53 PM, "Michael Barker" <mikeb01 at gmail.com> wrote:
> > The layer part is indeed not yet implemented. But even a catalogue of
> > where the code can't be made value-clean would be a useful contribution.
> > We know that the Collections implementation is full of stuff that will be
> > hard to any-fy without help from layering or other tools, but don't yet
> > have a complete catalog.
> I think I've managed to hit the wall with the current implementation of
> Valhalla. I think the "implementation by parts" work or something similar
> needs to make progress before moderately complex collections like HashMap
> can be implemented. So, sticking points thus far.
> 1) Nulls - checking against null inputs. Ideally no-op and always true for
> 2) Nulls - nulling out reference array elements. Need some notion of
> "zero" for value types, so that nested value types containing references
> don't leak memory.
> 3) Methods from Object, e.g. hashCode and equals. At the moment an <any T>
> doesn't have any methods, there's no obvious way to get the hash code of,
> or equate any-type variables.
> #1 & #2 can be worked around by simply not doing them and suffering the
> negative effects (NPEs and memory leaks respectively). I can't find an
> easy way to work-around #3. It was mentioned that value types will need to
> define hashCode/equals/toString. If this is the case, should the existing
> primitives support them too, such all possible types of an any-typed
> variable supports said methods? Obviously this impacts a HashMap
> implementation heavily as it is all about the hashCode and equals, but
> would probably impact an array ArrayList implementation too as it requires
> equals to support contains.
More information about the valhalla-dev