Есть в стандартной библиотеке модуль NList в пространстве Nemerle.Collections в нем есть много полезных методов над списками типа Product, Member, Partition, Range, Repeat, Singletons, SizeSubsets, SubsetPartition и др. Но каждая из функций не является методом расширения и чтобы их вызывать требуется выбирать прямо из модуля NList.Product(lst1, ..), для чего это сделано, почему эти полезные функции не являются методами расширения чтобы применять их на списках сразу типа lst.Product(...)?

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

CU>Есть в стандартной библиотеке модуль NList в пространстве Nemerle.Collections в нем есть много полезных методов над списками типа Product, Member, Partition, Range, Repeat, Singletons, SizeSubsets, SubsetPartition и др. Но каждая из функций не является методом расширения и чтобы их вызывать требуется выбирать прямо из модуля NList.Product(lst1, ..), для чего это сделано, почему эти полезные функции не являются методами расширения чтобы применять их на списках сразу типа lst.Product(...)?

Если посмотреть на реализацию, то окажется, что большинство методов реализованы через вызовы этих функций.

А вообще, так истроически сложилось. Раньше методов вообще мало было. А первые версии Nemerle были не отличимы от ML. ООП появился позже, а модуль на заре.

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

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

CU>>Есть в стандартной библиотеке модуль NList в пространстве Nemerle.Collections в нем есть много полезных методов над списками типа Product, Member, Partition, Range, Repeat, Singletons, SizeSubsets, SubsetPartition и др. Но каждая из функций не является методом расширения и чтобы их вызывать требуется выбирать прямо из модуля NList.Product(lst1, ..), для чего это сделано, почему эти полезные функции не являются методами расширения чтобы применять их на списках сразу типа lst.Product(...)?

VD>Если посмотреть на реализацию, то окажется, что большинство методов реализованы через вызовы этих функций.

VD>А вообще, так истроически сложилось. Раньше методов вообще мало было. А первые версии Nemerle были не отличимы от ML. ООП появился позже, а модуль на заре.

Да много что реализовано с помощью этого модуля, но вот многие полезные функции остались в стороне и я совсем недавно удивился, когда нашел нужный мне метод Product получающий перестановки, через стандартный intellisense этот метод невидим, только копаясь в исходниках или в рефлекторе можно увидеть что в этом модуле есть. Я предлагаю сделать все эти методы методами расширения, тогда вся функциональность будет видна в списке функций для обычного списка.

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

CU>Да много что реализовано с помощью этого модуля, но вот многие полезные функции остались в стороне и я совсем недавно удивился, когда нашел нужный мне метод Product получающий перестановки, через стандартный intellisense этот метод невидим, только копаясь в исходниках или в рефлекторе можно увидеть что в этом модуле есть. Я предлагаю сделать все эти методы методами расширения, тогда вся функциональность будет видна в списке функций для обычного списка.

Зачем расширениями? Делай обычными методами, если в этом есть смысл. Некоторые функции не особо хорошо выглядят как методы. А расширения они довольно сильно замедляют компиляцию. Так что без особых оснований лучше их не делать. Учитывая, что класс доступен для изменения, не стоит делать методы-расширения.

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

VD>Зачем расширениями? Делай обычными методами, если в этом есть смысл. Некоторые функции не особо хорошо выглядят как методы. А расширения они довольно сильно замедляют компиляцию. Так что без особых оснований лучше их не делать. Учитывая, что класс доступен для изменения, не стоит делать методы-расширения.

Методами самого списка? Это как то не в духе .net обычно все функции над коллекциями хранятся в отдельном модуле чтобы не загрязнять сам класс. Может быть многие из методов не понадобятся обычному пользователю, и заполнят уже и так огромный список функций в списке, а кому надо раскроет пространство Nemerle.Collections и получит нужные ему функции. Я не думаю что это сильное замедление, оно оправдано с точки зрения дизайна.

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

CU>Методами самого списка? Это как то не в духе .net обычно все функции над коллекциями хранятся в отдельном модуле чтобы не загрязнять сам класс.

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

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

VD>Ты где этой травы про дух нета набрался? Советую с осторожностью читать майкросовтовские агитки, и больше думать своей головой. А то информация в них периодически меняется на диаметрально противоположенную.

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

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

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

VD>>Ты где этой травы про дух нета набрался? Советую с осторожностью читать майкросовтовские агитки, и больше думать своей головой. А то информация в них периодически меняется на диаметрально противоположенную.

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

Если был бы интерфейс , то тогда конечно лучше методы расширения, чтобы не пришлось каждому копировать код.
Так поступили в случае IEnumerable.
А тут простой класс, нет интерфейсов. Толку от расширения мало тем более когда код доступен

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

