Extensions / Extension methods

[Nick Howard]

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.

https://gist.github.com/baroquebobcat/35b6f82cab6ad17bd82a

Thoughts?

--

-Nick Howard
http://blog.baroquebobcat.com/

[Raum Dellamorte]

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]

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]

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?

Steve 

[Nick Howard]

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?

--