Re: [scala-language] The cake’s problem, dotty des ign and the approach to modularity.

Apologies I realized my myopia. If the call site is receiving a manifest of 
types at runtime, then it can't know which types to compile into match-case 
boilerplate at compile time. Thus we still need some sort of vtable.

But why can't we make a vtable for types that is global and thus not tied 
to each instance of a type, a.k.a. not virtual inheritance nor subclassing?

So we have a manifest which is a lot of types and our compile time 
boilerplate enumerates the list. Each type has a globally UID for indexing 
a global vtable. Each interface has a globally UID which we can search for 
in our copy of the global vtable. The vtable should always be injected into 
each function, so that legacy code doesn't need to be recompiled.

I have not thought out how the above would interopt with types that are 
complex combinations of intersections and unions. I haven't even thought 
through the scenarios where unions will arise.

Apologies I am not writing out code examples for all my statements. If 
anything I've written is not clear, please ask me to clarify.

On Thursday, June 18, 2015 at 10:40:20 AM UTC+8, Shelby wrote:
>
> The only problem I thought of so far is that due to type erasure when 
> compiled to virtual machines (VMs) that erase types such as Java's, the 
> call site may not know the actually type of T in a collection and thus be 
> unable to construct the match-case boiler plate to apply the correct 
> Drawable[T] object implementation for each type in the intersection of 
> types in T. Type erasure can be worked around with implicit manifests so 
> this isn't a show stopper afaics.
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.