Feature renamed to extension type about co19 HOT 8 CLOSED

Some properties of extension types are different from the corresponding properties of inline classes, so we'll need some additional PRs about the expected behavior.

In particular, there is no instance variable declaration, and the representation name and type are specified as (<type> <identifier>) in the declaration header (the meaning of which is the same as final <type> <identifier>; in the declaration body plus a constructor that does this.<identifier> to initialize it).

Another new thing: It is allowed for an extension type to declare that it implements .... T .... for some T that aren't extension types.

But let's look into that later on, for now we just need to stop expecting an error for things like extension type E(int i) implements int {}.

from co19.

Just confirmed with @johnniwinther: The flag that enables the extension type feature will be inline-class, so that particular bit escapes the rename. Other than that, the phrase 'inline class' and terms like 'inline-class' should not occur anywhere.

from co19.

Perhaps this could be done in two steps, such that the diffs will be informative: First move all affected tests from /inline-classes/ to /extension-types/ (I probably got the directory name somewhat wrong, but the idea should be clear), and then change the tests to use the new syntax. Or vice versa, whatever is most convenient.

If we do both things in the same PR then I'm afraid it's going to look like deleting a bunch of libraries and adding a bunch of different libraries, with no connection between the two.

from co19.

Why do we need a connection between obsolete inline classes tests and the new extension types ones? Why not to simply have new tests first, and then delete the old ones? Otherwise there will be mess with renaming, large diffs etc

from co19.

I thought the "move then edit" approach would yield the smallest diffs:

If there is no connection then the diff will be 2 times everything (one for delete old library, one for add new library, no connection), and it would be necessary to start from scratch with every test. It's very easy to skip over the 'delete file' changes, but this is still 1 times everything.

But with "move then edit" we'd only need to consider the changes in every test. So there would be lots of situations where something like inline class V { is changed to extension type V(int i) {, and a couple of lines are deleted below that (an instance variable and a constructor), and the rest of the declaration would presumably be unchanged. Similarly, lots of usages (call sites, type declarations) could remain unchanged.

from co19.

Ok, I understand your idea. Ok, let's try to do the next PR this way, but I suggest "edit then move". Some tests needs to be deleted, some added, some reordered. So, first, "edit" that is changing an exising tests and adding new ones, then "move". That is moving, renaming, reordering and deleting unnecessary tests

from co19.

Sounds good, thanks!

from co19.

All inline classes tests transformed to extension type tests. Go on with extension type tests as part of #1400

from co19.