Re[4]: Странности с массивами
От: hardcase Пират http://nemerle.org
Дата: 14.02.11 19:00
Оценка:
Здравствуйте, Аноним, Вы писали:

А>1. нарушение принципов ООР — где именно? просто блокируются потенциально опасные методы.


Что в них опасного?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[8]: Странности с массивами
От: Аноним  
Дата: 14.02.11 19:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:


А>>Список сделали в немерли вы?


VD>Да. Точнее авторы языка — поляки.


А>>и получение хеша идет той же функцией? но работает не как принято в немерли.


VD>Это функции дотнетные. Объявлены они как виртуальные и должны переопределяться для типа его разработчиком. Вот для массивов в МС решили это не далеть.


VD>Обходной путь есть. Можно использовать вешний объект-компоратор.


А>>В действительности в общем не так важно как работает, главное что бы всегда или так или эдак... а не то так то эдок.


VD>Все зависит от объекта. На самом деле все работает правильно. Если поместить ссылку на массив в переменную и проверять ее, то результат будет правильным. Тут вопрос в другом. Для массивов просто не реализованы методы эквивалентности по содержимому.


как и для многих ссылочных типов, например если я создам класс, то этот метод не будет работать значениям.
массив является в немерли ссылочным типом (идеология .net), в то время как список немерли является типом значения (идеология .net).
Элементами массива могут быть не только числа, но и строки и произвольные объект и т д.

Какой результат даст хеш списка массивов? тут слишком много подводных камней....
Re[9]: Странности с массивами
От: hardcase Пират http://nemerle.org
Дата: 14.02.11 19:42
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Какой результат даст хеш списка массивов? тут слишком много подводных камней....


Наверно нужно понимать, что список Немерла — это иммутабельная структура данных, пришедшая из антивселенной некромонгеров другой вселенной.
Конкретно Вы пробовали использовать списки и кортежи прежде чем начинать философствовать на заданную тему?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[9]: Странности с массивами
От: hardcase Пират http://nemerle.org
Дата: 14.02.11 19:46
Оценка: :)
Здравствуйте, Аноним, Вы писали:

А>Какой результат даст хеш списка массивов? тут слишком много подводных камней....


Отлично, у нас есть кортежи (и часть из них — ссылочные типы), и у них также переопределены Equals и GetHashcode.
Справедливо ли это? Более того, в .NET 4.0 введено семейство типов System.Tuple, которое вообще все — ссылочные типы.

Какой результат даст хэш кортежа массивов? тут слишком много подводных камней....
/* иЗвиНите зА неРовнЫй поЧерК */
Re[9]: Странности с массивами
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.11 20:11
Оценка:
Здравствуйте, Аноним, Вы писали:

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


Ну, почему? Реализуй методы и получишь нужное для класса поведение. Все зависит от класса.

А>массив является в немерли ссылочным типом (идеология .net), в то время как список немерли является типом значения (идеология .net).


Нет. Это два ссылочных типа. А понятие эквивалентность вообще не имеет прямого отношения к типу объекта. В конце концов любой вэлью-тип можно запихать в хип и работать с ним по ссылке (через, интерфейс в C# или даже напрямую в C++).

А>Элементами массива могут быть не только числа, но и строки и произвольные объект и т д.


Тоже не имеет никакого отношения к делу.

А>Какой результат даст хеш списка массивов? тут слишком много подводных камней....


Сумарный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Странности с массивами
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.11 21:36
Оценка:
Здравствуйте, Ka3a4oK, Вы писали:

KK>А как вообще узнать как компарация производится для типа?


Как и все остальное из документации или Рефлектора.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Странности с массивами
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.11 21:38
Оценка:
Здравствуйте, Ziaw, Вы писали:

А>>Возможно надо добавить проверку на перекрытие метода. В случае если метод не перекрыт то выдавать предупреждение при компиляции. Это мягкое решение.


Z>Это нарушение принципов OOP — раз. Как минимум мне такие предупреждения будут мешать — два.


Да что там принципы ООП? Это вообще чушь, так как у типа может быть наследник и в переменной может оказаться он приведенный к базовому классу.

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