Breaking up the source of path-dependent types

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Breaking up the source of path-dependent types

Alan Burlison
I'm using path-dependent types and they work really well for the domain
I'm modelling. However there's one issue - I have quite a few
class-dependent types and as far as I can tell they all have to be
textually nested within the outer class. This makes for a rather large,
monolithic source file that ideally I'd like to split up into separate
files for each path-dependent type, but as far as I can tell there's no
way of doing that. Is that correct?

--
Alan Burlison
--

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Breaking up the source of path-dependent types

Stephen Compall-3
On November 17, 2015 10:57:12 AM EST, Alan Burlison <[hidden email]> wrote:
>I'm using path-dependent types and they work really well for the domain
>
>I'm modelling. However there's one issue - I have quite a few
>class-dependent types and as far as I can tell they all have to be
>textually nested within the outer class. This makes for a rather large,
>
>monolithic source file that ideally I'd like to split up into separate
>files for each path-dependent type, but as far as I can tell there's no
>
>way of doing that. Is that correct?

Tradition is to mix traits from separate sources. However, this is monolithic in another sense. There's another approach, given that x.T is just x.type#T.

class Foo {
class Bar
def dowith(b: Bar) = 42
}

case class HasBars[FX <: Foo](bar: FX#Bar)

val x = new Foo
val hb = HasBars(new x.Bar)
// hb has type HasBars[x.type]
// meaning this compiles
x.dowith(hb.bar)

[FX <: Foo] is also a sensible method type parameter. I've used this technique to split up reflection universe stuff (e.g. add methods) where using dependent method types was inconvenient (surprisingly common).

--
Stephen Compall
If anyone in the MSA is online, you should watch this flythrough.

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