Сделать, чтобы компилятор выдавал предупреждение, когда можно заменить класс, метод и т. д. на более оптимальные

Допустим, пользователь ввел List<int>, но такой тип неоптимален, когда есть NList<int>. Аналогично с Convert и NConvert, когда целевой тип - int. При этом на List<string> предупреждение не должно выдаваться, так как тип NList<string> невозможен. Как это можно сделать?

0

Сообщение от Wolfdp Банальное использование List<T> вместо T[] уже может давать те или иные аффекты.

под листом все тот же массив
про какие артефакты может идти речь?

0

Сообщение от Dr9vik про какие артефакты может идти речь?

affect -- оказывать воздействие

Из того с чем сталкивался: всюду на webapi проекте по возможности использовали List<T> и в ус не дули. В определенный момент мне приспичило вернуть json содержащий T[] (причины сейчас тоже не вспомню). Сериализация падала на этом свойстве. Причины -- хз. Сталкивался и в обратную сторону: когда List<T> вызывал ошибки сериализации в json. Оба случая "фиксилось" тем что использовал просто другую коллекцию, и не копал глубже (никто особо на это время бы и не выделил).

Ещё важный момент: речь шла не про прямое взаимодействие с каким-нибудь newtonsoft, а формирование модели для request/response и скармливание его условному sender. Т.е. для разбора пришлось бы основательно так копнуть что где как и почему. Как писал выше -- не всегда есть на это ресурсы.

Да, можно сказать что за несколько лет лишь пару раз стрельнуло это. Но речь об List<T> и T[], которые вроде как должны работать всюду. ТС же предлагает прям целенаправленно всюду использовать кастомное решение. Опуская все эти разборы по поводу насколько его оптимизации оправданы, я стараюсь донести мысль что "стандартное решение = более надежное решение".

Ещё можно докинуть в копилку, что всякие сторонние либы, которые приходится использовать, не всегда на вход принимают обобщение в виде IEnumerble<T>, а вполне могут ожидать List<T>. В итоге будет следующая картина:
- я не могу использовать NList<T>, потому как либа ожидает List<T>
- код изобилует уведомлениями "используй NList<T>". Если это ещё и целый warning, то вообще в топку это решение.

0

Сообщение от Wolfdp В итоге будет следующая картина: - я не могу использовать NList<T>, потому как либа ожидает List<T> - код изобилует уведомлениями "используй NList<T>". Если это ещё и целый warning, то вообще в топку это решение.

Кто мешает использовать new G.List<T>(nList) (предварительно объявив в начале файла using G = System.Collections.Generic;)? G.List<T> не относится к моей библиотеке, поэтому мой анализатор его никак не сможет контролировать. Кроме того, думаю, можно проверять, какой тип ожидается методом. Речь шла о ситуации, когда можно с равной степенью корректности использовать и List<T>, и NList<T>.

0

Сообщение от Wolfdp Из того с чем сталкивался: всюду на webapi проекте по возможности использовали List<T> и в ус не дули. В определенный момент мне приспичило вернуть json содержащий T[] (причины сейчас тоже не вспомню). Сериализация падала на этом свойстве. Причины -- хз. Сталкивался и в обратную сторону: когда List<T> вызывал ошибки сериализации в json. Оба случая "фиксилось" тем что использовал просто другую коллекцию, и не копал глубже (никто особо на это время бы и не выделил).

это кривой сериализатор и скорее вы использовали стандартный от масдая который кривой был до 3 кора
темболее какая связь Linq и IQueryable если у вас сериализатор не работал

0

Etyuhibosecyu,

Речь шла о ситуации, когда можно с равной степенью корректности использовать и List<T>, и NList<T>.

Проблема как раз в том что вы хотите автоматически определять когда его можно использовать. Эта задача, на мой взгляд, сопоставима с написанием ии, который сможет существенно рефакторить код .

Dr9vik, перечитайте ещё раз моё первое сообщение. Я задавал два отдельных вопроса: касаемо формирования запросов из linq и касаемо сериализации. И далее их не смешивал, просто вы не вниматель читали мои ответы.

Еще один момент -- вы пытаетесь мне доказать что большинстве случаев дефолтный лист и массив работают. Я это прекрасно понимаю. Эти вопросы и примеры были целью натолкнуть на мысль ТСа, что его реализация не будет работать по причине, что код завязан на использование обычного листа и легкой замены не добиться. А так как проекты нередко имеют цикл сопровождения и развития, то добавляется шанс что сначала вроде заменить и можно, а потом оказывается что лучше бы там был обычный лист.

0

Сообщение от Etyuhibosecyu Кто мешает использовать new G.List<T>(nList)

Мешает умножение на нуль всей идеи "оптимизации" от твоей библиотеки.

0