https://kotlinlang.org logo
Join Slack
Powered by
Maybe stupid question but why kotlin doesn’t have ...
# announcements
c
Maybe stupid question but why kotlin doesn’t have a unaryTimes operator? I a not sure if this does make sense mathematically but I am facing a situation where it would be really handy to overload the * while writing a DSL like this
Copy code
foo { // will invoke some object as this
    0 {
        // create some list based on Foo and get 0 index of list 
    } 
    * {
        // create some list based on Foo and get all entries of list
    }
}
https://kotlinlang.org/docs/operator-overloading.html
👋🏼 1
n
feels kinda pointer-y
➕ 1
you could open a feature request
I'm curious to know what their logic is around what unary operators get added
you're already using 
+
I presume?
put that in some ``` please 😄
c
I am already using it and * would feel natural while using the DSL for the given usecase. I added an examole
Oh damn I am on my mobile sorry haha
n
Copy code
foo { // will invoke some object as this
    0 {
        // create some list based on Foo and get 0 index of list
    }

    * {
    // create some list based on Foo and get all entries of list
    }
}
I'm waiting for a build 😛
I'd probably say 
n
or 
all
instead of 
*
☝️ 1
👍 1
c
yeah thats what im doing right now. i have a function called 
findAll
. but wenn you need to use it a lot it feels a bit clumsy. here is a the real world example. https://github.com/skrapeit/skrape.it#parse-and-verify-html-from-string instead of findFirst you can already invoke an Int to find matching elements by index calling unary times would feel like the natural consequence to me. espacially in the context of css query selectors to pick html elements from a html document
n
what if you did 
find * {
and made 
*
an infix operator?
c
uuuh
nice idea, that would be possible
n
other than that, I'm out of ideas 🙂
c
i think i will go for the infix function an a override for times as well es having an infix function with an Int paramter. thereby it is highly readable and feels consistent in use. e.g.
Copy code
htmlDocument("""
        <html>
            <body>
                <h1>welcome</h1>
                <div>
                    <p>first p-element</p>
                    <p class="foo">some p-element</p>
                    <p class="foo">last p-element</p>
                </div>
            </body>
        </html>""") {

        h1 {
            find 0 {
                text toBe "welcome"
            }
            p {
                withClass = "foo"
                find 0 {
                    text toBe "some p-element"
                    className  toBe "foo"
                }
            }
            p {
                find * {
                    text toContain "p-element"
                }
                findLast {
                    text toBe "last p-element"
                }
            }
        }
    }
thx for the great idea
but just for curiosity, where would i open the feature request for lets say things like an unaryTimes operator?
n
https://youtrack.jetbrains.com/issues/KT ? you might also discuss on the forum or #C0B9K7EP2. if it was bigger, a KEEP would be appropriate, but I feel like a KEEP would be more like...to allow any single-character unary operator-type thing (which tbh would be gross IMO)
👍 1
c
ok i’ll try to explain my point in the propsals channel and see if it is a stupid idea for some reason or if people think it sounds legit 😄
n
IMO the main pushback will be -- we want to avoid going down the Scala route where there are a lot of operator-y methods, like...arbitrary chains of symbols
is this just another step towards "well why not have every symbol on the keyboard be a unary operator"
🤷‍♂️
but fwiw, I think + - * / might we well be
...maybe not /, that's always a binary operator
c
Good points
n
worth a shot anyway 🙂
🙂 1
n
fwiw I think also part of the reason why 
infix
exists is exactly to avoid the need to add lots of symbols with relatively low usage. Traditionally, people have used operators a lot in DSL's in weird ways, mostly just because they wanted infix really badly.
👀 1
c
y
This could also be a bit awkward, but you could possibly do "`*`" as in wrap it up with backticks and then you can define it as a normal function
5 Views
Open in Slack
PreviousNext
Powered by