Здравствуйте, Аноним, Вы писали:
А>Как минимум этот код должен выдавать ошибку во время компиляции т.к. ("для массивов не переопределены Equals и GetHashcode")
С чего бы это? Методы же у массива реализованы. Только они сравнивают не данные хранимые в массивах, а экзепляры массива (используют реализацию указанных методов из класса object).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Странности с массивами
От:
Аноним
Дата:
14.02.11 16:48
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
А>>Как минимум этот код должен выдавать ошибку во время компиляции т.к. ("для массивов не переопределены Equals и GetHashcode")
VD>С чего бы это? Методы же у массива реализованы. Только они сравнивают не данные хранимые в массивах, а экзепляры массива (используют реализацию указанных методов из класса object).
с того что поведение не предсказуемо и не однозначно. Это тоже самое что если бы сравнение целых чисел было бы по значению а строк по ссылке...
Здравствуйте, Аноним, Вы писали:
А>как минимум сильный глюк архитектуры языка
При чем тут язык? Это библиотеки, попробуй сравнить массивы в C#.
Re[6]: Странности с массивами
От:
Аноним
Дата:
14.02.11 17:00
Оценка:
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Аноним, Вы писали:
А>>как минимум сильный глюк архитектуры языка
Z>При чем тут язык? Это библиотеки, попробуй сравнить массивы в C#.
Это я понимаю, но теперь попробуй сравнить список в C#?
Здравствуйте, <Аноним>, Вы писали:
А>как минимум сильный глюк архитектуры языка
Это глюк архитектуры всего .НЕТ.
К сожелению выкинуть .НЕТ пока не представляется возможным ибо сил писать свою ВМ пока нет, а другие ВМ еще хуже.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ka3a4oK, Вы писали:
KK>И как мне решить эту проблему? Обернуть массив в структуру?
Можно так или можно реализовать System.Collections.Generic.IEqualityComparer[T] и передать его в конструктор Hashtable.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Странности с массивами
От:
Аноним
Дата:
14.02.11 17:20
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, <Аноним>, Вы писали:
А>>как минимум сильный глюк архитектуры языка WH>Это глюк архитектуры всего .НЕТ. WH>К сожелению выкинуть .НЕТ пока не представляется возможным ибо сил писать свою ВМ пока нет, а другие ВМ еще хуже.
Можно просто заблокировать подобные методы или переименовать.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Ka3a4oK, Вы писали:
KK>>И как мне решить эту проблему? Обернуть массив в структуру? WH>Можно так или можно реализовать System.Collections.Generic.IEqualityComparer[T] и передать его в конструктор Hashtable.
А как вообще узнать как компарация производится для типа?
Здравствуйте, Аноним, Вы писали:
А>с того что поведение не предсказуемо и не однозначно. Это тоже самое что если бы сравнение целых чисел было бы по значению а строк по ссылке...
Здорово! Но мы то тут причем? Это поведение определяется реализацией находящейся в .net framework. Так что заловаться надо в MS.
А>как минимум сильный глюк архитектуры языка
Язык то тут причем?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Странности с массивами
От:
Аноним
Дата:
14.02.11 17:54
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
А>>с того что поведение не предсказуемо и не однозначно. Это тоже самое что если бы сравнение целых чисел было бы по значению а строк по ссылке...
VD>Здорово! Но мы то тут причем? Это поведение определяется реализацией находящейся в .net framework. Так что заловаться надо в MS.
А>>как минимум сильный глюк архитектуры языка
VD>Язык то тут причем?
Список сделали в немерли вы? и получение хеша идет той же функцией? но работает не как принято в немерли.
В действительности в общем не так важно как работает, главное что бы всегда или так или эдак... а не то так то эдок.
Re: Странности с массивами
От:
Аноним
Дата:
14.02.11 18:13
Оценка:
Поясняю, что я считаю ошибкой проектирования.
Возможно надо добавить проверку на перекрытие метода. В случае если метод не перекрыт то выдавать предупреждение при компиляции. Это мягкое решение.
Здравствуйте, Аноним, Вы писали:
А>Это я понимаю, но теперь попробуй сравнить список в C#?
Немерловый? Будет вести себя точно так же как и в nemerle. Сравнение по значению это одна из его фич. Если бы он вел себя точно так же как List[T] из фреймворка не было бы никакой надобности в своей реазлизации.
Здравствуйте, Аноним, Вы писали:
А>Поясняю, что я считаю ошибкой проектирования.
А>Возможно надо добавить проверку на перекрытие метода. В случае если метод не перекрыт то выдавать предупреждение при компиляции. Это мягкое решение.
Это нарушение принципов OOP — раз. Как минимум мне такие предупреждения будут мешать — два.
Re[8]: Странности с массивами
От:
Аноним
Дата:
14.02.11 18:19
Оценка:
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Аноним, Вы писали:
А>>Это я понимаю, но теперь попробуй сравнить список в C#?
Z>Немерловый? Будет вести себя точно так же как и в nemerle. Сравнение по значению это одна из его фич. Если бы он вел себя точно так же как List[T] из фреймворка не было бы никакой надобности в своей реазлизации.
Ура. Кто то понял. Немерли пользуется библиотекой нет, но свои типы работают не аля нет.
То есть неоднозначность, дополнительный нюанс который надо изучать человеку. Дополнительный кладезь ошибок.
Re[3]: Странности с массивами
От:
Аноним
Дата:
14.02.11 18:38
Оценка:
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Аноним, Вы писали:
А>>Поясняю, что я считаю ошибкой проектирования.
А>>Возможно надо добавить проверку на перекрытие метода. В случае если метод не перекрыт то выдавать предупреждение при компиляции. Это мягкое решение.
Z>Это нарушение принципов OOP — раз. Как минимум мне такие предупреждения будут мешать — два.
2. Ты часто пользуешься хешем ссылок? (предупреждение только в этом случае)
1. нарушение принципов ООР — где именно? просто блокируются потенциально опасные методы.
Здравствуйте, Аноним, Вы писали:
А>Список сделали в немерли вы?
Да. Точнее авторы языка — поляки.
А>и получение хеша идет той же функцией? но работает не как принято в немерли.
Это функции дотнетные. Объявлены они как виртуальные и должны переопределяться для типа его разработчиком. Вот для массивов в МС решили это не далеть.
Обходной путь есть. Можно использовать вешний объект-компоратор.
А>В действительности в общем не так важно как работает, главное что бы всегда или так или эдак... а не то так то эдок.
Все зависит от объекта. На самом деле все работает правильно. Если поместить ссылку на массив в переменную и проверять ее, то результат будет правильным. Тут вопрос в другом. Для массивов просто не реализованы методы эквивалентности по содержимому.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>1. нарушение принципов ООР — где именно? просто блокируются потенциально опасные методы.
Что в них опасного?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[8]: Странности с массивами
От:
Аноним
Дата:
14.02.11 19:07
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
А>>Список сделали в немерли вы?
VD>Да. Точнее авторы языка — поляки.
А>>и получение хеша идет той же функцией? но работает не как принято в немерли.
VD>Это функции дотнетные. Объявлены они как виртуальные и должны переопределяться для типа его разработчиком. Вот для массивов в МС решили это не далеть.
VD>Обходной путь есть. Можно использовать вешний объект-компоратор.
А>>В действительности в общем не так важно как работает, главное что бы всегда или так или эдак... а не то так то эдок.
VD>Все зависит от объекта. На самом деле все работает правильно. Если поместить ссылку на массив в переменную и проверять ее, то результат будет правильным. Тут вопрос в другом. Для массивов просто не реализованы методы эквивалентности по содержимому.
как и для многих ссылочных типов, например если я создам класс, то этот метод не будет работать значениям.
массив является в немерли ссылочным типом (идеология .net), в то время как список немерли является типом значения (идеология .net).
Элементами массива могут быть не только числа, но и строки и произвольные объект и т д.
Какой результат даст хеш списка массивов? тут слишком много подводных камней....
Здравствуйте, Аноним, Вы писали:
А>Какой результат даст хеш списка массивов? тут слишком много подводных камней....
Наверно нужно понимать, что список Немерла — это иммутабельная структура данных, пришедшая из антивселенной некромонгеров другой вселенной.
Конкретно Вы пробовали использовать списки и кортежи прежде чем начинать философствовать на заданную тему?
Здравствуйте, Аноним, Вы писали:
А>Какой результат даст хеш списка массивов? тут слишком много подводных камней....
Отлично, у нас есть кортежи (и часть из них — ссылочные типы), и у них также переопределены Equals и GetHashcode.
Справедливо ли это? Более того, в .NET 4.0 введено семейство типов System.Tuple, которое вообще все — ссылочные типы.
Какой результат даст хэш кортежа массивов? тут слишком много подводных камней....
Здравствуйте, Аноним, Вы писали:
А>как и для многих ссылочных типов, например если я создам класс, то этот метод не будет работать значениям.
Ну, почему? Реализуй методы и получишь нужное для класса поведение. Все зависит от класса.
А>массив является в немерли ссылочным типом (идеология .net), в то время как список немерли является типом значения (идеология .net).
Нет. Это два ссылочных типа. А понятие эквивалентность вообще не имеет прямого отношения к типу объекта. В конце концов любой вэлью-тип можно запихать в хип и работать с ним по ссылке (через, интерфейс в C# или даже напрямую в C++).
А>Элементами массива могут быть не только числа, но и строки и произвольные объект и т д.
Тоже не имеет никакого отношения к делу.
А>Какой результат даст хеш списка массивов? тут слишком много подводных камней....
Сумарный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
А>>Возможно надо добавить проверку на перекрытие метода. В случае если метод не перекрыт то выдавать предупреждение при компиляции. Это мягкое решение.
Z>Это нарушение принципов OOP — раз. Как минимум мне такие предупреждения будут мешать — два.
Да что там принципы ООП? Это вообще чушь, так как у типа может быть наследник и в переменной может оказаться он приведенный к базовому классу.
Потом для многих типов для которых не определены методы эквивалентности сравнение ссылок обеспечивает нужный результат.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.