CU>>Методами самого списка? Это как то не в духе .net обычно все функции над коллекциями хранятся в отдельном модуле чтобы не загрязнять сам класс.
VD>Ты где этой травы про дух нета набрался? Советую с осторожностью читать майкросовтовские агитки, и больше думать своей головой. А то информация в них периодически меняется на диаметрально противоположенную.

Мне тоже этот дух по-душе. Но я так понял, что ты их не любишь потому что Немерле их медленно компилирует?

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

_NN>А тут простой класс, нет интерфейсов. Толку от расширения мало тем более когда код доступен

Толк очень простой. Можно было бы реализовать эти методы для ICollection.

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

CU>>Методами самого списка? Это как то не в духе .net обычно все функции над коллекциями хранятся в отдельном модуле чтобы не загрязнять сам класс.

VD>Ты где этой травы про дух нета набрался? Советую с осторожностью читать майкросовтовские агитки, и больше думать своей головой. А то информация в них периодически меняется на диаметрально противоположенную.

А для своей коллекции надо полагать придется реализовать все те же методы ? Сильный подход к дизайну, ничего не скажешь.

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

I>А для своей коллекции надо полагать придется реализовать все те же методы ? Сильный подход к дизайну, ничего не скажешь.

Реализация для list[T] специфична и уже есть в виде статических методов. Вопрос только делать ли их методами-расшинениями или нормальными методами.

За то чтобы делать их нормальными методами есть два аргумента:
1. Их использование не будет зависеть от того открыто магическое пространство имен или нет.
2. Код с их использованием будет быстрее компилироваться компилятором немерла.

Противопоказаний — 0, если не считать майкросовтовской пропаганды.

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

IT>Мне тоже этот дух по-душе. Но я так понял, что ты их не любишь потому что Немерле их медленно компилирует?

У нас с тобой разные подходы к выбору дизайна. Ты используешь понятия "любишь" / "не любишь", а я в зависимости от наличия аргументов за и против. Если я пишу универсальную функцию которая будет работать а IEnumerable или IList, то сделаю ее методом расширения. Если конкретную реализацию для класса у которого доступны исходники, то предпочту сделать нормальный метод, так:
1. Он не потребует открытия магических пространств имен.
2. Случайно не возникнет неоднозначность.
3. (потенциально) Можно воспользоваться разными недоступными из вне членами.
4. Будет способствовать скорости компиляции, которая и так не блещет. Особенно это актуально для функций из стандартной библиотеки.

А вот какие есть аргументы за метод-расширение, кроме откровенно философских на тему соблюдения умных принципов, я представить себе не могу. Может ты поможешь.

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

VD>А вот какие есть аргументы за метод-расширение, кроме откровенно философских на тему соблюдения умных принципов, я представить себе не могу. Может ты поможешь.

Похоже, новый тренд — монолитный дизайн возводится в культ.

"Четкое разделение на базе интерфейсов позволит котролировать лакальность реализаций." @VladD2

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

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

VD>>А вот какие есть аргументы за метод-расширение, кроме откровенно философских на тему соблюдения умных принципов, я представить себе не могу. Может ты поможешь.

I>Похоже, новый тренд — монолитный дизайн возводится в культ.

I>"Четкое разделение на базе интерфейсов позволит котролировать лакальность реализаций." @VladD2

Да ладно вопрос не ставился так, не надо делать из мухи слона, вопрос лишь о нескольких функциях взаимосвязанных с листом, никто не собирается обобщать эти функции пока в отдельные коллекции, поэтому они и остаются вместе со списком в отдельном классе, это лучше чем вызывать их из модуля. Если кто то ищет нужные ему функции по коллекциям, которых нет в библиотеке то в любом случае их надо будет реализовывать самому.

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

IT>Толк очень простой. Можно было бы реализовать эти методы для ICollection.

Нельзя. Ты, похоже, не понял в какой разговор влез. Речь идет о том, что у нас есть готовые, специализированные, реализации в модуле. И Кодюнит хочет сделать на их основе методы классов.

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

I>А для своей коллекции надо полагать придется реализовать все те же методы ? Сильный подход к дизайну, ничего не скажешь.

Функции уже есть. Ничего реализовывать не надо. К тому же реализации специализированные и от того более эффективные, для данного типа структур данных.

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

I>Похоже, новый тренд — монолитный дизайн возводится в культ.

Похоже другое — кому-то снова захотелось по флеймить, а темы достойной нету.

Никто ничего в культ не возводит. В библиотеке есть куча методов обобщенных для разных типов коллекций. Они ралаизованы в виде методов расширений. Тут же идет речь о превращении специализированных функций (объявленных в модуле NList) в соответствующие методы типа list[T].