search

clj-commons / byte-streams

A Rosetta stone for JVM byte representations
417 stars 33 forks source link

Deprecate single-segment top-level namespace #53

Closed piotr-yuxuan closed 2 years ago

piotr-yuxuan commented 2 years ago

Single-segment top-level namespaces are hard to manage with native compilation.

For more context, see https://github.com/clj-easy/graalvm-clojure/pull/51#issuecomment-999383626

As a suggestion I updated the version number, but I leave the final choice to the maintainers.

KingMob commented 2 years ago

@piotr-yuxuan

This is quite a big change, unfortunately, and I really don't like the duplication. Realistically, few people upgrading will notice they need to change namespaces, which means keeping copies in sync forever. One alternative is to move the code, but expose it in the original namespaces. Elsewhere, borkdude suggested sunsetting the old ns, and only making updates in the new ns, which I'm also not a fan of, since people won't notice upgrades do nothing for them. It may be better to use new project names (e.g., byte-streams2), but that's a bit weird for a project in maintenance mode.

Regardless, I'd like to hear more about the situation with GraalVM, and why it can't handle single-segment namespaces. Can they actually not be included, or is it just that it's tedious to list them out as they have no package? How big an issue is this?

KingMob commented 2 years ago

OK, after chatting with borkdude, I don't think it will be so bad.

However, if we're going to do this, I'd prefer to place primitive-math under clj-commons with byte-streams. I can introduce you to the clj-commons admins if you want to be the maintainer for primitive-math, or I can deal with it myself. Let me know which you prefer.

KingMob commented 2 years ago

Closed by #54.