manifold

Something like manifold-sql[1] for ts would be awesome. 1. https://github.com/manifold-systems/manifold/blob/master/man...

Right, my sentiments too. I was expecting type-safe SQL. The manifold-sql[1] project has this down. 1. https://github.com/manifold-systems/manifold/blob/master/man...

Yep. They demo great, but unless your use case is on the trivial end, you either find yourself making unreasonable compromises or, if the tool provides API escapes, you’re not only coding, but hacking against the tool. In my view, mainstream languages like Java should offer static metaprogramming for library authors to make tooling like Rails possible and more approachable in IDEs. The manifold project[1] has something like this for SQL, but it’s obviously providing its own static metaprogramming layer over Java. Shrug. 1. https://github.com/manifold-systems/manifold/blob/master/man...

> 1) Yet another protocol etc. Agreed. > 3) The biggest challenge about data models is not auto-generated code I would say auto-generated code is most definitely the harder problem to solve, and I’d also go out on a limb and say it is THE problem to solve. Whether it’s JSON, XML, JavaScript, SQL, or what have you, integrating both data and behavior between languages is paramount. But nothing has changed in the last 40+ years solving this problem, we still generate code the same clumsy way… Chinese wall between systems, separate build steps, and all the problems that go with it. Something like project manifold[1] for the jvm world is in my view the way forward. Shrug. 1. https://github.com/manifold-systems/manifold

Generally, the idea is that there is no incompatibility between units. Money is a bit exotic given its abstract nature wrt units / exchange rates. For instance, physical dimensions store values as SI units, regardless of supplied unit, but retain the supplied unit type as a display hint. Here, the Length dimension illustrates working with amounts of any unit. Length orbit = 250 mi; Length moon = 238000 km; Length landing = moon + orbit; display(landing); // prints 148,136.344 mi display(landing.to(km)); // prints 238,402.336 km // where display(landing.to(mi) == landing.to(km)); // prints true // perhaps a better example Rate rate = 1.41 km/s; Time duration = 76 hours; Length distance = rate * duration; // make your own unit constants RateUnit kps = km/s; rate = 1.41 kps; You can play with the manifold-science[1] project, it implements t

Would be cool to hook this up as a manifold unit[1]. This way you could write code like: Money ask = 2.1M USD; What I don't see with the Java JSR is how exchange rate services are integrated (if at all?). In the best of worlds, as with manifold's units I could write. Money deposit = 300 USD + 500 EUR; Where internally the deposit automatically maintains the amounts separately and uses exchange rates only for spot display/calc, transfer, etc. 1. https://github.com/manifold-systems/manifold/tree/master/man...

Project manifold hacks into the the Java compiler with extreme prejudice via the javac plugin API to provide existing Java projects with seamless access to manifold's language extensions. This particular feature, manifold-sql, pushes the envelope with static metaprogramming.

The advantages of composition (or "true" delegation) over inheritance are well documented, but many languages remain poorly suited for it, particularly Java. In the influential book "Effective Java" the author advocates favoring composition over inheritance, yet Java provides little support for it. One is left having to write or generate large portions of boilerplate code to achieve the most basic form of interface composition. More pragmatic support for the feature requires language/VM intervention, such as with true delegation and mix-in traits. This isn't to say the author's claims about inheritance and composition aren't well intentioned, however in practice it is difficult to make use of this advice when the language he champions, nearly a quarter century later, still does little to facilitate his position. The library mentioned here

The manifold[1] compiler plugin for java offers a lot of features other languages like Kotlin provide, and innovates in some uniquely awesome ways like type-safe SQL, true delegation, etc. 1. https://github.com/manifold-systems/manifold

Manifold SQL[1] is a compiler plugin that lets you write _native_ SQL directly and type-safely in your Java code. - Query types are instantly available as you type native SQL of any complexity in your Java source - Query results are type-safe and API-rich and simple to use - Entity types are automatically derived from your database, providing type-safe CRUD, decoupled TX, and more - No ORM, No DSL, No wiring, and No code generation build steps - Use Manifold SQL simply by adding the javac -Xplugin:Manifold argument and manifold-sql and manifold-sql-rt dependencies to your gradle or maven build 1. https://github.com/manifold-systems/manifold/blob/master/man...

Use this command line interface (CLI) tool to produce a textual GitHub traffic report for any repository. The report is similar in format to GitHub's Traffic page, but includes additional features such as star diffs between usages, who starred/unstarred the repo, unique view ratio per top views, more. See the example[1]. Written in Java + manifold[2]. 1. https://github.com/manifold-systems/github-traffic/blob/main... 2. https://github.com/manifold-systems/manifold

manifold-sql[1] is a schema-first JPA alternative that lets you type-safely inline native SQL in Java source among other capabilities. DuckDB[2] is a high-performance, in-process database based on PostgreSQL specifically designed for analytics. Combining manifold-sql and DuckDB results in a uniquely productive platform for analytics with Java. 1. https://github.com/manifold-systems/manifold/blob/master/man... 2. https://duckdb.org/

A while back I built a science library supporting both physical and abstract dimensions. Almost immediately I discovered working with floating point numbers suck in that space and BigDecimal isn't much better in terms of managing scale wrt margin of error across calculations, Java doesn't make this easy. Rationals are in my view much better suited for science/math in that information cannot be unintentionally lost when using them. So I made a Rational for Java, and in the process _forced_ Java to work better with science and math.