Gosu's open type system


#1

Hi Kotlinders!

Recently Carson Gross gave a presentation on Gosu and their new Web Application framework, Ronin at the Sacramento Groovy User’s Group.  I was blown away that their type system enables library writers to create new types from property files, Json files, SQL files, WSDLs, etc.  I’m wondering if Kotlin has any concept for doing things like this.  So you could have a SQL file that had:

CREATE TABLE Person
(
lastName varchar(255),
firstName varchar(255)
)

And then you could do something like:

joeBlow = new db.Person()

joe.firstName = 'joe’
joel.lastName = ‘blow’

This is sudo code because I am not that familiar with Gosu syntax.

What was so cool is that with their intellij plugin they were able to get autocompletion and compile time error highlighting.  This also allowed them to build an awesome ORM tool that uses sql files like those above.  This is pretty similar to what Android does with the resource files except there is no code generation going on in the background.  You could also imagine template files for HTML where you could do things like:

List<Person> persons = service.getPeople()
view. persons.list.div.persons.insert {
  persons.each {
          new p(value: persons.name)
  }
}

And you could have compile time checking and auto-completion all the way through.  It seems like this sort of capability would be ideal for a templating system that could pull from static HTML files and output dynamic rendering from a class file instead of embedding logic and tags into an HTML file.

Is there any chance Kotlin will have the capabilty to do such a thing?

-Steve


#2

I wrote a fairly extensive review of Gosu's open type system last year:

http://beust.com/weblog/2011/05/10/open-type-systems/

The short version of it was: I like the idea of open type systems, especially coming from Java and its very draconian restrictions on the Class class, but I was left wondering if the comfort of being able to create types so easily was such a big improvement compared to either code generation or some type of proxying (no static support for this approach, though).

At the end of the day, I think it’s mostly a cost/benefit analysis: if you can add an OTS to your compiler without dramatically injuring your code base and without adding too much complexity to your type system, then you should go for it.


Cédric


#3

I have no idea what the cost would be but the benefit would be that people developing a new library/module in Kotlin would be able to potentially create new template types that allow for all the niceties of code completion and compile time checking without having to do code generation like in Android requiring a seperate process to be running or ide-plugin-development like Grails Domain classes.  That's an incredibly powerful tool when introducing a new library interface for something like json, html, wsdl, sql, etc.

That being said, I have no idea if that would be  hundreds or thousands of hours of development time.  Also it might hinder the performance of Kotlin.  I just don’t know enough about their compiler to speak about that.

-Steve


#4

Haha then maybe you can answer me a question I have been asking myself for a while now. How can this gosu class creation/enhancement magic be compatible with type safety? From your example, how can the compiler know that host and port are properties of the HostProperties class? Is the compiler doing that by running custom code at compile-time ?


#5

Yes, it basically saves you from a code generation step.


#6

Oups you answered too quickly while I was updating my question sorry !


#7

We are considering supporting some kind of type loaders (BTW, it's not unique to Gosu, F# has it, too). We've done some initial prototyping to make sure it's possible to do, but this is just a proof-of-concept, a little early for including into the trunk.


#8

Carson mentioned that they had spoken to the F# guys but apparently they had different goals.

Would the Kotlin type loading allow for building libraries with new file types?  I.E. using HTML files or SQL files as types?

Also, would this have any effect on performance?  Does it introduce some type of metaobject protocol?

Have you taken a look at Ronin (Gosu’s Web Application Framework) and their ORM?  It didn’t really dawn on me how powerful the open type system was until I saw that.  


#9

Would the Kotlin type loading allow for building libraries with new file types?  I.E. using HTML files or SQL files as types?

Not sure I understand the question: to me this is the whole purpose of having type loaders.

Also, would this have any effect on performance?  Does it introduce some type of metaobject protocol?

The prototype we made simply rewrote all the code to make it use some more verbose libraries, e.g. DOM object for XML. We have to pay some compiler performance for having types loaded, though. No impact when you don't use the feature.

Have you taken a look at Ronin (Gosu's Web Application Framework) and their ORM?  It didn't really dawn on me how powerful the open type system was until I saw that.

I kind of watch it with the corner of my eye, but for us type loading is rather far away for now.

#10

If you get to the point where it can be built I would LOVE to try to build a prototype library using that functionality.  Please involve me.