Цитата:
Сообщение от
DSPIC
Точки расширения они делают регулярно. Деятели...
Тут такая логическая цепочка: регулярные обновления => совместимость => органичение объема API.
При регулярных обновлениях надо быть обратно совместимым потому, что иначе расширения будут отваливаться. Теперь рассмотрим, что будет, если просто везде стаить public.
Вот, допустим кто-то написал
X++:
public void foo(string bar)
{
...-
}Теперь нам надо сделать дополнительный параметр.
X++:
public void foo(string bar, int baz)
- так делать нельзя. Расширение может вызывать этот метод и оно перестанет компилироваться и работать.
X++:
public void foo(string bar, int baz = 0)
Тут расширение из предыдущей фразы будет работать, но
1. Может быть расширение которое обернуло этот код и не прокидывает новый параметр
2. Если параметр baz
логически обязательный, то все скомпилируется и сработает но неправильно. Фактически, это означает, что логически обязательный параметр вообще никак нельзя добавить без потери обратной совместимости.
X++:
public void foo(string bar)
{
this.fooWithBaz(bar, 0);
}
public void fooWithBaz(string bar, int baz)Так можно, но нельзя перестать вызывать foо в том месте, где он изначально вызывался, потому, что расширение может подписаться на вызовы foo или обернуть и тогда оно тихо перестанет работать.
Еще можно сделать disposable context - фактически передавать дополнительные данные через статический метод, но будут пролемы с рекурсией.
Можно изначально передавать параметры завернутые в parameter object.
A самое главное, от логически обязательного параметра не спасает ничего.
При этом всем этот метод в реальности, скорее всего, никакими расширениями не используется (потому, что большинство методов не используется) и делать его piblic значит просто закрыть себе возможность развития этого участка кода без какой бы то ни было выгоды для кого-то.