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

If we think about the gains that have been made lately in terms of reactive 
programming and modularity, it is about inverting the control so that the 
inner immutable doesn't have to morph to control the outer composition.

It appears conceptually this is what is being done by moving the vtable out 
of the instance of a type (aka virtual inheritance) and into an outer 
composition vtable list of implemented interfaces on known types.

I think this point is precisely on point with the opening post of this 
thread, because we are relating how the removal of inheritance modeling and 
the insertion of conjunction and disjunction modeling in the new DOT 
(Dotty) calculus, is intimately related with forsaking the Cake pattern and 
its inherent limits on extensibility of composition.

On Thursday, June 18, 2015 at 10:58:58 AM UTC+8, Shelby wrote:
>
> 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.