2 ms·

I think the idea is the kernel of something very interesting. TA is right - in typed languages especially, why not add some extra metadata what would render man

I think the idea is the kernel of something very interesting. TA is right - in typed languages especially, why not add some extra metadata what would render many changes non-breaking? I think part of our hang-up is that we tend to think of code and data in very separate categories (except for literals, of course)--and only allow treating code as data after a lexer starts processing it (or via reflection or first-class functions at run time). Correcting this category error and adding metadata (not just types) could yield all sorts of interesting ideas. Like - as TA suggests, why not encode the notion of how a function signature has changed over time to enable automatic migrations?

ivan_gammel 2y ago
It’s not going to work. You cannot capture the meaning of the change with metadata. Let’s say you have this change: BigDecimal doSomething(); to Money doSomething(); In theory metadata can capture the migration from a plain number to Money#amount() and compiler will generate a facade for the client code. But simply discarding the currency will have disastrous effects at some later point. Even relatively simple migration String->Number may go wrong without semantics. Language feature allowing such metadata and migrations will be a minefield.
- TimTheTinker 2y ago
  Sure, there are lots of examples of lossy migrations, even in databases. That doesn't mean migrations in general aren't a good idea. And it doesn't invalidate the notion of metadata for code in general and all the possibilities that opens up.
  - ivan_gammel 2y ago
    When I was writing about shallow analysis, I was meaning that we need to see those possibilities beyond trivial cases. It sounds cool on the surface, but the devil is in details. There are lots of examples I can come up with in few minutes of thinking that show how this idea may not work. I would really like to see how this may work in a way where it will do more good than harm.
AtlasBarfed 2y ago
A lot of that kernel is that dependency information is grossly coarse. For the vast majority of langs I ve used it is simply the library name: not even a library version (build files like gradle will). The node approach is very fine grained libraries, but that makes its own headaches Really every function or interface invocation has an implicit version number. It should be explicit in the code, and that assumes major minor breaking change versioning.

ivan_gammel 2y ago

It’s not going to work. You cannot capture the meaning of the change with metadata. Let’s say you have this change: BigDecimal doSomething(); to Money doSomething(); In theory metadata can capture the migration from a plain number to Money#amount() and compiler will generate a facade for the client code. But simply discarding the currency will have disastrous effects at some later point. Even relatively simple migration String->Number may go wrong without semantics. Language feature allowing such metadata and migrations will be a minefield.

TimTheTinker 2y ago
Sure, there are lots of examples of lossy migrations, even in databases. That doesn't mean migrations in general aren't a good idea. And it doesn't invalidate the notion of metadata for code in general and all the possibilities that opens up.
- ivan_gammel 2y ago
  When I was writing about shallow analysis, I was meaning that we need to see those possibilities beyond trivial cases. It sounds cool on the surface, but the devil is in details. There are lots of examples I can come up with in few minutes of thinking that show how this idea may not work. I would really like to see how this may work in a way where it will do more good than harm.

AtlasBarfed 2y ago

A lot of that kernel is that dependency information is grossly coarse. For the vast majority of langs I ve used it is simply the library name: not even a library version (build files like gradle will). The node approach is very fine grained libraries, but that makes its own headaches Really every function or interface invocation has an implicit version number. It should be explicit in the code, and that assumes major minor breaking change versioning.