https://kotlinlang.org logo
Join Slack
Powered by
the `where` function would take an AST representat...
# language-proposals
g
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
@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
"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
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
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
it.fName == "bob"
can be translated into 
WHERE fName = "bob"
, but an extension function will require fetching unfiltered results
g
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
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
I mean, the LInq community might disagree with you
but i gotta go to a meeting
a
Copy code
dbConnection.where(Model::fName eq "bob").where { it.fName.extensionCall() }
g
but its worth mentioning thats not even the worst of it
a
heh
g
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
Open in Slack
PreviousNext
Powered by