https://kotlinlang.org logo
#language-proposals
Title
# language-proposals
g

groostav

02/10/2017, 10:36 PM
the
where
function would take an AST representation of the body --effectively it takes source code, and then transcompiles the AST for
it.name == "bob"
into
WHERE c.name == bob
, of the equivalent mongo thing (iirc something resembling
{"where" { eq { field { "fname" }, "bob" }}
a

aimozg

02/10/2017, 10:53 PM
@groostav I think AST in that use case will give a dangerous illusion of having every feature of Kotlin syntax translatable to target language and something not supported could be detected only in runtime.
I use query builders like
Copy code
val q2 = Thing.TABLE.simpleQuery {
			Thing::name eqAny listOf("thing1","thing2")
			Thing::id eq 2
		}
Do you really need something more complex than infix functions and property references? I'd say
Copy code
val result: Iterable<Model> = dbConnection.where { Model::fName eq "bob" }
looks nice enough.
g

groostav

02/10/2017, 11:04 PM
"looks nice enough"...
scala looks nice enough
what your describing is effectively breaking the AST down through some of the nifty reflection mechanisms built into kotlin --the fact that
Model::fname
is trivially converted to a
KProperty
is a really cool feature, but it doesn't go anywhere near far enough imho. When you get into queries of even minimal sophistication this is going to get ulgy
a

aimozg

02/10/2017, 11:10 PM
what are going to do with
Copy code
fun String.niceExtension(other:String, param:ParamEnum):Boolean
used in
Copy code
dbConnection.where { it.fName.niceExtension("bob", ParamEnum.ALPHA) }
?
g

groostav

02/10/2017, 11:10 PM
the AST for that expression? This is what C# and jinq both do now
I think Jinq might actually attempt to recover your extension function
but yeah, the semantics around
inline
are likely to be a boon to kotlin that C# doesnt have
but yes @aimozg several interesting question are going to come up in this things implementation
a

aimozg

02/10/2017, 11:12 PM
it.fName == "bob"
can be translated into
WHERE fName = "bob"
, but an extension function will require fetching unfiltered results
g

groostav

02/10/2017, 11:13 PM
yes im very much aware
so what the MongoDB Linq Driver does
because MongoDB is so focused on the driver side, is simply apply the filter in the drivers process space
consider
it.extensionCall() && it.age > 25
the db will apply an optimized
it.age > 25
, using whatever seocndary indexes or other DB magic it has, then send that back to the driver (the library), to apply the rest of the filter, which includes a call do your extension methods
what the SQL driver does I dont know since I havent used it
but you might see things like `OperationNotSupportException`'s
a

aimozg

02/10/2017, 11:15 PM
that would mean you'll need to remember which subset of Kotlin is supported in a translator. But if you write your DSL, you'll have limited syntax during compile-time. And I'd rather have features that make creating DSLs and builders easier and less ugly than writing Kotlin-AST-to-DSL transpilers
g

groostav

02/10/2017, 11:17 PM
I mean, the LInq community might disagree with you
but i gotta go to a meeting
a

aimozg

02/10/2017, 11:17 PM
Copy code
dbConnection.where(Model::fName eq "bob").where { it.fName.extensionCall() }
g

groostav

02/10/2017, 11:17 PM
but its worth mentioning thats not even the worst of it
a

aimozg

02/10/2017, 11:17 PM
heh
g

groostav

02/10/2017, 11:17 PM
the worst of it is argument order
the guy who runs the fabulous adventures in coding explicitly dropped support for named-arguments from linq expressions
because the ramifications to the users of the Expression object can be too bizarre
but I still think its enormously valuable
brb meeting
Eric Lippart, head of the C# project for a while, thats his name
@pniederw regarding using macros in kotlin, I actually think Linq is a stroke of genius when it comes to macros: a huge amount of the bugs in macros comes from a failure to properly apply the front-end of a compiler; a macro author is tempted to start rooting-around in string values of source code, which is begging for disaster. But by productizing (APIzing? weaponizing?) the AST in the way microsoft did, they basically did an enormous amount of the heavy lifting needed by macros for the would-be macro author. In short, this feature would enable a huge number of macro-like functionalities without the kinds of horrifying bugs you often associate with macros.
6 Views