Defining interface and default implementation in a single pass

[John Sullivan]

Hi Clint,

I like your syntax much better than mine, and I really like the idea of using macros! While I have read the guide on doing macros, I'm not sure how possible this is.

I'm cc:ing scala-language group here, since we're talking about a potential new language feature. scala-language people, we are talking about the possibility of defining an interface (trait) and a default implementation of that trait in a single pass.

Best, John

On Wed, Feb 13, 2013 at 10:38 PM, Clint Gilbert <clint_...@hms.harvard.edu> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've often wanted the same thing.  Perhaps it could be available for
every type?

class SomeClass {
  def foo
  def bar
}

class Blarg extends SomeClass.Api { ... }

or maybe apiOf[T], or contract[T]?

Are the latter something macros could accomplish?

On 02/13/2013 09:11 PM, John Sullivan wrote:
> Me too. I would like to be able to define an interface and a
> default implementation of that interface in a single pass. (As I
> mention in the paper.) Why not? Or some operation like:
>
> class FooImpl { // ... }
>
> trait Foo asImplementedBy FooImpl { // every public member of
> FooImpl becomes an abstract public member of this trait }
>
>
>
> On Wed, Feb 13, 2013 at 9:04 PM, Eric Kolotyluk

> <eric.ko...@gmail.com <mailto:eric.ko...@gmail.com>>

> wrote:
>
> I would be fascinated to see if Scala has some solutions to the
> boilerplate problems you point out.
>
> Cheers, Eric
>
>
> On 2013-02-13 2:45 PM, John Sullivan wrote:
>
> Hi people! I hope this isn't too inappropriate for this group, but
> I've been using the "cake pattern" for dependency injection with
> Scala for the past couple years, and I wrote up my experiences
> using it. I hope there is some practical advice here that goes

> beyond the two seminal papers by Odersky and Bon￩r.
>
> http://scabl.blogspot.com/__2013/02/cbdi.html

> <http://scabl.blogspot.com/2013/02/cbdi.html>
>
> Best, John -- 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

> scala-user+unsubscribe@__googlegroups.com
> <mailto:scala-user%2Bunsu...@googlegroups.com>. For more
> options, visit https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

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

> scala-user+unsubscribe@__googlegroups.com
> <mailto:scala-user%2Bunsu...@googlegroups.com>. For more
> options, visit https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
>
> -- 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
> scala-user+...@googlegroups.com. For more options, visit
> https://groups.google.com/groups/opt_out.
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlEcXEkACgkQ0GFaTS4nYxs3ZQCeMarMBeP09VIFKtlcAbu6lPrj
i8YAn1BRd2UqOySUpyg2mr/QlpC2jSY2
=ZA7h
-----END PGP SIGNATURE-----

--
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 scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Léonard Schneider]

This seems to be possible in 2.11.0-SNAPSHOT thanks to type macros. I have a first prototype that I'll share in a few days.

Syntax looks like following:

      import TraitOf._

      class AImpl {

        def f(i: Int): Int = i + 42

      }

      

      trait ATrait extends TraitOf[AImpl]

      class A extends AImpl with ATrait

      val a: ATrait = new A

Is it what you're looking for?

Best regards,

Leo

[Léonard Schneider]

To be correct: 2.11.0-SNAPSHOT in the macro paradise branch ;)

[Marc Grue]

Hi John (and Léonard),

I haven't had time to read through your paper, sorry, but I get a feeling that you might somehow use the type macro approach that I use for doing DCI: https://github.com/DCI/scaladci - or simply use DCI ;-)

It accomplishes the trick of adding behavior to already defined (and instantiated) objects. Not exactly what you ask for, but maybe it can reduce some boilerplate in an alternative way or solve some of the same basic requirements that the cake patterns sets out to solve?? I'm really on swaying ground here, so I'll leave the creative (and founded) thinking to you ... :)

You're welcome to use any part of the type macro if it is of any help. I'm looking forward to see your type macro, Léonard...

Thanks,

Marc

[Léonard Schneider]

Hi all,

Giving some news. I have a macro paradise 2.11.0-SNAPSHOT prototype implementing the TraitOf type macros as described above. I kept it simple so it only export public vals, vars and defs from the class. You can still declare in the trait body inheriting TraitOf some other stuff you would miss. Nevertheless, if you are to pass some default implementation in your trait, I feel you will end up declaring a plain trait.

You can have a look at my github project https://github.com/leonardschneider/macrogen

Feedback and comment welcome ;)

BR

Leo