7mind / idealingua-v1 Goto Github PK

This can't be done until we make distage compatible with scalajs

At the moment src_managed is being re-created on each compiler invokation.

It's completely okay, but in case someone wishes to use our code generator together with another one within the same artifact - it wouldn't work.

This is a rare case, so it's not important. Just recording for future reference.

• Primitive ADT members are explicitly disabled because of issues with ADT support in Typescript (the only language we use atm which supports ADTs natively, string | Something)
• From what I can understand there are some serialization issues

I believe it's possible to design a sane approach for TS ADTs.

• We should improve exception model and support exception throwing
• We should try to get rid of crappy javax WebSocket implementation (blocked by http4s/http4s#330)

Right now we have extensions, though we can't provide them any parameters from our definitions. It's a good thing but it may be required to change it one day.

1. We may reuse one of existing ORM-like libraries, like Doobie, Slick, Quill, etc
2. We may support SQL, CQL and maybe smth else

At the moment when something bad happens both client and server just times out.

We need:

• Modify HttpServer.makeResponse to support BuzzFail incoming message
• Support negative cases in RequestState
• Implement simple generic transport exceptions model
• When we have RPCPacketKind.RpcFail or RPCPacketKind.BuzzFail with ref set we should pass the exception into RequestState in both server and client.

RN we have a lot of unsafe references like IRTServiceResult, IRTInContext, etc

We should have an IDL type for the native ByteArray/ByteString type of the target language

1. We definitely need lense generator for scala
2. Other languages would be nice as well.

ServiceId + MethodId are not enough to identify an overloaded method

At the moment we don't resolve a lot of name conflicts leading to obscure error messages, like:

• We may define an entity name clashing with a keyword in one of the target languages (like for),
• We may define an entity name clashing with a runtime class/namespace/symbol name in one of the target languages (like Result, Int),
• We may even clash with some implementation-dependent names, like scala/bug#10926
• alias UserId and data UserID breaks TS compiler. Most likely we should compare all the names case-insensitively during typespace verification

Feel free to extend the list

At the moment the problem is partially mitigated by prohibiting lowercase class names and IRT prefix but that's not enough.

Seems like the correct solution would be:

1. Translator provides NamingPolicy to the typespace.
2. Typespace performs all the necessary computations and renames and feeds translator back with properly named entities.

Also most likely we may need to enrich our identifiers with language-specific identifiers, like case class ClassId(abstract: String, specific: String)

Low-prio atm, we don't have capacity

We may want to dogfood IdeaLingua's IR AST by compiling it from IdeaLingua definitions.

This would allow some novel forms of staging:

• IDL compiler could have a mode that just parse domain definitions and dump the IR AST in transport format. That would allow backends to be written in any language supported by idealingua.
• IDL compiler could have a mode that accepts IR AST in transport format, omitting the parsing step. That would allow frontends to be written in any language supported by idealingua.

Low-prio atm, we don't have enough capacity

Related: 7mind/izumi#90

1. Additional semantic
2. Implementation isn't strictly required
3. Still possible to implement an "always UTC" wrapper

Enforcement problem: in some languages we don't have enough native types to express the concept

To be used for external API models

We wish to be able to generate several domains from just one definition: a company may wish to generate public API and internal API on the basis of just one definition.

We should be able to tag domain entities (like public, private) and then filter out everything what doesn't match to a specified tags during compilation

Low-prio atm, we don't have capacity

Related: 7mind/izumi#90

1. We may say "maybe you meant Apple instead of Sapple?" instead of failing immediately
2. Another common issue: wrong case. WorkForce vs Workforce

https://www.joyofdata.de/blog/comparison-of-string-distance-algorithms/

We may try to generalize current design further by implementing a function computing difference between any two arbitrary structural definitions.

It would be possible to express all the narrowers, wideners and casts using this approach.

Not urgent.

Related: 7mind/izumi#215

Be careful: recursive structures

1. (scala) All the imports should be done with _root_ prefix
2. We need to minimize all the type references
3. Right now we have to use dirty tricks to avoid duplications/clashing imports. Though we may include imports into RenderableProduct and treat them as entities.

We need to preserve information of entities requiring an import.

Low-prio atm, we don't have capacity

Not a critical issue for now: we have no ways to define such domains on user level.

Though it may affect 7mind/izumi#59

1. ScalaJS would help

Faces the same enforcement problem as #43 (in some languages we don't have enough native types to express the concept)

We should add parseable descriptors into all the artifacts produced.

Related to 7mind/izumi#201

We wish to provide a way do define things like "non-empty list", "string matching regex", "integer within an interval"

Probably we should provide a way to specify arbitrary metadata and compiler extensions able to introduce custom types

Related: 7mind/izumi#90

We may implement a tool converting a JSON into a set of model drafts.

This API call:

{
  "personalizations": [
    {
      "to": [
        {
          "email": "[email protected]",
          "name": "John Doe"
        }
      ],
      "subject": "Hello, World!"
    }
  ],
  "from": {
    "email": "[email protected]",
    "name": "Sam Smith"
  },
  "reply_to": {
    "email": "[email protected]",
    "name": "Sam Smith"
  }
}

may be translated into

data emailuser {
   email: str
   name: str
}

data emailData {
   to: list[emailuser]
   subject: str
}

data {
   personalizations: list[emailData]
   from: emailUser
   reply_to: emailUser
}

This may allow us to interoperate with simple REST data providers.

Also we may convert swagger and other popular formats into our models. Kinda related: #19

We may accumulate requests in client and process them in batches.

On server side we should expose additional endpoint taking a list of identified queries.