projectfluent / fluent-kotlin Goto Github PK

I think we could also experiment with sealed classes to express sum types, like so:

sealed class VariantKey {
    data class NumberKey(val key: NumberLiteral) : VariantKey()
    data class IdentifierKey(val key: Identifier) : VariantKey()
}

And then, in the parser code:

    fun getVariantKey(ps: FluentStream): VariantKey {
        val ch = ps.currentChar()

        if (ch == null) {
            throw ParseError("E0013")
        }

        val cc = ch.toInt()

        if ((cc >= 48 && cc <= 57) || cc == 45) { // 0-9, -
            return VariantKey.NumberKey(this.getNumber(ps))
        }

        return VariantKey.IdentifierKey(this.getIdentifier(ps))
    }

This is actually close to how enum can be defined in Rust, although (perhaps a bit surp not how we do it in fluent-rs, where a number literal in a variant key position is not the same struct as a number literal in an expression.

I like this approach because it helps document in the code what a variant key can be (rather than searching for all subclasses deriving from the VariantKey interface. OTOH, I realize there are consequences to whast the AST hierarchy looks like. Serializing to JSON, for instance, would be a bit more involved.

Originally posted by @stasm in https://github.com/Pike/fluent-kotlin/pull/2

When humans edit Fluent content, they're most often editing straight-forward patterns.

They shouldn't be bothered with leading/trailing whitespace, or escaping {.

Thus we should create a representation of Patterns which is editing-friendly.

Pontoon has code for similar purposes in https://github.com/mozilla/pontoon/tree/master/frontend/src/core/utils/fluent.

Working title is AntiPattern, as combining Patterns and AntiPatters is pure energy. This name should not stick.

Please take a look at ProcessorTest for an example. It happens when pattern consists of the mix of TextElement and Placeable elements and TextElement has trailing spaces.

Since a 0.1 release is already out there, having it available as a package in a Maven repo is needed for the community to start creating tooling for Project Fluent (IntelliJ integrations, Framework support, etc.) Instructions on how to do this with GitHub Actions are available here

(…) this doesn't handle \U123456 yet. I know it's my fault for not doing so initially, but good to call out.

Originally posted by @Pike in #42 (comment)

There's a _ snake in the visitor pattern, let's get rid of it.

Right now, reference tests just check the top level item type.

This made a couple of bugs slip through the cracks, we need to dive deeper into the comparison logic against the reference json.

I got some thoughts, taking.

We should have some documentation for fluent-kotlin and fluent.syntax.

I've looked into generated documentation via dokka, and the output doesn't ring a bell for me. Side thing that I noticed is that all classes of a package are listed in one go, which makes me think that we should put the Visitor and childrenOf into its own package.

There's not a lot of customization we can do there, short of writing our own output generator. It's OK to look at for things like "public" vs "private", though. What needs a doc string, etc.

My suggestion is to not rely on generated docs for now, and to just write some RST in sphinx, like we do for python for much of it.

Implement a port of the fluent.bundle from projectfluent/fluent.js to ease the usage of fluent-kotlin

Currently, the withSpans option doesn't do anything.

The methods we use in js and python land sadly don't work.

The visitor pattern would be good to have.

We can probably build on what BaseNode.equals does.

When porting the parser, I moved the support of nested expressions from expressions to placeables, and that's wrong. We should fix that.

Probably also a pretty straight port from the TS impl.

Seems that separate files inside a package are not considered to be "different" by at least dokka.

We should probably move visitor into its own package.

equals is special in Kotlin, https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/equals.html.

Probably good to make it call into our implementation, but not with the default flags to ignore spans.

The sidebar on Parser.kt is full of comments by IDEA on how to improve the code.

Among which are manyer "could be private", but also others.

So far, we only have the reference tests, but not the structure tests, which deal with error detection.

We should port those.

Related issues: #21 for the actual comparison to json. #16 could be related in terms of hidden bugs.

Let's get some basic tests up on the Java side. Not java 7 yet, as that requires a different junit, but at least java 8+