Extensions / Extension methods

Skip to first unread message

Nick Howard

Feb 17, 2015, 1:55:01 PM2/17/15
to mi...@googlegroups.com
Macros in Mirah are really powerful, but I don't think they are super friendly to use. They expose the guts of the compiler, and require at least some familiarity with the idea of manipulating syntax trees. In addition to that, extending classes that already are defined is tricky and requires knowing about methods on objects inside the compiler.

I think we should have a new abstraction on top of macros for providing extension methods.

I started a gist with some strawman documentation of how it might work.



Raum Dellamorte

Feb 17, 2015, 8:30:03 PM2/17/15
to mi...@googlegroups.com
I started looking into Kotlin recently.  I discovered it from a mention on Quora.  It does a few things syntactically similar to Mirah, but it has a runtime which is what Mirah avoids.  Where we have def, they have fun, short for function, obviously, but method/function definitions have almost the same style.

We would say
def hello(world:String):String

and they would say
fun hello(world: String): String {

In line with what you're talking about, if they want to extend String, they would say
fun String.myExt(whatever: Class) {

I'd like to be able to say
def String.myExt(whatever:Class):void

but after a quick glance at your proposal I don't have a serious problem with what you've laid out.

In Kotlin, extensions are available to all classes/functions within the same package, and that seems reasonable.  I don't know how close we can get to similar functionality without a runtime.  I am in no way saying we should be just like Kotlin, I'm only wondering what's stopping us from having similar conveniences. How smart can we make our compiler?

The one thing that seems a bit unfortunate is the possible mirahc dependency due to compiler annotations that you mentioned.  I don't quite understand how a separate jar for macros avoids this.

Separately, Kotlin has a shortcut for defining instance variables that I like.  Mirah-ized, it would look like def initialize(@foo:int, @bar = true):void thus avoiding having to assign @foo and @bar within the initialize method.  Can we already do this and I just don't know?  If not, can it be done?

Nick Howard

Feb 17, 2015, 10:25:06 PM2/17/15
to mi...@googlegroups.com

The syntax I've be mooting is kind of like Ruby's refinements. It allows one extension to extend multiple types. I'm not super attached to it, but it's the one I like most of the ones I've come up with so far.

The separate jar works by allowing you to have it be a mirahc compile time dependency, but not a javac or runtime dependency. It's ok for the annotations to be in the runtime class path though, because they have the compile time flag set and are ignored by the jvm runtime.

As far as package access goes, I've been thinking it'd be nice to have something like Scala's package.scala files where default imports for a package could be defined. Package level extension usage could be setup there.

On initializers that set ivars like that, my feelings are mixed. I think if you have a large number of fields in an object, its construction should start to feel awkward because that's a sign that the class has too many responsibilities.

On the other hand, it'd be really cool if making struct-like classes were easier. I'm not sure whether that should be in mirahc, or in a library. It should be doable using macros without changing the compiler itself.

You received this message because you are subscribed to the Google Groups "The Mirah Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mirah+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Steve Hannah

Feb 17, 2015, 11:47:58 PM2/17/15
to mi...@googlegroups.com

On the other hand, it'd be really cool if making struct-like classes were easier. I'm not sure whether that should be in mirahc, or in a library. It should be doable using macros without changing the compiler itself.

By "struct-like", do you mean Value Objects (like this: http://openjdk.java.net/jeps/169)?  Or something else?
If you do mean Value Objects, how would to go about doing this using macros?


Nick Howard

Feb 18, 2015, 12:24:46 AM2/18/15
to mi...@googlegroups.com

Value objects are a good vote in favor of creating a syntax and implementation in the compiler itself, because then we could intrinsify them as native value objects on the jvm if you target one that supports it.

What should they look like?

Reply all
Reply to author
0 new messages