https://kotlinlang.org logo
Join Slack
Powered by
It would be really nice for DSLs to be able to ove...
# language-proposals
m
It would be really nice for DSLs to be able to overload assignments to a String 🙃 Dynamic configuration in this particular case.
👍 1
👎 4
o
a little different, but similar 🙂
m
Yeah that’s related indeed :)
h
Does that mean that the property name, which is a string is assigned the string value "test"? What ist the reason in your example that it can't be a normal var property and the lambda one with receiver? (Just curious)
m
No, it's a Map internally. There are no properties.
h
Ah, so its the same as ["name"] = "test" here? Does your usecase prevent you from defining a class with properties delegating to an underlying map, using a lambda with receiver in your usecase? Just asking because i would prefer that.
m
Yes, because such configurations are very dynamic. It may come from Kotlin DSL, a HOCON file or a simple Map.
h
I c. Not Sure whether i would like sth to look like a property assignment but is sth that can't be resolved statically ^^" does it make sense to make your proposed syntax available for exising operator fun set then?
m
I don’t think 
set
is suitable here as that’s meant to be used with 
[…]
. I’d call it 
assign
just like suggested in the PR comment above.
b
I personally don't like the idea adding an alternative meaning to 
=
. How about instead of assignment overloading, adding an association operator that uses 
:
instead of 
=
?
m
:
denotes a type of something 🤔
l
I don't like the proposed syntax because it reads like 
1 = 3
(which is mathematically false)
m
Equality is 
==
in Kotlin 🤔
l
With the proposed syntax, one could still write 
"yes" = "no"
or 
"1" = "3"
Does it mean 
"yes"
just became 
"no"
? one could wonder.
Assinging a value to a string or a constant value doesn't make sense to me
Then, if it works for 
String
, some would ask for it to work on 
Number
as well blob upside down
m
Whether it makes sense depends on the context. DSL always depends on the context and can be very different depending on it. Thinking about it this problem is very similar to a special syntax for creating map values. Kotlin doesn't have that (yet?) but it would solve the same problem. I think there was a YouTrack issue somewhere for that.
l
Well, in Go and some other funny (funny, not fun) programming languages, you can define what 
true
and 
false
mean in a context. Would sure be handy for a politics DSL! I'd prefer the assignment operator to stick to its meaning regardless of the context. Maybe another (new?) operator like 
<-
or other could be used instead.
m
It is an assignment. It's just that you assign to a key, which can be any value. It's basically a shortcut for 
this["yes"] = "no"
It's just scoped automatically in DSL.
l
The thing is that is not just ripping out the 
this
, but also the get operator (
[ ]
), and past that point, the semantic meaning is entirely different.
m
Yeah. And 
["yes"] = "no"
looks like a destructuring 😅 There's probably no way to solve that with existing syntax.
e
Can we come up with an alternative new operator instead of overloading assignment (which is scary and presents tons of problems)?
m
We could: 
:=
, 
=>
, 
<-
, 
~=
But I’m not sure if such a feature is worth additional syntax until we find more common use cases.
l
To me, 
:=
is the less confusing option of what's on the table so far. 
=>
might be confused with JS lambdas, 
~=
is vague I'd say, 
<-
might seem to go in the wrong direction (and so could it the other way around).
m
OTOH overloading 
=
would allow implementing type coercion. And delegates are a special kind of assignment already.
@louiscad why is 
<-
the wrong direction? RHS is assigned to LHS, so right to left.
It’s the opposite of a function where input on LHS leads to output on RHS in the signature.
l
Another possiblity is to give a new meaning to 
:
when it's after an expression (and keep its current meaning when it's after a declaration)
@Marc Knaup In PHP, associative arrays (which are the same as `Map`s and dictionaries) use 
=>
, which is the opposite direction of 
<-
. Both make sense in some contexts, but Kotlin is a general purpose programming language.
m
I think 
:
can quickly lead to confusion. I personally wouldn’t consider PHP a good example for anything - except as a counter-example 😅
But yeah, 
=>
is too close to functions anyway.
I already get mad when jumping between 
var
, 
val
and 
let
between Kotlin, JS and Swift because they’re too similar yet the meaning changes.
l
I didn't specify whether is was a good or bad example, just that the direction of the arrow has important implications
m
There’s also 
<<
and 
>>
since they’re not used for bit shifting.
⬅️ 😄
Alternatively instead of changing the operator we could change the LHS.
Copy code
$"bar" = "foo"
@"bar" = "foo"
#"bar" = "foo"
:"bar" = "foo"
&"bar" = "foo"
~"bar" = "foo"
Or without quotes if LHS should reference the value of a variable 
bar
instead of a String.
l
R syntax 😉
How would you call an operator named 
:
that does what you asked for in the first place? 
assign
?
m
LHS syntax is similar to JS objects with value as key. 
[foo]: bar
Well 
assign
is 
=
, isn’t it?
It’s an assignment in either case. Just not directly to a variable.
If you see it as a shortcut for 
this[a] = b
you could also re-use 
operator fun set
.
l
operator fun set
makes the most sense, yep, though it might get confusing to have one name for two syntax using a different symbol 🤔
m
The syntax isn’t really all that relevant but what the syntax does, right?
l
What is does is running some code, i.e. calling a function with two parameters or something. The syntax is quite important actually. It's like for bikes: the handlebars are very important to actually ride.
m
Yes, but both are keyed assignment:
Copy code
this["a"] = "b"
"a" := "b" // or whatever syntax
So it should be totally fine to have the same operator function name.
e
Open in Slack
PreviousNext
Powered by