Question on layer/peeling

Vitaly Davidovich 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
> values.
> 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.
>
> Mike.
>


More information about the valhalla-dev mailing list