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

     Hello,

  My problem is still (yeah, still) to figure out what exactly is cake
pattern. There is no Wikipedia article on it. I could not find any
definition ("Cake pattern is ..."). I saw some examples, and I'm never sure
which parts of the discussion apply to dependency injection in general,
which parts are specific to cake, and which parts are specific to the
particular example.

  I know I asked this before. I could spend some time to dig out what the
answer was. But even better would be if those who put examples of cake on
the web could explain what makes it cake.

     Best, Oliver

On Tue, May 12, 2015 at 4:22 AM, martin odersky <[email protected]>
wrote:

> I would not classify cake as an anti-pattern per se. Like any scheme
> it is good for something but can be over-used. In fact, cake and
> inheritance are quite similar in their benefits and problems.
> Here are some points I can think of (I'd be interested in other
> arguments people might have).
>
> The good:
>
>  - Lets you compose multiple components quickly and with minimal fuss
> - no parameters, no forwarders, no imports, just mix slices together.
>
>  - Allows for mutual dependencies between slices.
>
>  - Is therefore very general: Any set of global definitions with
> arbitrary dependencies between them can be lifted into a cake.
>
> The bad:
>
>  - Because they are so convenient, cakes tend to get big.
>
>  - Dependencies are not declared, so are hard to track for big cakes.
>
>  - If cakes contain types, these can be accessed from outside the cake
> only with path dependent types. Cakes with mutual type dependencies
> between them (as they exist in nsc) are particularly hard to model.
>
> In summary, cakes, like inheritance, are a useful tool to achieve
> close coupling of components. It's very easy to link components in one
> cake, and it is comparably much harder to access them from the
> outside, in particular if types are involved. Cakes are misused in a
> situation where weak coupling is preferable (and those situations are
> in the majority).
>
> My advice would be: Cakes are fine to model mutual dependencies
> between traits. However, care must be exercised to keep them
> reasonably small. Furthermore, one should think twice whether
> embedding types in cakes is the right way to model things. Nowadays,
> I'd do that only if the type was essentially private to the
> participants of the cake, or if it was clear that every instance needs
> its different opaque type. Otherwise one might end up with awkward
> situations, where e.g. the type of symbols in the nsc compiler depends
> on the cake that's used. Sometimes you want that isolation, but at
> other times you want to communicate a symbol between different
> compiler instances (i.e., cakes), and then all you can do is copy an
> arbitrary complex graph of symbol dependencies (see the "Importers"
> framework in scala.reflect). So, putting types in traits can be a
> premature restriction of their usage.
>
> The alternative to cakes is essentially functional abstraction. Have
> components parameterized by others. Depending where you come from you
> might call that "functors" or "constructor dependency injection".
> Implicit parameters can help reduce the boilerplate in function
> application.
>
> The dotty compiler uses fine-grained functional abstraction
> everywhere, using implicit context arguments. That has turned out to
> work quite well so far. Contexts are still cakes, in that they mix
> together slices that are modelled around different concerns. But they
> are much smaller and tend not to contain types, just methods and
> fields.
>
> This writeup got much longer than I meant it to be when I started...
>
>  - Martin
>
>
> On Tue, May 12, 2015 at 9:13 AM, Alex Ivanov <[email protected]>
> wrote:
> > Good morning everyone.
> >
> > I’m very interested in the topic of modularity in Scala. It’s not a
> secret
> > that today The Cake Pattern is the most popular way to achieve
> modularity in
> > the project and, to some extent, a nice way to manage dependencies. On
> the
> > other hand this way of structuring the application becomes more and more
> an
> > anti-pattern, but unfortunately there’s not much explanation why. I feel
> > that it’s pretty hard to answer why it’s becomes an anti-pattern without
> > some big, active project (like Scala compiler), but in general i can
> think
> > of things like - complicated design, not that nice way to manage
> > dependencies, problems with binary compatibility, slower compilation due
> to
> > inheritance overuse and complex cyclic dependencies, any other issues
> that i
> > didn’t think of?
> >
> > I remember that not so long ago Prof. Odersky mentioned he was also
> > disappointed in the pattern and went a bit different way with a Dotty
> > design. But, unfortunately, i couldn’t find details on this decision,
> what
> > were the problems and how they were solved with a new design (would be
> good
> > to read a paper like Scalable Component Abstractions). Anyway the
> project is
> > open-source, so it’s not hard to take a look and see that there are some
> > differences in the design, some components are packed within
> modules/objects
> > and it uses less cake-style coupling (beside the Context structure).
> Could
> > someone please unveil the secrets of the dotty architectural design?
> >
> > And, i guess, that last question that bothers me, what to use instead of
> the
> > Cake? In the talk “Scala - the simple parts” i liked the idea on the
> Scala’s
> > Modular Roots where we can see the mapping between Scala and SML
> languages.
> > Can’t reason much on this, i’ve just started looking at what we can
> achieve
> > with this SML-style modularity (maybe someone could explain this as well
> =)?
> > ), but it looks like a better approach to the modular design, especially
> in
> > combination with typeclasses. Of course we should “use the right tool for
> > problem”, but it feels like the Cake Pattern, is not good as the
> essential
> > approach to the application architecture and modularity.
> >
> > --
> > 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.
>
>
>
> --
> Martin Odersky
> EPFL
>
> --
> 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.
>



-- 
Oliver Ruebenacker
Solutions Architect at Altisource Labs <http://www.altisourcelabs.com/>
Be always grateful, but never satisfied.

-- 
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.