Здравствуйте, Sinix, Вы писали:

S>Diamond inheritance разруливается через явные вызовы:

Правильный подход. Мы в Нитре такой же выбрали. Еще можно от порядка указания плясать, как в Скале. Но мне кажется это слишком ненадежно.

S>Текущее предложение предусматривает поддержку со стороны CLR и возможность добавлять новые члены в интерфейс, не ломая бинарную совместимость.

Вот здесь действительно очень тонкий момент. Дело в том, что такие методы фактически должны копироваться в окончательный класс. Такое копирование можно производить во время компиляции (как делаем мы в Нитра) и во в рантайме. Но в рантайме или во время ngen-а. Во время компиляции может получиться так, что один класс будет скомпилирован с одной версией интерфейса, а другой с другой. При этом сам интерфейс не изменится, а изменится только код этих методов. Это может привести к сложно понимаемым ошибкам.

Оптимально, чтобы такую сборку из кусочков производили JIT и ngen. Тогда во всех классах будет одна и та же версия кода.

Но для этого нужно курочить ратнайм.

S>Остальные фичи с разбивкой по milestones можно глянуть тут.
S>Как обычно, любая может быть отменена / поменяться в любой момент времени.

Боюсь, что как обычно просле кучи грандиозных планов на выходе будет что-то урезенное или вообще отложат до лучших времен. А фича действительно очень полезная. Я вот в Nitra ею начал пользоваться и не нарадуюсь никак. Без нее столько копипасты или дублирования пришлось бы сделать, что становится грустно.

Здравствуйте, Sinix, Вы писали:

S>Diamond inheritance разруливается через явные вызовы:

Правильный подход. Мы в Нитре такой же выбрали. Еще можно от порядка указания плясать, как в Скале. Но мне кажется это слишком ненадежно.

S>Текущее предложение предусматривает поддержку со стороны CLR и возможность добавлять новые члены в интерфейс, не ломая бинарную совместимость.

Вот здесь действительно очень тонкий момент. Дело в том, что такие методы фактически должны копироваться в окончательный класс. Такое копирование можно производить во время компиляции (как делаем мы в Нитра) и в рантайме (а так же во время ngen-а, что тоже можно считать "рантаймом", так как он происходит на машине клиент, когда все длл-и известны). Во время компиляции может получиться так, что один класс будет скомпилирован с одной версией интерфейса, а другой с другой. При этом сам интерфейс не изменится, а изменится только код этих методов. Это может привести к сложно понимаемым ошибкам.

Оптимально, чтобы такую сборку из кусочков производили JIT и ngen. Тогда во всех классах будет одна и та же версия кода.

Но для этого нужно курочить ратнайм.

S>Остальные фичи с разбивкой по milestones можно глянуть тут.
S>Как обычно, любая может быть отменена / поменяться в любой момент времени.

Боюсь, что как обычно после кучи грандиозных планов на выходе будет что-то урезанное или вообще отложат до лучших времен. А фича действительно очень полезная. Я вот в Nitra ею начал пользоваться и не нарадуюсь никак. Без нее столько копипасты или дублирования пришлось бы сделать, что становится грустно.