Возник вопрос: почему хлопцы из Microsoft во 2-ом .NET не позаботились о generic-версии интерфейса ICloneable. Меня, например, это иногда напрягает ...

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

S>Возник вопрос: почему хлопцы из Microsoft во 2-ом .NET не позаботились о generic-версии интерфейса ICloneable. Меня, например, это иногда напрягает ...

А вот в Nemerle добавить не забыли...

public interface ICloneable<'a>

....... не сочтите за рекламу ......

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

S>Возник вопрос: почему хлопцы из Microsoft во 2-ом .NET не позаботились о generic-версии интерфейса ICloneable. Меня, например, это иногда напрягает ...

Ну сделай сам, делов то.

AVK>Ну сделай сам, делов то.

Не хочу сам. Хочу, чтоб стандартно было. Представляете, чё будет, если в каждой библиотечке будет по ICloneable. А если надо будет использовать эти библиотечки вместе ... — будут конфликты имён, надо будет вводить псевдонимы пространств имён в using-ах и прочая лубуда начнётся.

Не-е ... Такие вещщи должны быть в стандарте (IMHO, конечно) ...

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

AVK>>Ну сделай сам, делов то.

S>Не хочу сам. Хочу, чтоб стандартно было. Представляете, чё будет, если в каждой библиотечке будет по ICloneable. А если надо будет использовать эти библиотечки вместе ... — будут конфликты имён, надо будет вводить псевдонимы пространств имён в using-ах и прочая лубуда начнётся.

S>Не-е ... Такие вещщи должны быть в стандарте (IMHO, конечно) ...

ИМХО, генерик ICloneable будет вводить в заблуждение. Clone должен возвращать точную копию текущего объекта "фиксированного" типа. А теперь представьте его в виде генерика — складывается впечатление, что один и тот же объект может "скопировать" себя несколькими способоами (в разные результирующие типы).

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

S>Возник вопрос: почему хлопцы из Microsoft во 2-ом .NET не позаботились о generic-версии интерфейса ICloneable. Меня, например, это иногда напрягает ...
Для реализации Clone нужно создавать новый объект. А с этим в генериках не очень хорошо. Поэтому реализация подобного интерфейса достаточно проблематично.

Hello, "Sentry"
> Возник вопрос: почему хлопцы из Microsoft во 2-ом .NET не позаботились о
> generic-версии интерфейса ICloneable. Меня, например, это иногда напрягает
> ...

Потому, что IClonable это не самый удачный дизайн.
В целом про использование IClonable можно почитать тут:
http://blogs.msdn.com/brada/archive/2003/04/09/49935.aspx

P>ИМХО, генерик ICloneable будет вводить в заблуждение. Clone должен возвращать точную копию текущего объекта "фиксированного" типа. А теперь представьте его в виде генерика — складывается впечатление, что один и тот же объект может "скопировать" себя несколькими способоами (в разные результирующие типы).

Есть проблемка помощнее, чем просто заблуждение. По мне, так я ничего заблуждающего не вижу: ясно, что Clone() создаёт копию объекта, и его тип по-любому должен быть такой же, как и у текущего.

Так вот, в чём проблема: если реализовывать этот интерфейс в структурах, то при возврате значения из метода будет происходить его boxing. Вот от этого, IMHO, реально тоскливо ...

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

S>Не хочу сам. Хочу, чтоб стандартно было.

А смысл? Дженерик версия ICloneable с конкретным параметром все равно новый тип, базовый дженерик тебе ничем не поможет в плане универсальности.

TK>Потому, что IClonable это не самый удачный дизайн.
TK>В целом про использование IClonable можно почитать тут:
TK>http://blogs.msdn.com/brada/archive/2003/04/09/49935.aspx

Я слегка не согласен. Там рекомендуют написать свой Clone или Copy и задокументировать, какую копию он делает: shallow или deep, без реализации ICloneable. Но ICloneable — это стандарт. И какая разница, что есть метод Clone с реализацией интерфейса или без неё. По мне так лучше с реализацией, ибо где-то я читал, что лучше даже пожертвовать логически верным дизайном, чем не соответствовать стандартным соглашениям.
Чего им трудно было что ли его туда пихнуть? Кому он мешал бы? А мне бы спокойней стало ...

AVK>А смысл? Дженерик версия ICloneable с конкретным параметром все равно новый тип, базовый дженерик тебе ничем не поможет в плане универсальности.

А какой тогда смысл в IComparable<T> и вообще в generic-интерфейсах? ...

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

S>Я слегка не согласен. Там рекомендуют написать свой Clone или Copy и задокументировать, какую копию он делает: shallow или deep, без реализации ICloneable. Но ICloneable — это стандарт. И какая разница, что есть метод Clone с реализацией интерфейса или без неё. По мне так лучше с реализацией, ибо где-то я читал, что лучше даже пожертвовать логически верным дизайном, чем не соответствовать стандартным соглашениям.
S>Чего им трудно было что ли его туда пихнуть? Кому он мешал бы? А мне бы спокойней стало ...

Они не дураки, и врядли они об этом просто напросто забыли... Просто они, видимо, взвесили все за и против и поняли что это плохой дизайн.

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

S>А какой тогда смысл в IComparable<T>

Смысл простой — IComparable<T> используется в самом фреймворке в качестве типа параметра

S>и вообще в generic-интерфейсах?

Для разных целей.

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

TK>Hello, "Sentry"
>> Возник вопрос: почему хлопцы из Microsoft во 2-ом .NET не позаботились о
>> generic-версии интерфейса ICloneable. Меня, например, это иногда напрягает
>> ...

TK>Потому, что IClonable это не самый удачный дизайн.
TK>В целом про использование IClonable можно почитать тут:
TK>http://blogs.msdn.com/brada/archive/2003/04/09/49935.aspx

чтож в нем неудачного? неудачный design — это shallow copy. И поддержка этого неудачного дизайна — на совести тех, кто его распространяет. Clone должен всегда
делать deep copy. Для shallow пусть придумают что-нибудь другое.