недостатки системы типов .NET
От: AndreiF  
Дата: 09.11.06 06:46
Оценка: 9 (2) +2 :)
Вот здесь я уже писал о некоторых недостатках в реализации .NET. Теперь я решил расширить список и написать о других аспектах платформы, а точнее — о системе типов.
Здесь я составил список проблем в системе типов CLI, которые осложняют работу. Впрочем, это только мое мнение — на абсолютную правоту я не претендую
Если у кого-то есть желание расширить список — welcome.

Нет ни множественного наследования реализаций, ни его заменителей.

Нет ковариантности для переопределения виртуальных методов.

Нет возможности использовать константные ссылки на объекты, что вынуждает программиста создавать read-only версии объектов — дополнительная ручная работа.

Нельзя перегружать методы по типу возвращаемого значения.

Нет кортежей.

Критически важные системные исключения (OutOfMemoryException, ThreadAbortException, ExecutionEngineException и т.п.) наследуются от того же базового класса, что и частно используемые ArgumentException, NotSupportedException и так далее. Это провоцирует плохих программистов писать конструкции наподобие
catch (Exception) { return false; }

Наличие типов, которые явно обозначаются как передаваемые через стек, и все связанные с этим усложнения системы типов (боксинг) и ограничения (нельзя наследовать от структур). На самом деле, решать, каким образом передавать объект в каждом конкретном случае – это задача оптимизатора.

Просчеты в реализации энумов. Например, любое числовое значение можно привести к любому перечислимому типу, даже если в том нет соответствующего значения, и это не вызовет никакой ошибки во время выполнения. Фактически, целевой переменной перечислимого типа будет присвоено некоторое «неопределенное» значение. No comments.

Коллекции
Одновременное применение в системе типов .NET массивов, нетипизированных коллекций, специализированных коллекций и генерик-коллекций, которые все «немного похожи» и «немного разные». Соответственно, методы из FCL возвращают разные типы — это создает лишнюю путаницу и сложности при программировании.
Например, String.Split возвращает string[], а не IList<string> или IEnumerable<string>, как можно было ожидать.
Для массивов возможна ко/контра-вариантность элементов, для остальных коллекций – нет. Массивы можно инициализировать списком значений в коде, для коллекций это невозможно.
Большинство коллекций поддерживают возможность добавлять элементы без пересоздания объекта, для массивов эта возможность недоступна. Для большинства коллекций доступен метод AsReadOnly() или аналог, для массивов такой возможности нет.
Генерики
Много лишней писанины, если нужно создать систему из нескольких связанных типов, имеющих общие параметры.

Нельзя использовать Enum в качестве констрэйнта на тип.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: недостатки системы типов .NET
От: WolfHound  
Дата: 09.11.06 11:56
Оценка: +2 -2
Здравствуйте, AndreiF, Вы писали:

AF>Нет ни множественного наследования реализаций, ни его заменителей.

Решается метапрограммированием. И вобще наследование реализации нужно по возможности избегать. Ибо оно дает слишьком сильные связи что мешает развивать систему.

AF>Нет ковариантности для переопределения виртуальных методов.

Честно говоря не больно то оно и нужно. Особенно если не злоупотреблять наследованием.

Вот эти два пункта объеденю:
AF>Нет возможности использовать константные ссылки на объекты, что вынуждает программиста создавать read-only версии объектов — дополнительная ручная работа.
AF>Наличие типов, которые явно обозначаются как передаваемые через стек, и все связанные с этим усложнения системы типов (боксинг) и ограничения (нельзя наследовать от структур). На самом деле, решать, каким образом передавать объект в каждом конкретном случае – это задача оптимизатора.
Дело в том что есть объекты которые должны быть изменяемыми и есть объекты которые должны быть не изменяемыми. Есть объекты которые должны передоваться по ссылке и есть объекты которые должны передоватся по значению.
Это не вопрос оптимизации это вопрос архитектуры. Нельзя мешать теплое с мягким. Ничего хорошего из этого не выходит.

AF>Нет кортежей.

Легко эмулируются при помощи генериков.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.11.06 22:55
Оценка: +1 :))
Здравствуйте, kan, Вы писали:

kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта операция не согласуется с идеологией безопасных языков.


Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.06 15:32
Оценка: :)))
Здравствуйте, AndreiF, Вы писали:

AF>В С++ вообще нет никаких гарантий


Скажу больше. Гарантии вообще редко можно встретиь. И даже если встретишь, то по жизни оказвается, что и это обман.

Вот давича купил я себе память для нового компьютера. На ней написано "пожизненная гарантия". Ну, и что вы думаете? В гарантийном талоне написано — один год.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: недостатки системы типов .NET
От: AndreiF  
Дата: 12.11.06 16:58
Оценка: 10 (1) :)
Здравствуйте, VladD2, Вы писали:

VD>Вот давича купил я себе память для нового компьютера. На ней написано "пожизненная гарантия". Ну, и что вы думаете? В гарантийном талоне написано — один год.


[offtopic on]
Это старый трюк маркетоидов. "Пожизненная" — производитель обычно имеет в виду срок жизни данной модели на рынке, а совсем не то что подумает нормальный покупатель. Так что как только эту модель перестанут производить, тут гарантии и конец. В штатах, если не ошибаюсь, даже приняли специальный закон, что "пожизненная" гарантия не может длиться меньше чем год (или что-то около того)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: недостатки системы типов .NET
От: AndreiF  
Дата: 09.11.06 12:13
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

WH>Решается метапрограммированием. И вобще наследование реализации нужно по возможности избегать. Ибо оно дает слишьком сильные связи что мешает развивать систему.


Метапрограммированием решается вообще всё — это не аргумент.

AF>>Нет ковариантности для переопределения виртуальных методов.

WH>Честно говоря не больно то оно и нужно. Особенно если не злоупотреблять наследованием.

class Test: ICloneable
{
  public Test Clone() // а вот хрен то там!
    {
    ...
    }
}

Так что вместо простого и понятного кода придется воротить два метода и явную реализацию метода интерфейса, менее понятно и более громоздко. И это еще самый тривиальный пример.

WH>Дело в том что есть объекты которые должны быть изменяемыми и есть объекты которые должны быть не изменяемыми.


Чушь.
// made by Vasya
class Document : IDisposable
{
....
}

// made by Petya
static class Printer
{
  public static Print(Document doc)
    {
      ...
        doc.Dispose(); // опа!
    }
}

Ну так что, документ он какой — изменяемый или неизменямый?

AF>>Нет кортежей.

WH>Легко эмулируются при помощи генериков.

а ты пробовал?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: недостатки системы типов .NET
От: _FRED_ Черногория
Дата: 09.11.06 12:27
Оценка: +2
Здравствуйте, AndreiF, Вы писали:

GZ>>Кому как. Нет ни одной типа коллекции которую я бы не юзал. Все пригождается.


AF>Проблема не в том, что есть "лишние" типы коллекций. Проблема в том, что между ними слишком много мелких неприятных различий. Почему например для массивов есть ко/контра-вариантность,


Да ещё и для не любых массивов! :о))

AF>а для других коллекций — нет?


потому что способ хранения данных в массиве известен рантайму, а вот как хранятся данные за ширмой IList\ICollection — личное дело того, кто эти интерфейсы реализует. Опять же, при необходимости, написание своего преобразователя совсем не сложно (во-первых) и в третьем шарпе у экземпляра любого типа, реализующего IEnumerable (который не-дженерик!) можно будет вызвать метод Cast<T>() получив последовательность (IEnumerable<T>) нужного типа. И это лишь один из способов. Для Немерла, небось, тоже кудесники могут много чего придумать — надо только захотеть.
... << RSDN@Home 1.2.0 alpha rev. 664>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Re: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.11.06 22:32
Оценка: +2
Здравствуйте, AndreiF, Вы писали:

AF>Если у кого-то есть желание расширить список — welcome.


Расширение или сужение зависит от точки зрения и имеющегося багажа знаний. Так что лучше для начала пару коментариев.

AF>Нет ни множественного наследования реализаций, ни его заменителей.


Это проблемы не CLI, а кокретных ЯП. Так есть Эфил с МН, Скала с трэтсами и Немерле с макросами на которых она неплохо заменяется.

AF>Нет ковариантности для переопределения виртуальных методов.


Для системы типов дотнета это невозможно, в общем случае. Коваринтныи могут быть только неизменяемые типы.
Ко/конт-вариантность доступна для интерфейсов. Но к сожалению Шарп это не поддерживает. За то поддерживает коваринатность для делегатов и массивов. Причем на мой взгляд для массивов это совершенно лишнее, препятсвует некоторым оптимизациям и приводит к рантайм-ошибкам.

AF>Нет возможности использовать константные ссылки на объекты, что вынуждает программиста создавать read-only версии объектов — дополнительная ручная работа.


Мне кажется, что вопрос изменчивости данных — это отдельный и очень непростой вопрос. И рассматривать его только в аспекте неизменчивости ссылок в корне не верно. Ведь единственно зачем нужно обсуждать этот вопрос — это чтобы понять как получить более надежные и безопасные ЯП. Пример С++ же отлично показывает, что наличие неизменяемости ссылок не делает язык более безопасным.

AF>Нельзя перегружать методы по типу возвращаемого значения.


CLI это позволяет делать. Это не позволяют делать C++ и C#. И на то есть вполне объективные причины. Кстати, оператор приведения типов в Шарпе перегружается именно по типу возвращаемого значения.

AF>Нет кортежей.


Это возможность скорее языковая.

AF>Критически важные системные исключения (OutOfMemoryException, ThreadAbortException, ExecutionEngineException и т.п.) наследуются от того же базового класса, что и частно используемые ArgumentException, NotSupportedException и так далее. Это провоцирует плохих программистов писать конструкции наподобие

AF>catch (Exception) { return false; }

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

AF>Наличие типов, которые явно обозначаются как передаваемые через стек, и все связанные с этим усложнения системы типов (боксинг) и ограничения (нельзя наследовать от структур). На самом деле, решать, каким образом передавать объект в каждом конкретном случае – это задача оптимизатора.


От тут полностью согласен. Вот только жаль, что такого умного оптимизатора пока реально нет. В Яве над этим ведется работа. Поглядим что выйдет.

AF>Просчеты в реализации энумов. Например, любое числовое значение можно привести к любому перечислимому типу, даже если в том нет соответствующего значения, и это не вызовет никакой ошибки во время выполнения. Фактически, целевой переменной перечислимого типа будет присвоено некоторое «неопределенное» значение. No comments.


Опять же не видел от этого проблемы. Хотя с аргументами согласен.

AF>Коллекции

AF>Одновременное применение в системе типов .NET массивов, нетипизированных коллекций, специализированных коллекций и генерик-коллекций, которые все «немного похожи» и «немного разные». Соответственно, методы из FCL возвращают разные типы — это создает лишнюю путаницу и сложности при программировании.

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

AF>Например, String.Split возвращает string[], а не IList<string> или IEnumerable<string>, как можно было ожидать.


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

AF>Для массивов возможна ко/контра-вариантность элементов, для остальных коллекций – нет.


Согласен. Не красиво. Темболее, что для интефрейсов это возможно. Могли бы в Шарпе хотя бы это реализовать.

AF> Массивы можно инициализировать списком значений в коде, для коллекций это невозможно.


Приминительно к CLI это утверждение не верно. Инициализация — это фишка ЯП. Так что это притензия к Шарпу. И в версии 3.0 она похоже будет исправлена.

AF>Большинство коллекций поддерживают возможность добавлять элементы без пересоздания объекта, для массивов эта возможность недоступна. Для большинства коллекций доступен метод AsReadOnly() или аналог, для массивов такой возможности нет.


Это вообще заблуждение:
using System;
using System.Collections.Generic;

class Program
{
    public static readonly int x = 1;

    static void Main()
    {
        int[] ary = new int[] { 1, 2, 3 };
        IList<int> lst = Array.AsReadOnly(ary);
        lst[0] = 123;
    }
}


AF>Генерики

AF>Много лишней писанины, если нужно создать систему из нескольких связанных типов, имеющих общие параметры.

Не понял претензии. Но подозреваю, что она поять же не к дотнету или КЛИ, а к Шарпу.

AF>Нельзя использовать Enum в качестве констрэйнта на тип.


Это тоже проблема C#. Например, в Nemerle таких ограничений нет.

Подытоживая... как минимум неверно названа тема. Перечисленные тобой претензии в основном относятся к C#.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: недостатки системы типов .NET
От: WolfHound  
Дата: 10.11.06 11:01
Оценка: +2
Здравствуйте, kan, Вы писали:

>> Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.

kan>А в каком языке есть const, но нет const_cast?
Ты лучше покажи язык кроме С++ где этот самый const_cast есть...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: недостатки системы типов .NET
От: fmiracle  
Дата: 10.11.06 12:56
Оценка: +1 :)
Здравствуйте, AndreiF, Вы писали:

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

WH>>И должен он будет работать в глобальном масштабе... Ибо если на тойже виртуальной машине сделать межпроцессное общение типа как в сингулярити...

AF>Подозреваю, что рано или поздно всё к этому и придет.


Подозреваю, что рано или поздно люди смогут жить на Луне. Но это еще не значит, что надо сегодня в качестве машины покупать луноход.
Re[4]: Нет возможности использовать константные ссылки
От: Cyberax Марс  
Дата: 10.11.06 14:21
Оценка: +2
GlebZ wrote:
> При любом изменении создаем новый экземпляр. Ессно при таком подходе
> важно наличие GC.
А теперь представь, что у тебя сеть объектов. Каждый раз будешь всю сеть
клонировать?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[6]: недостатки системы типов .NET
От: Cyberax Марс  
Дата: 11.11.06 20:03
Оценка: +2
VladD2 wrote:
> kan>А в каком языке есть const, но нет const_cast?
> Вольфхаунд прав. const_cast — это бред придуманный только в С++.
> В других языках обычно и const нет. Вместо этого там просто есть
> неизменяемые переменные. Более того есть зыки в которых все переменные
> не изменяемые (Хаскель, например).
Так неизменяемые переменные не нужны, а нужен контекст, в котором
нельзя изменять объекты.

На самом деле, const — это один простейших типов программирования по
контракту. Модификатором 'const' мы обозначаем, что метод не меняе
инвариант класса.

Как раз стоило бы развить эту идею для большего статического контроля
правильности программы. Или ты против статического контроля?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: недостатки системы типов .NET
От: Андрей Хропов Россия  
Дата: 13.11.06 16:59
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Хотя согласен, что идея помечать методы (да и классы) как неизменяемые — это хорошая идея. И надо будет ее реализовать.


На самом деле правильная идея (которая хорошо ложится на философию Немерле) как раз делать их (классы и методы) по умолчанию неизменяемыми, а как раз помечать изменяемые случаи!

А то ведь в основном людям лень дополнительно чего-то дописывать.
поэтому Nemerle провоцирует делать неизменяемые переменные (чтобы не писать mutable),
а C++ — изменяемые (чтобы не писать const) .
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.06 03:48
Оценка: +2
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Как раз очень правильно. Потому что утилитный метод лучше делать статическим.


AF>>А почему тогда у List<T> его сделали экземплярным?


AVK>Потому что пиип.


Лично я на это дело сморю так. Если в языке есть методы расширения и IDE их понимает, то возможно действительно лучше оформлять утилитарные методы как статические методы расширения. Но если мы имеем дело с языком не поддерживающим методы расширения (C# 1-2), то лучше уж сделать их экземплярными просто для удобства и краткости. Так что ребята писавшие List<T> поступили совершенно верно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.06 03:48
Оценка: 14 (1)
Здравствуйте, AndreiF, Вы писали:

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


WH>>
WH>>using SMByteEps = ConsoleApplication3.StateMachine<byte>.EpsTransition;
WH>>


AF>Плохо только, using придется писать для каждого типа и в каждом файле, где они используются.


Тогда переходи на Nemerle . В нем объявляешь:
type SMByteEps = ConsoleApplication3.StateMachine<byte>.EpsTransition;

и используй SMByteEps в любом месте.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: недостатки системы типов .NET
От: Алексей П Россия  
Дата: 15.11.06 16:30
Оценка: 14 (1)
Здравствуйте, _FRED_, Вы писали:

_FR>А ссылку на документиацию можешь дать? А то я не нашёл только здесь

Не могу, документации вообще мало.

_FR>Может ли псевдоним (alias) быть незавершённым дженерик-типом? То есть примерно

АП>>Nemerle:
type Context[T] = System.Collection.Generic.List[T]

Проверил, можно. Использование такого алиаса компилится в простое new List<тип>()
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: недостатки системы типов .NET
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.11.06 09:08
Оценка: 7 (1)
Здравствуйте, GlebZ, Вы писали:

AF>>Нельзя перегружать методы по типу возвращаемого значения.

GZ>+1 Аналогично ковариантности.

В CLI то вроде как раз можно.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.11.06 09:12
Оценка: +1
Здравствуйте, AndreiF, Вы писали:

AF>Нельзя перегружать методы по типу возвращаемого значения.


Это особенности конкретных языков, связанные с проблемами в синтаксисе. Сам CLR такую перегрузку поддерживает.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[3]: недостатки системы типов .NET
От: GlebZ Россия  
Дата: 09.11.06 11:53
Оценка: +1
Здравствуйте, kan, Вы писали:

kan>GlebZ wrote:


>> AF>Нет возможности использовать константные ссылки на объекты, что

>> вынуждает программиста создавать read-only версии объектов —
>> дополнительная ручная работа.
>> +1
kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта операция не согласуется с идеологией безопасных языков.
Нет. Не обязательно. Есть другой вопрос: зачем это делать на уровне CLI, и как передавать данный модификатор между сборками если вторая сборка скомпилена в языке который не поддерживает модификатор const. Вобщем const здесь не нужен.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.11.06 22:55
Оценка: +1
Здравствуйте, AndreiF, Вы писали:

AF>
AF>class Test: ICloneable
AF>{
AF>  public Test Clone() // а вот хрен то там!
AF>    {
AF>    ...
AF>    }
AF>}
AF>

AF>Так что вместо простого и понятного кода придется воротить два метода и явную реализацию метода интерфейса, менее понятно и более громоздко. И это еще самый тривиальный пример.

interface ICloneable<T>
{
    T Clone();
}

class Test : ICloneable<Test>
{
  public Test Clone() // OK
    {
    ...
    }
}



WH>>Дело в том что есть объекты которые должны быть изменяемыми и есть объекты которые должны быть не изменяемыми.


AF>Чушь.

AF>
AF>// made by Vasya
AF>class Document : IDisposable
AF>{
AF>....
AF>}

AF>// made by Petya
AF>static class Printer
AF>{
AF>  public static Print(Document doc)
AF>    {
AF>      ...
AF>        doc.Dispose(); // опа!
AF>    }
AF>}
AF>

AF>Ну так что, документ он какой — изменяемый или неизменямый?

Ты что тут пытался то продемонстрировать?

AF>>>Нет кортежей.

WH>>Легко эмулируются при помощи генериков.

AF>а ты пробовал?


Ну, вон в Немерле так и сделано.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: недостатки системы типов .NET
От: FR  
Дата: 10.11.06 11:02
Оценка: :)
Здравствуйте, kan, Вы писали:

kan>VladD2 wrote:


>> kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта

>> операция не согласуется с идеологией безопасных языков.
>> Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.
kan>А в каком языке есть const, но нет const_cast?

В большинстве функциональных, правда неявный
Re: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 12:28
Оценка: +1
Здравствуйте, Odi$$ey, Вы писали:

OE>о, кстати этот вопрос я тоже пока не догнал, можно поподробнее — есть ссылочный тип, есть метод, в который он передается в качестве параметра и который его изменять не должен, только читать — как это разруливается в C#?

В С# это никак не обрабатывается. Единственный способ — это вообще не создавать методов меняющих внутреннее состояние объекта. Пример того что это работает — String.
Re[3]: Нет возможности использовать константные ссылки
От: WolfHound  
Дата: 10.11.06 12:38
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>На мой взгляд здесь сколько не косяк, а именно недоработочка. Если бы у типа был некоторый модификатор который запрещал бы менять внутреннее состояние объекта кроме как в конструкторе, IMHO, это было бы правильнее и проще.

И я о том же. Должны быть изменяемые и не изменяемые объекты.
А где-то изменяемый и где-то не изменяемый объект это прямой путь на минное поле.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 10.11.06 12:44
Оценка: -1
Здравствуйте, GlebZ, Вы писали:

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


V>>С точки зрения шарпа, тут косяк в архитектуре, так как по сути передаваемый объект имеет открытые методы и свойства, доступ к которым должен быть закрыт. То есть надо было передавать не объект целиком, а, лишь, некоторый тоненький интерфейс, через который можно делать только то, что разрешено явно. Хорошо это, или плохо — это другой вопрос. Я вот не знаю, хорош этот подход, или, наоборот плох. Хотелось бы услышать соображения общественности

GZ>На мой взгляд здесь сколько не косяк, а именно недоработочка. Если бы у типа был некоторый модификатор который запрещал бы менять внутреннее состояние объекта кроме как в конструкторе, IMHO, это было бы правильнее и проще.

Но факт остается фактом: попытка вызвать метод, который меняет состояние, это фактически попытка вызова закрытого в данном контексте метода. Для закрытия методов в зависимости от контекста имеются штатные механизмы. Да, писанины выходит больше, но, зато все очень гибко и понятно. Идея с модификатором, конечно, хороша, но у нее есть один приличный косяк: как определять, меняет ли метод внутреннее состояние объекта, или не меняет? Вот чтобы рещить эту проблему и придется добавлять всякие консткасты, за использование которых джедаи потом "бъют морды".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[5]: недостатки системы типов .NET
От: AndreiF  
Дата: 10.11.06 12:49
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

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

WH>И должен он будет работать в глобальном масштабе... Ибо если на тойже виртуальной машине сделать межпроцессное общение типа как в сингулярити...

Подозреваю, что рано или поздно всё к этому и придет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Нет возможности использовать константные ссылки
От: WolfHound  
Дата: 10.11.06 12:52
Оценка: +1
Здравствуйте, prVovik, Вы писали:

V>Как определить, что метод не меняет состояние объекта?

Это должно быть свойством типа. Как value типы и reference типы. Также должно быть еще одно измерение mutable типы и imutable типы.
Те объект либо изменяемый либо нет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: недостатки системы типов .NET
От: kan Великобритания  
Дата: 10.11.06 13:14
Оценка: +1
WolfHound wrote:

>> > Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.

> kan>А в каком языке есть const, но нет const_cast?
> Ты лучше покажи язык кроме С++ где этот самый const_cast есть...
Потому что это единственный (мне известный) язык (не функциональный) где есть const.
Автор вопроса о const явно подразумевал C#, на крайняк CLI, что явно не функциональные языки.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: недостатки системы типов .NET
От: kan Великобритания  
Дата: 10.11.06 13:15
Оценка: -1
FR wrote:

>> > kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта

>> > операция не согласуется с идеологией безопасных языков.
>> > Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.
> kan>А в каком языке есть const, но нет const_cast?
> В большинстве функциональных, правда неявный
Функциональщина не в счёт, там вопрос о const ни у кого и не возникает, имхо.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: недостатки системы типов .NET
От: WolfHound  
Дата: 10.11.06 13:27
Оценка: +1
Здравствуйте, kan, Вы писали:

kan>Потому что это единственный (мне известный) язык (не функциональный) где есть const.

kan>Автор вопроса о const явно подразумевал C#, на крайняк CLI, что явно не функциональные языки.
И много ты знаешь чисто функциональных языков?
Подавляющие большинство функциональных языков позволяют писать в императивном стиле. А если посмотреть на nemerle то код на нем вобще можно сделать 1 в 1 (за исключением мелких синтаксических отличий) как на C#.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Нет возможности использовать константные ссылки
От: kan Великобритания  
Дата: 10.11.06 16:52
Оценка: -1
GlebZ wrote:

> kan>Я прекрасно понимаю, что аналогичный код можно переписать в

> функциональном стиле, но зачем? Императивныые языки нужны
> kan>для того, чтобы писать в императивном стиле. А в этом случае const
> весьма полезен.
> Видишь ли, никто и не предлагал отказаться от mutable объектов. В данном
Так разговор идёт о const — позволяет делать что-то типа мутабельности (но не совсем её) на уровне методов, притом
проверка compile-time (!), а не "as documented". Как в C# узнать, что данный объект немутабельный? Правильно — залезть в
документацию (если она есть, иначе — сорцы, если они есть, иначе — вешаться) и прочитать. Больше никак. Как узнать, что
данный метод можно вызвать без клонирования объекта, дабы чьи-нибудь данные не попортить? Правильно — залезть в
сорцы/документацию. Больше никак.
А если вдруг какой-нибудь метод изменили и он стал изменять состояние? Старый код об этом никак не узнает.

> случае очень показательны константные строки в C++. Там есть режим

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

> легче. Там так строки уже работают. В C++ вся идея изгажена тем, что

> константу можно перевести в указатель без константы, и соответсвенно
Это как? Без явного приведения?

> нарушить данное правило.

Нет, идея С++ в том, что он небезопасный — можно нарушить любое правило.

> kan>Если на императивном языке пишут в функциональном стиле — это

> проблема, неправильно выбрали язык.
> Нет. Если ты посмотришь на все введения в императивные языки за
> последние 5 лет, то все они пришли из функциональных языков. К тому же,
> например C# особенно трешка, напрямую поддерживает функциональное
> программирование. Только менее императивным он не стал. Или например,
Как именно поддерживает? Чем эта поддержка принципиально отличается от C++? Можно ссылку.

> если возьмешь к примеру STL — то это прямая эмуляция функций высшего

> порядка.
Мягко говоря, не очень... скорее тут "виноваты" шаблоны, stl не при чём, а это исчисление типов, метапрограммирование.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: недостатки системы типов .NET
От: Андрей Хропов Россия  
Дата: 11.11.06 11:56
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

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


kan>>А в каком языке есть const, но нет const_cast?

GZ>Есть понятие mutable/unmutable. Оно в функциональных языках часто присутсвует. Причем unmutable(неизменяемый) — это основной стиль.
Только immutable а не unmutable.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: недостатки системы типов .NET
От: Андрей Хропов Россия  
Дата: 11.11.06 11:56
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

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


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


kan>>>>А в каком языке есть const, но нет const_cast?

GZ>>>Есть понятие mutable/unmutable. Оно в функциональных языках часто присутсвует. Причем unmutable(неизменяемый) — это основной стиль.

_FR>>Константность объекта и константность ссылки на него — разные вещи. Я подозреваю, что "в функциональных языках" под "unmutable(неизменяемый)" понимают неизменяемость ссылки, а вовсе не данных, на которые она указывает.

GZ>
GZ>immutable i=10;
GZ>mutable i=10;
GZ>


Во-первых ключевого слова immutable в Nemerle нет (все по умолчанию immutable), пишут просто
def i = 10;

или если член класса то вообще просто
i : int;
.

А во-вторых FR говорил вот про что:

[Record]
class A
{
  public mutable x : int;

  public static Main() : void
  {
    def a1 = A(1);
        
        //a1 = A(2);  // ошибка компиляции - a1 неизменяемая!
    a1.x = 5;            // a объект на который она указывает - изменяемый!
    
    System.Console.WriteLine($"a1.x = $(a1.x)"); // выдает "a1.x = 5"
  }
}


В С++ можно действовать более гибко, хотя больше писанины:
class A
{
public:
  int x;
  
  A(int _x) : x(_x) {}
};

int main()
{
  const A* a1 = new A(1); // указатель на неизменяемый объект
  //a1->x = 5;              // ошибка компиляции - неизменяемый объект изменять нельзя!
  delete a1;
  
  a1 = new A(2);          // а сам указатель - можно!
  delete a1;
  
  /////////////////////////////////////////////////
  
  A *const a2 = new A(1); // константный указатель на изменяемый объект
  a2->x = 5;              // объект изменять можно
  //a2 = new A(2);          // ошибка компиляции - указатель изменять нельзя!
  delete a2;
  
  /////////////////////////////////////////////////
  
  const A *const a3 = new A(1); // константный указатель на неизменяемый объект
  //a3->x = 5;                    // ошибка компиляции - константный объект изменять нельзя!
  //a3 = new A(2);                // ошибка компиляции - указатель тоже изменять нельзя!
  delete a3;
  
  return 0;
}
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Нет возможности использовать константные ссылки
От: Cyberax Марс  
Дата: 11.11.06 13:14
Оценка: +1
GlebZ wrote:
> C>А теперь представь, что у тебя сеть объектов. Каждый раз будешь всю сеть
> C>клонировать?
> Не-а. Тут как раз и есть плюсы такого подхода. Для того чтобы получить
> другую сеть не обязательно клонировать объекты. Один и тот же объект
> неизменяем и может лежать в любой подсети. Меняется ведь только ссылка
> на него.
Вот тебе ситуация, объекты А и Б циклически связаны друг с другом:
struct A
{
     B *b;
};
struct B
{
     A *a;
};


Если я создаю новый A, оставив у него ссылку на старый объект, то
получится интересная ситуация:
A *oldA;
A *newA=doSomething(oldA);

assert(newA->b->a == newA); //WTF?????


Чтобы ее разрулить нужно будет клонировать еще и объект B. Ну и все
связаные с ним объекты.

Почему я об этом говорю — у меня была именно такая ситуация, которую я
разрулил введением контекстных ссылок. То есть значение ссылки у меня
зависит от контекста. Получается достаточно большой overhead, но у меня
контексты являются достаточно грубыми единицами деления (с помощью них
организуются транзакции на графе объектов), так что в моем случае это не
так страшно. А вот если контекст создавать на каждое изменение
переменной....
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[8]: недостатки системы типов .NET
От: AndreiF  
Дата: 12.11.06 06:23
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Не против. Но хотелось бы, чтобы пометка метода как неизменяющего состояние класса гарантировало бы это на сто процентов. А вот в С++ такой гарантии нет.


В С++ вообще нет никаких гарантий
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Нет возможности использовать константные ссылки
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.06 15:32
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Это должно быть свойством типа. Как value типы и reference типы. Также должно быть еще одно измерение mutable типы и imutable типы.

WH>Те объект либо изменяемый либо нет.

+1
Однако это не должно мешать наличию неизменяемых переменных. Неизменность переменных — это особенность алгоритма текущей функции. А неизменность типа — это особенность конкретного типа.

Например, int принципиально изменяем в любом ИЯ. Но не во всех алгоритмах имеет смысл изменять целочисленные переменные. Декларируя переменную как неизменяемую мы можем защитить себя от ошибок связаннях с неверным применением переменных.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 13.11.06 06:30
Оценка: -1
Здравствуйте, VladD2, Вы писали:

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


V>>Ну вот мы указали, что класс imutable. А он внутри себя пишет в лог. Как в этом случае должен поступить компилятор?


VD>Очевидно должна быть возможность пометить любой метод как безопасный с точки зрения инварианта типов программы. Так что методы вывода на консоль надо просто пометить таким атрибутом и компилятор будет пропускать его.


Вот именно, я об этом и говорю. Но чем этот подход будет отличаться от const_cast'a? Ну да, чисто с эстетической точки зрения красивее, но суть таже.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[6]: недостатки системы типов .NET
От: WolfHound  
Дата: 13.11.06 07:59
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Коваринтность будет доступна почти везде. Можно будет отказаться от боксинга. Упростится модель абстракйий. В общем, много чего упростится. А компилятор может скомпенсировать потери в производительности.

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

VD>В общем, я считаю, что когда-то, когда уровень рантаймов и компиляторов выростет до невероятных высот такой дизайн будет самым верным (собственно дизайн Смолтока, от части). Но на время выпуска первого фрэймворка выбор МС был конечно оправдан.

Сомневаюсь что они когданибудь будут настолько хороши(ну разве очень не скоро). Ибо эта задачка сравнима с компиляцией какогонибудь руби или питона.

VD>Джит уже работает в глобальном масштабе, если таковым считать масштаб процесса.

Тут придется оптимизировать весь код на машине при каждом изменении.

WH>>Ибо если на тойже виртуальной машине сделать межпроцессное общение типа как в сингулярити...

VD>И что будет? Все будет ОК. Там взаимодействие ведется неизменяемыми типами.
Неа. Там используются value типы. Причем не любые, а только те которые не содержат ссылок.
Можно конечно передовать граф объектов по значению но тут могут опять быть грабли с тем что придется тянуть очень много всего в другой процесс. Те могут быть жуткие потери производительности и памяти при безобидных изменениях.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Нет возможности использовать константные ссылки
От: WolfHound  
Дата: 13.11.06 07:59
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Например, int принципиально изменяем в любом ИЯ. Но не во всех алгоритмах имеет смысл изменять целочисленные переменные. Декларируя переменную как неизменяемую мы можем защитить себя от ошибок связаннях с неверным применением переменных.

Вот только AndreiF хочет иметь возможность с одним и темже объектом в одном контексте работать как с изменяемым, а в другом как с не изменяемым. Те мешает мух с котлетами.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: недостатки системы типов .NET
От: WolfHound  
Дата: 13.11.06 07:59
Оценка: +1
Здравствуйте, AndreiF, Вы писали:

AF>Ты будешь смеяться, но и в этом может быть смысл. Например, если нужно выжать из системы максимум производительности — в этом случае тотальная кросс-оптимизация всех модулей будет вполне уместна.

Вот только если не делать так как ты говоришь можно и из системы выжать все и не перекомпилировать весь код.

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

Нет. В твоей системе придется перекомпилировать вобще все и вобще всегда. Ибо любое изменение кода может повлечь за собой невозможность оптимизации которое цепной реакцией распространиться на всю систему.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.11.06 11:34
Оценка: :)
Здравствуйте, AndreiF, Вы писали:

AVK>>Как раз очень правильно. Потому что утилитный метод лучше делать статическим.


AF>А почему тогда у List<T> его сделали экземплярным?


Потому что пиип.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[8]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 13:12
Оценка: +1
Здравствуйте, prVovik, Вы писали:

V>Ну да, ну да, const_cast'ы рулят!


Дались тебе эти конст-касты. Когда я писал на плюсах, мне они были нужны только при вызове WinAPI и ему подобных. Во всех остальных случаях грамотного проектирования и расстановки mutable вполне достаточно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: недостатки системы типов .NET
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 14.11.06 08:51
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Лично я на это дело сморю так. Если в языке есть методы расширения и IDE их понимает, то возможно действительно лучше оформлять утилитарные методы как статические методы расширения. Но если мы имеем дело с языком не поддерживающим методы расширения (C# 1-2), то лучше уж сделать их экземплярными просто для удобства и краткости. Так что ребята писавшие List<T> поступили совершенно верно.


Ага, а потом, если нужно сделать свой нестандартный IList, то сортировку придётся писать отдельно (хорошо, что хоть PowerCollections помогает). Просто это бессмысленно. Неужели было тяжело сделать статический класс с методом Sort, а затем в List просто написать дополнитльный метод?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.06 13:17
Оценка: +1
Здравствуйте, konsoletyper, Вы писали:

K>Ага, а потом, если нужно сделать свой нестандартный IList, то сортировку придётся писать отдельно


Не прийдется. List<T> использует функции сортировки из класса Array. List<T>.Sort не более чем обертка.

K>(хорошо, что хоть PowerCollections помогает). Просто это бессмысленно.


Бессмысленны вот такие заявления. А смысл наличия метода Sort в List<T> очевиден. Метод не приходится искать черт знает где и код получается короче.

В общем, разговр бессмысленный. Когда сделают методы расширения и поддржку для них в IDE, то конечно смысла встраивать подбные методы в классы не будет. Но пока этого нет, нет смысла обсуждать это.

K> Неужели было тяжело сделать статический класс с методом Sort, а затем в List просто написать дополнитльный метод?


Так и сделали. Открой рефлектором исхдники этого метода и убедись, что там всего лишь вызов статической функции.

Другое дело, что не сделали обошенной реализации Sort для IList<T>. Вот это уже действительно не грамотно.

Что до PowerCollections, то я так ни разу еге и не использовал в своих программах. Как-то нет потребности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: недостатки системы типов .NET
От: AndreiF  
Дата: 09.11.06 06:50
Оценка:
Пардон, ссылка кривая. Правильный адрес — здесь
Автор: AndreiF
Дата: 11.10.06
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: недостатки системы типов .NET
От: GlebZ Россия  
Дата: 09.11.06 08:58
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Впрочем, это только мое мнение — на абсолютную правоту я не претендую

И это правильно.

AF>Если у кого-то есть желание расширить список — welcome.

нет. Но поправить — можно. Прежде всего — CLI это не пользовательский язык программирования а все-го лишь основа для расширения с помощью более высоких языков программирования. И именно с этой точки зрения нужно подходить.

AF>Нет ни множественного наследования реализаций, ни его заменителей.

+1. Только это отнюдь не значит что его нельзя реализовать в пользовательском языке.

AF>Нет ковариантности для переопределения виртуальных методов.

+1. Только если бы ковариантность была, то это создало бы более существенные проблемы для языков которые не поддерживают ковариантность. С другой стороны, ковариантность для пользовательских языков можно создать.

AF>Нет возможности использовать константные ссылки на объекты, что вынуждает программиста создавать read-only версии объектов — дополнительная ручная работа.

+1

AF>Нельзя перегружать методы по типу возвращаемого значения.

+1 Аналогично ковариантности.

AF>Нет кортежей.

А кто мешает их сделать в пользовательском языке?

AF>Критически важные системные исключения (OutOfMemoryException, ThreadAbortException, ExecutionEngineException и т.п.) наследуются от того же базового класса, что и частно используемые ArgumentException, NotSupportedException и так далее. Это провоцирует плохих программистов писать конструкции наподобие

AF>catch (Exception) { return false; }
Это не есть верно. Попробуй словить OutOfMemoryException и ExecutionEngineException вышеуказанным способом. Вряд ли это получится.

AF>Наличие типов, которые явно обозначаются как передаваемые через стек, и все связанные с этим усложнения системы типов (боксинг) и ограничения (нельзя наследовать от структур). На самом деле, решать, каким образом передавать объект в каждом конкретном случае – это задача оптимизатора.

-1. Жабе пришлось пройти нехилый путь, чтобы сделать хоть как нибудь оптимизатор.

AF>Коллекции

AF>Например, String.Split возвращает string[], а не IList<string> или IEnumerable<string>, как можно было ожидать.
IList — это несколько другая опера, а IEnumerable<string> можешь легко получить из string[]. И к тому же обращение к объекту string[] несколько быстрее работает чем IEnumerable<string>.
AF>Для массивов возможна ко/контра-вариантность элементов, для остальных коллекций – нет. Массивы можно инициализировать списком значений в коде, для коллекций это невозможно.
AF>Большинство коллекций поддерживают возможность добавлять элементы без пересоздания объекта, для массивов эта возможность недоступна. Для большинства коллекций доступен метод AsReadOnly() или аналог, для массивов такой возможности нет.
Не забывай что коллекции чаще всего это те же массивы но обросшие мясом(то бишь методами).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: недостатки системы типов .NET
От: AndreiF  
Дата: 09.11.06 09:15
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Это не есть верно. Попробуй словить OutOfMemoryException и ExecutionEngineException вышеуказанным способом. Вряд ли это получится.


Если не ошибаюсь, это только во второй версии фреймворка добавили повторный выброс системных исключений из блоков catch. ИМХО, это явный костыль.

GZ>-1. Жабе пришлось пройти нехилый путь, чтобы сделать хоть как нибудь оптимизатор.


Все равно я думаю, что escape-анализ — это самый правильный путь. Пусть и более сложный в реализации.

GZ>Не забывай что коллекции чаще всего это те же массивы но обросшие мясом(то бишь методами).


Проблема в том, что число сущностей умножено сверх всякой необходимости.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: недостатки системы типов .NET
От: prVovik Россия  
Дата: 09.11.06 09:25
Оценка:
Здравствуйте, GlebZ, Вы писали:


AF>>Критически важные системные исключения (OutOfMemoryException, ThreadAbortException, ExecutionEngineException и т.п.) наследуются от того же базового класса, что и частно используемые ArgumentException, NotSupportedException и так далее. Это провоцирует плохих программистов писать конструкции наподобие

AF>>catch (Exception) { return false; }
GZ>Это не есть верно. Попробуй словить OutOfMemoryException и ExecutionEngineException вышеуказанным способом. Вряд ли это получится.
Как, впрочем, и ThreadAbortException
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[3]: недостатки системы типов .NET
От: prVovik Россия  
Дата: 09.11.06 09:28
Оценка:
Здравствуйте, AndreiF, Вы писали:

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


GZ>>Это не есть верно. Попробуй словить OutOfMemoryException и ExecutionEngineException вышеуказанным способом. Вряд ли это получится.


AF>Если не ошибаюсь, это только во второй версии фреймворка добавили повторный выброс системных исключений из блоков catch. ИМХО, это явный костыль.


Нет, соль в том, что ты некоторые исключения catch'ем не отловишь. Ибо поздно пить боржоми...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[3]: недостатки системы типов .NET
От: GlebZ Россия  
Дата: 09.11.06 09:30
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

AF>>>Нельзя перегружать методы по типу возвращаемого значения.

GZ>>+1 Аналогично ковариантности.

ANS>В CLI то вроде как раз можно.

Точно. Слишком быстро прочитал. Это не CLS совместимо, но возможно. Посыпаю голову пеплом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: недостатки системы типов .NET
От: GlebZ Россия  
Дата: 09.11.06 09:35
Оценка:
Здравствуйте, prVovik, Вы писали:

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



AF>>>Критически важные системные исключения (OutOfMemoryException, ThreadAbortException, ExecutionEngineException и т.п.) наследуются от того же базового класса, что и частно используемые ArgumentException, NotSupportedException и так далее. Это провоцирует плохих программистов писать конструкции наподобие

AF>>>catch (Exception) { return false; }
GZ>>Это не есть верно. Попробуй словить OutOfMemoryException и ExecutionEngineException вышеуказанным способом. Вряд ли это получится.
V>Как, впрочем, и ThreadAbortException
Это еще почему??? ThreadAbortException спокойно ловится. У него просто есть свои причуды (после прохода по catch блоку он снова бросается).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: недостатки системы типов .NET
От: prVovik Россия  
Дата: 09.11.06 09:47
Оценка:
Здравствуйте, GlebZ, Вы писали:


AF>>>>Критически важные системные исключения (OutOfMemoryException, ThreadAbortException, ExecutionEngineException и т.п.) наследуются от того же базового класса, что и частно используемые ArgumentException, NotSupportedException и так далее. Это провоцирует плохих программистов писать конструкции наподобие

AF>>>>catch (Exception) { return false; }
GZ>>>Это не есть верно. Попробуй словить OutOfMemoryException и ExecutionEngineException вышеуказанным способом. Вряд ли это получится.
V>>Как, впрочем, и ThreadAbortException
GZ>Это еще почему??? ThreadAbortException спокойно ловится. У него просто есть свои причуды (после прохода по catch блоку он снова бросается).

Ну может и так...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[3]: недостатки системы типов .NET
От: GlebZ Россия  
Дата: 09.11.06 10:01
Оценка:
Здравствуйте, AndreiF, Вы писали:

GZ>>Это не есть верно. Попробуй словить OutOfMemoryException и ExecutionEngineException вышеуказанным способом. Вряд ли это получится.

AF>Если не ошибаюсь, это только во второй версии фреймворка добавили повторный выброс системных исключений из блоков catch. ИМХО, это явный костыль.
Нет. Это не повторный выброс. Это фактически остановка приложения. Здесь ты еще забыл StackOverflowException.

GZ>>-1. Жабе пришлось пройти нехилый путь, чтобы сделать хоть как нибудь оптимизатор.

AF>Все равно я думаю, что escape-анализ — это самый правильный путь. Пусть и более сложный в реализации.
Нет. Это скорее ошибка. Повторюсь CLI — создавался как виртуальная машина для языков более высокого уровня. Байткод изначально предназначался для Java и получился как Java. Разделение на стек и память надо относить именно как плюс CLI, так как есть куча языков для которых такое разделение есть(например С++, С#) и нет(многие функциональные языки). Если его нет, то такой анализ(если он вообще для них нужен) должен проводится на уровне данного языка, и в терминах этого языка.

GZ>>Не забывай что коллекции чаще всего это те же массивы но обросшие мясом(то бишь методами).

AF>Проблема в том, что число сущностей умножено сверх всякой необходимости.
Я думаю нормально. Достаточно много примитивов чтобы пользоваться только ими. И самое главное, они весьма расширяемы чтобы строить свои коллекции.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: недостатки системы типов .NET
От: AndreiF  
Дата: 09.11.06 10:49
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Нет. Это не повторный выброс. Это фактически остановка приложения. Здесь ты еще забыл StackOverflowException.


Если тупо сделать throw new ExecutionEngineException(), то ловится вполне благополучно. А если у них есть какой-то "специальный throw", то это, как и любые "особые случаи" — явный недочет в дизайне.

GZ>Нет. Это скорее ошибка. Повторюсь CLI — создавался как виртуальная машина для языков более высокого уровня. Байткод изначально предназначался для Java и получился как Java. Разделение на стек и память надо относить именно как плюс CLI, так как есть куча языков для которых такое разделение есть(например С++, С#) и нет(многие функциональные языки). Если его нет, то такой анализ(если он вообще для них нужен) должен проводится на уровне данного языка, и в терминах этого языка.


-1
Передача через стек — всего лишь способ оптимизации. А в С++ стековые значения все равно совсем не такие, как в CLI.

GZ>Я думаю нормально. Достаточно много примитивов чтобы пользоваться только ими.


слишком много
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: недостатки системы типов .NET
От: kan Великобритания  
Дата: 09.11.06 11:03
Оценка:
GlebZ wrote:

> AF>Нет возможности использовать константные ссылки на объекты, что

> вынуждает программиста создавать read-only версии объектов —
> дополнительная ручная работа.
> +1
Почему-то мне кажется, что const нельзя делать без const_cast, а эта операция не согласуется с идеологией безопасных языков.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: недостатки системы типов .NET
От: GlebZ Россия  
Дата: 09.11.06 11:30
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Если тупо сделать throw new ExecutionEngineException(), то ловится вполне благополучно. А если у них есть какой-то "специальный throw", то это, как и любые "особые случаи" — явный недочет в дизайне.

Конечно у него другой throw. У меня есть подозрение что ты немного путаешь. Наследование не обозначает что внешняя обработка наследников должна быть однотипная. Внутреннее поведение должно быть похожее в той степени какой это позволяет полиформизм. А внешняя нет. Да и дебаггерам как то это все побоку, поскольку они могут вылавливать данные исключения.

GZ>>Нет. Это скорее ошибка. Повторюсь CLI — создавался как виртуальная машина для языков более высокого уровня. Байткод изначально предназначался для Java и получился как Java. Разделение на стек и память надо относить именно как плюс CLI, так как есть куча языков для которых такое разделение есть(например С++, С#) и нет(многие функциональные языки). Если его нет, то такой анализ(если он вообще для них нужен) должен проводится на уровне данного языка, и в терминах этого языка.

AF>-1
AF>Передача через стек — всего лишь способ оптимизации. А в С++ стековые значения все равно совсем не такие, как в CLI.
Абсолютно правильно. Не все возможно запихать в стек. А если возможно то поведение сущности (например после процедуры box/unbox) несколько другое. И если предоставить эту информацию программисту чтобы он это учитывал, то система получится более эффективная чем набор эвристик. К тому же не всем языкам нужна именно модель памяти предоставленная Net. Кому-то достаточно и наиболее эффективно именно работа только в стеке(особенно это было бы заметно в форте), или наоборот в динамической памяти без стека(как было предложено в одной статье по функциональному программированию на этом сайте). Вобщем CLI — это инструмент. А модель памяти зависит от самого языка.

GZ>>Я думаю нормально. Достаточно много примитивов чтобы пользоваться только ими.

AF>слишком много
Кому как. Нет ни одной типа коллекции которую я бы не юзал. Все пригождается.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: недостатки системы типов .NET
От: AndreiF  
Дата: 09.11.06 12:03
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Кому как. Нет ни одной типа коллекции которую я бы не юзал. Все пригождается.


Проблема не в том, что есть "лишние" типы коллекций. Проблема в том, что между ними слишком много мелких неприятных различий. Почему например для массивов есть ко/контра-вариантность, а для других коллекций — нет?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: недостатки системы типов .NET
От: kan Великобритания  
Дата: 09.11.06 12:25
Оценка:
GlebZ wrote:

>> > AF>Нет возможности использовать константные ссылки на объекты, что

>> > вынуждает программиста создавать read-only версии объектов —
>> > дополнительная ручная работа.
>> > +1
> kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта
> операция не согласуется с идеологией безопасных языков.
> Нет. Не обязательно.
Иначе им будет опасно пользоваться. А вдруг неправильно задизайнили либу и приходится изменять константы?

> Есть другой вопрос: зачем это делать на уровне CLI,

> и как передавать данный модификатор между сборками если вторая сборка
> скомпилена в языке который не поддерживает модификатор const. Вобщем
> const здесь не нужен.
Логично, если добавить const на уровень языка, просто как проверка времени компиляции, то ок.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: недостатки системы типов .NET
От: WolfHound  
Дата: 09.11.06 12:37
Оценка:
Здравствуйте, AndreiF, Вы писали:

WH>>Решается метапрограммированием. И вобще наследование реализации нужно по возможности избегать. Ибо оно дает слишьком сильные связи что мешает развивать систему.

AF>Метапрограммированием решается вообще всё — это не аргумент.
А как насчет сильной связанности?

AF>Так что вместо простого и понятного кода придется воротить два метода и явную реализацию метода интерфейса, менее понятно и более громоздко. И это еще самый тривиальный пример.

А может нужно просто подругому подходить к проектированию? Вот у меня почемуто таких проблем не возникает.
К тому же это можно решить на уровне конкретного языка. Или вобще метапрограммированием.

WH>>Дело в том что есть объекты которые должны быть изменяемыми и есть объекты которые должны быть не изменяемыми.

AF>Чушь.
Как скажите молодой человек.

AF>>>Нет кортежей.

WH>>Легко эмулируются при помощи генериков.
AF>а ты пробовал?
Пробовал. Получилось при помощи одного генерик класса и одного класса заглушки. С их помощью можно генерировать кортежи произвольной длинны. Если у тебя не хватает фантазии то это не мои проблемы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: недостатки системы типов .NET
От: GlebZ Россия  
Дата: 09.11.06 12:40
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Проблема не в том, что есть "лишние" типы коллекций. Проблема в том, что между ними слишком много мелких неприятных различий.

Тебе не нравится
void Printf(object[] obj)
{
...    
}
int[] range=new int[]
...
Printf(range);

Напиши в Microsoft. Может уберут. Но я здесь тебе не помошник.
AF>Почему например для массивов есть ко/контра-вариантность, а для других коллекций — нет?
Для каких других? Основная проблема в том, что другие коллекции являются либо коллекциями object либо generics. То что касается generics то это ограничение C#. В С++/CLI насколько я помню такое можно делать. И насколько я помню, это поддерживается именно CLI.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.11.06 22:55
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Все равно я думаю, что escape-анализ — это самый правильный путь. Пусть и более сложный в реализации.


Ради справедливости надо заметить, что тогда по уму нужно отказываться вообще от вэлью-типов. Это снимет море проблем. Но оптимизатр при этом должен будет быть просто зверским. Иначе будет ну очень не быстро и расточительно по памяти.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: недостатки системы типов .NET
От: AndreiF  
Дата: 10.11.06 05:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А как насчет сильной связанности?


Смотря как применять.

WH>А может нужно просто подругому подходить к проектированию? Вот у меня почемуто таких проблем не возникает.

WH>К тому же это можно решить на уровне конкретного языка. Или вобще метапрограммированием.

Проблем у меня тоже не возникает. Но лишняя писанина напрягает.

WH>Пробовал. Получилось при помощи одного генерик класса и одного класса заглушки. С их помощью можно генерировать кортежи произвольной длинны. Если у тебя не хватает фантазии то это не мои проблемы.


опять метапрограммирование?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: недостатки системы типов .NET
От: AndreiF  
Дата: 10.11.06 05:09
Оценка:
Здравствуйте, VladD2, Вы писали:

ну зачем такой страшный оверквотинг?

AF>>Ну так что, документ он какой — изменяемый или неизменямый?


VD>Ты что тут пытался то продемонстрировать?


То, что один и тот же объект может быть как изменяемым так и неизменяемым, в зависимости от контекста где этот объект используется. Применение read-only версий объектов — это всего лишь костыль.

VD>Ну, вон в Немерле так и сделано.


Ок, этот пункт убираю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: недостатки системы типов .NET
От: AndreiF  
Дата: 10.11.06 05:14
Оценка:
Здравствуйте, VladD2, Вы писали:

AF>>Большинство коллекций поддерживают возможность добавлять элементы без пересоздания объекта, для массивов эта возможность недоступна. Для большинства коллекций доступен метод AsReadOnly() или аналог, для массивов такой возможности нет.


VD>Это вообще заблуждение:


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

VD>Не понял претензии. Но подозреваю, что она поять же не к дотнету или КЛИ, а к Шарпу.


Возможно...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: недостатки системы типов .NET
От: kan Великобритания  
Дата: 10.11.06 10:39
Оценка:
VladD2 wrote:

> kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта

> операция не согласуется с идеологией безопасных языков.
> Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.
А в каком языке есть const, но нет const_cast?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: недостатки системы типов .NET
От: WolfHound  
Дата: 10.11.06 10:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ради справедливости надо заметить, что тогда по уму нужно отказываться вообще от вэлью-типов. Это снимет море проблем.

Каких проблем?

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

И должен он будет работать в глобальном масштабе... Ибо если на тойже виртуальной машине сделать межпроцессное общение типа как в сингулярити...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: недостатки системы типов .NET
От: GlebZ Россия  
Дата: 10.11.06 11:39
Оценка:
Здравствуйте, kan, Вы писали:

kan>А в каком языке есть const, но нет const_cast?

Есть понятие mutable/unmutable. Оно в функциональных языках часто присутсвует. Причем unmutable(неизменяемый) — это основной стиль.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Нет возможности использовать константные ссылки
От: Odi$$ey Россия http://malgarr.blogspot.com/
Дата: 10.11.06 11:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

AF>Нет возможности использовать константные ссылки на объекты


WH>Дело в том что есть объекты которые должны быть изменяемыми и есть объекты которые должны быть не изменяемыми. Есть объекты которые должны передоваться по ссылке и есть объекты которые должны передоватся по значению.

WH>Это не вопрос оптимизации это вопрос архитектуры. Нельзя мешать теплое с мягким. Ничего хорошего из этого не выходит.

о, кстати этот вопрос я тоже пока не догнал, можно поподробнее — есть ссылочный тип, есть метод, в который он передается в качестве параметра и который его изменять не должен, только читать — как это разруливается в C#?
... << RSDN@Home 1.2.0 alpha rev. 662>>
Re: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 10.11.06 12:02
Оценка:
Здравствуйте, Odi$$ey, Вы писали:

OE>о, кстати этот вопрос я тоже пока не догнал, можно поподробнее — есть ссылочный тип, есть метод, в который он передается в качестве параметра и который его изменять не должен, только читать — как это разруливается в C#?


С точки зрения шарпа, тут косяк в архитектуре, так как по сути передаваемый объект имеет открытые методы и свойства, доступ к которым должен быть закрыт. То есть надо было передавать не объект целиком, а, лишь, некоторый тоненький интерфейс, через который можно делать только то, что разрешено явно. Хорошо это, или плохо — это другой вопрос. Я вот не знаю, хорош этот подход, или, наоборот плох. Хотелось бы услышать соображения общественности
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[2]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 12:31
Оценка:
Здравствуйте, prVovik, Вы писали:

V>С точки зрения шарпа, тут косяк в архитектуре, так как по сути передаваемый объект имеет открытые методы и свойства, доступ к которым должен быть закрыт. То есть надо было передавать не объект целиком, а, лишь, некоторый тоненький интерфейс, через который можно делать только то, что разрешено явно. Хорошо это, или плохо — это другой вопрос. Я вот не знаю, хорош этот подход, или, наоборот плох. Хотелось бы услышать соображения общественности

На мой взгляд здесь сколько не косяк, а именно недоработочка. Если бы у типа был некоторый модификатор который запрещал бы менять внутреннее состояние объекта кроме как в конструкторе, IMHO, это было бы правильнее и проще.
Re[4]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 10.11.06 12:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


GZ>>На мой взгляд здесь сколько не косяк, а именно недоработочка. Если бы у типа был некоторый модификатор который запрещал бы менять внутреннее состояние объекта кроме как в конструкторе, IMHO, это было бы правильнее и проще.

WH>И я о том же. Должны быть изменяемые и не изменяемые объекты.
WH>А где-то изменяемый и где-то не изменяемый объект это прямой путь на минное поле.

Как определить, что метод не меняет состояние объекта?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[4]: недостатки системы типов .NET
От: vdimas Россия  
Дата: 10.11.06 12:47
Оценка:
Здравствуйте, VladD2, Вы писали:


AF>>Все равно я думаю, что escape-анализ — это самый правильный путь. Пусть и более сложный в реализации.


VD>Ради справедливости надо заметить, что тогда по уму нужно отказываться вообще от вэлью-типов. Это снимет море проблем.


И потеряем одно интересное св-во. Для вэлью типа логически верно то экземпляр и его копия — это одно и то же. Удобное весьма св-во. Для классического ОО два экземпляра объекта — это как бы означает два разных объекта.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Нет возможности использовать константные ссылки
От: AndreiF  
Дата: 10.11.06 12:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А где-то изменяемый и где-то не изменяемый объект это прямой путь на минное поле.


обоснуй
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: недостатки системы типов .NET
От: AndreiF  
Дата: 10.11.06 12:54
Оценка:
Здравствуйте, vdimas, Вы писали:

V>И потеряем одно интересное св-во. Для вэлью типа логически верно то экземпляр и его копия — это одно и то же. Удобное весьма св-во. Для классического ОО два экземпляра объекта — это как бы означает два разных объекта.


Для этого есть метод Equals. Перегружай его, и сравнивай объекты как тебе нравится.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 10.11.06 12:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


V>>Как определить, что метод не меняет состояние объекта?

WH>Это должно быть свойством типа. Как value типы и reference типы. Также должно быть еще одно измерение mutable типы и imutable типы.
WH>Те объект либо изменяемый либо нет.

Ну вот мы указали, что класс imutable. А он внутри себя пишет в лог. Как в этом случае должен поступить компилятор?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[6]: недостатки системы типов .NET
От: WolfHound  
Дата: 10.11.06 12:59
Оценка:
Здравствуйте, AndreiF, Вы писали:

WH>>И должен он будет работать в глобальном масштабе... Ибо если на тойже виртуальной машине сделать межпроцессное общение типа как в сингулярити...

AF>Подозреваю, что рано или поздно всё к этому и придет.
Те предлогаешь каждый раз когда в системе появляется новый код перекомпилировать всю систему?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: недостатки системы типов .NET
От: prVovik Россия  
Дата: 10.11.06 13:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>>>И должен он будет работать в глобальном масштабе... Ибо если на тойже виртуальной машине сделать межпроцессное общение типа как в сингулярити...

AF>>Подозреваю, что рано или поздно всё к этому и придет.
WH>Те предлогаешь каждый раз когда в системе появляется новый код перекомпилировать всю систему?

ага, мы уже проходили это светлое будущее с шаблонами в С++
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[4]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 13:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>И я о том же. Должны быть изменяемые и не изменяемые объекты.

WH>А где-то изменяемый и где-то не изменяемый объект это прямой путь на минное поле.
Только тут есть одна сложность. По настоящему этим воспользоваться нельзя. Есть unsafe режим которому все эти модификаторы по барабану. В Net постоянно закрывают дырки связанные с этим вопросом. Например в StringBuilder закрыли дырку в том, что он возвращал один и тот же string в разные потоки. Вобщем с unsafe все значительно сложнее.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Нет возможности использовать константные ссылки
От: WolfHound  
Дата: 10.11.06 13:05
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Ну вот мы указали, что класс imutable. А он внутри себя пишет в лог. Как в этом случае должен поступить компилятор?

Зачем imutable классу писать в лог? Он де блин imutable.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 10.11.06 13:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


V>>Ну вот мы указали, что класс imutable. А он внутри себя пишет в лог. Как в этом случае должен поступить компилятор?

WH>Зачем imutable классу писать в лог? Он де блин imutable.

А каким боком запись в лог меняет состояние объекта? К тому же может он пишет в лог только на этапе отладки?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[7]: Нет возможности использовать константные ссылки
От: kan Великобритания  
Дата: 10.11.06 13:19
Оценка:
prVovik wrote:

> V>>Как определить, что метод не меняет состояние объекта?

> WH>Это должно быть свойством типа. Как value типы и reference типы.
> Также должно быть еще одно измерение mutable типы и imutable типы.
> WH>Те объект либо изменяемый либо нет.
>
> Ну вот мы указали, что класс imutable. А он внутри себя пишет в лог. Как
> в этом случае должен поступить компилятор?
Лог — не состояние объекта, это другой объект, объект содержит лишь указатель на него (вот указатель изменить нельзя, но
указуемый объект можно).
В общем, посмотри как с C++ сделано.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: недостатки системы типов .NET
От: WolfHound  
Дата: 10.11.06 13:20
Оценка:
Здравствуйте, prVovik, Вы писали:

WH>>Те предлогаешь каждый раз когда в системе появляется новый код перекомпилировать всю систему?

V>ага, мы уже проходили это светлое будущее с шаблонами в С++
Нет. По сравнению с тем что предлагается шалоны С++ это детский лепет. Ибо предлагают перекомпилировать вобще всеь софт на машине каждый раз когда что-то меняется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 10.11.06 13:21
Оценка:
Здравствуйте, kan, Вы писали:


kan>Лог — не состояние объекта, это другой объект, объект содержит лишь указатель на него (вот указатель изменить нельзя, но

kan>указуемый объект можно).
kan>В общем, посмотри как с C++ сделано.

Да знаю я, как оно там сделано. А вот WolfHound говорит, что запись в лог состояние меняет, так как идет обращение к неконстантному объекту, от которого теоретически может зависеть исходный объект. А вот есть ли реально зависимость, или нет знать может только программист, отсюда и вытекает необходимость костылей вроде консткаста.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[9]: недостатки системы типов .NET
От: prVovik Россия  
Дата: 10.11.06 13:22
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>>>Те предлогаешь каждый раз когда в системе появляется новый код перекомпилировать всю систему?

V>>ага, мы уже проходили это светлое будущее с шаблонами в С++
WH>Нет. По сравнению с тем что предлагается шалоны С++ это детский лепет. Ибо предлагают перекомпилировать вобще всеь софт на машине каждый раз когда что-то меняется.

Суть таже, разница только в масштабах
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[2]: Нет возможности использовать константные ссылки
От: kan Великобритания  
Дата: 10.11.06 13:26
Оценка:
GlebZ wrote:

> OE>о, кстати этот вопрос я тоже пока не догнал, можно поподробнее — есть

> ссылочный тип, есть метод, в который он передается в качестве параметра
> и который его изменять не должен, только читать — как это разруливается
> в C#?
> В С# это никак не обрабатывается. Единственный способ — это вообще не
> создавать методов меняющих внутреннее состояние объекта. Пример того что
> это работает — String.
А как разрулить такую ситуацию?
class User
{
  void setUserName(string name);
  string getUserName() const;
};

class Form
{
  editUser(User *user);      // а вот тут я ожидаю, что может быть изменено что угодно.
  showUser(const User *user);// вызывая этот метод, я ожидаю, что никто ничего в объекте не поменяет.
};
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 13:41
Оценка:
Здравствуйте, kan, Вы писали:

kan>А как разрулить такую ситуацию?

class User
{
  User& setUserName(string name); 
  string getUserName() const;
};

class Form
{
  showUser(editUser(user));// Примерно так
};

При любом изменении создаем новый экземпляр. Ессно при таком подходе важно наличие GC.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 13:51
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Но факт остается фактом: попытка вызвать метод, который меняет состояние, это фактически попытка вызова закрытого в данном контексте метода. Для закрытия методов в зависимости от контекста имеются штатные механизмы. Да, писанины выходит больше, но, зато все очень гибко и понятно. Идея с модификатором, конечно, хороша, но у нее есть один приличный косяк: как определять, меняет ли метод внутреннее состояние объекта, или не меняет? Вот чтобы рещить эту проблему и придется добавлять всякие консткасты, за использование которых джедаи потом "бъют морды".

Косяка тут нет. Определить изменяет ли метод внутреннее состояние, является ли это состояние закрытым — легко. Единственное где можно изменять состояние это конструктор и методы им вызываемые. Для компилятора у которого есть AST с семантикой — это детская задачка.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 10.11.06 14:04
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


V>>Но факт остается фактом: попытка вызвать метод, который меняет состояние, это фактически попытка вызова закрытого в данном контексте метода. Для закрытия методов в зависимости от контекста имеются штатные механизмы. Да, писанины выходит больше, но, зато все очень гибко и понятно. Идея с модификатором, конечно, хороша, но у нее есть один приличный косяк: как определять, меняет ли метод внутреннее состояние объекта, или не меняет? Вот чтобы рещить эту проблему и придется добавлять всякие консткасты, за использование которых джедаи потом "бъют морды".

GZ>Косяка тут нет. Определить изменяет ли метод внутреннее состояние, является ли это состояние закрытым — легко. Единственное где можно изменять состояние это конструктор и методы им вызываемые. Для компилятора у которого есть AST с семантикой — это детская задачка.

Re[6]: Нет возможности использовать константные ссылки
Автор: prVovik
Дата: 10.11.06
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[6]: недостатки системы типов .NET
От: _FRED_ Черногория
Дата: 10.11.06 14:07
Оценка:
Здравствуйте, GlebZ, Вы писали:

kan>>А в каком языке есть const, но нет const_cast?

GZ>Есть понятие mutable/unmutable. Оно в функциональных языках часто присутсвует. Причем unmutable(неизменяемый) — это основной стиль.

Константность объекта и константность ссылки на него — разные вещи. Я подозреваю, что "в функциональных языках" под "unmutable(неизменяемый)" понимают неизменяемость ссылки, а вовсе не данных, на которые она указывает.
... << RSDN@Home 1.2.0 alpha rev. 665>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Re[7]: недостатки системы типов .NET
От: GlebZ Россия  
Дата: 10.11.06 14:19
Оценка:
Здравствуйте, _FRED_, Вы писали:

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


kan>>>А в каком языке есть const, но нет const_cast?

GZ>>Есть понятие mutable/unmutable. Оно в функциональных языках часто присутсвует. Причем unmutable(неизменяемый) — это основной стиль.

_FR>Константность объекта и константность ссылки на него — разные вещи. Я подозреваю, что "в функциональных языках" под "unmutable(неизменяемый)" понимают неизменяемость ссылки, а вовсе не данных, на которые она указывает.

immutable i=10;
mutable i=10;
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 14:19
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Re[6]: Нет возможности использовать константные ссылки
Автор: prVovik
Дата: 10.11.06

И что? Ссылка на класс immutable, сам экземпляр mutable. И еще наверняка singleton. Нормально и без косяков.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 10.11.06 14:30
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


V>>Re[6]: Нет возможности использовать константные ссылки
Автор: prVovik
Дата: 10.11.06

GZ>И что? Ссылка на класс immutable, сам экземпляр mutable. И еще наверняка singleton. Нормально и без косяков.

Можно ли вызывать методы, которые пишут что-то в лог, у объекта по immutable ссылке?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[5]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 14:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>GlebZ wrote:

>> При любом изменении создаем новый экземпляр. Ессно при таком подходе
>> важно наличие GC.
C>А теперь представь, что у тебя сеть объектов. Каждый раз будешь всю сеть
C>клонировать?
Не-а. Тут как раз и есть плюсы такого подхода. Для того чтобы получить другую сеть не обязательно клонировать объекты. Один и тот же объект неизменяем и может лежать в любой подсети. Меняется ведь только ссылка на него.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 14:44
Оценка:
Здравствуйте, prVovik, Вы писали:

V>>>Re[6]: Нет возможности использовать константные ссылки
Автор: prVovik
Дата: 10.11.06

GZ>>И что? Ссылка на класс immutable, сам экземпляр mutable. И еще наверняка singleton. Нормально и без косяков.

V>Можно ли вызывать методы, которые пишут что-то в лог, у объекта по immutable ссылке?

Конечно. А разве в этом есть противоречие? Даже сам объект который пишет в лог может быть immutable
public class Logs
{
    static string fileName;
    public static void WriteLog(string logString)
    {
        using (StreamWriter sw=File.OpenWrite(fileName))
        {
            sw.WriteLine(logString);
        }
    }
}

Данное ограничение ни на временные объекты, ни на файл не накладываются.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Нет возможности использовать константные ссылки
От: kan Великобритания  
Дата: 10.11.06 14:50
Оценка:
GlebZ wrote:

Ок. Представляю себе цирк:
class User
{
   User& setUserName(string name);
   string getUserName() const;
   User& setUserAge(int age);
   ing getUserName() const;
   User& setUserHeight(float age);
   float getUserHeigh() const;
};


User user = new User();
user = user.setUserName("a");
user = user.setUserAge(30);
user = user.setUserHeight(175.2);

Что хорошо в фукнциональнище не всегда хорошо в императивщине.

> При любом изменении создаем новый экземпляр. Ессно при таком подходе

> важно наличие GC.
Объект соответствует записи в субд. Ку?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 14:59
Оценка:
Здравствуйте, kan, Вы писали:

kan>User user = new User();

kan>user = user.setUserName("a");
kan>user = user.setUserAge(30);
kan>user = user.setUserHeight(175.2);
Сколько императивной писанины. Ведь можно в одну строку.
User user=new User().setUserName("a").setUserAge(30).setUserHeight(175.2);// без возврата такое не сделаешь

или
User user=new User("a", 30, 175.2);


kan>Что хорошо в фукнциональнище не всегда хорошо в императивщине.

Никакой проблемы тут нет.

>> При любом изменении создаем новый экземпляр. Ессно при таком подходе

>> важно наличие GC.
kan>Объект соответствует записи в субд. Ку?
И что Ку? Если тебе нужна транзакционность объектов то это на форум Архитектуры. Она обычно делается внешними средствами. К данной проблематике отношение не имеет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Нет возможности использовать константные ссылки
От: kan Великобритания  
Дата: 10.11.06 15:40
Оценка:
GlebZ wrote:

> User user=new User().setUserName("a").setUserAge(30).setUserHeight(175.2);// без возврата такое не сделаешь

Если в set-методах возвращать this, то можно такое писать при желании.
Блин, так и думал что ты это предложишь. Но это тоже костыль, сразу надо было посложнее пример накатать:

User user = new User();
placeOnForm1(user);// отображать текущее состояние объекта, объект туда отдаётся константный.
user.setUserName("a");
placeOnForm2(user);// отображать текущее состояние объекта, объект туда отдаётся константный.
if(weNeedSetAge) user = user.setUserAge(30);
user.invalidate();// обновить отображалки
// (можно делать обновление без этого явного метода, в каждом сеттере, зависит от задачи).
user = user.setUserHeight(175.2);
user.invalidate();// обновить отображалки.

Я прекрасно понимаю, что аналогичный код можно переписать в функциональном стиле, но зачем? Императивныые языки нужны
для того, чтобы писать в императивном стиле. А в этом случае const весьма полезен.

> kan>Что хорошо в фукнциональнище не всегда хорошо в императивщине.

> Никакой проблемы тут нет.
Если на императивном языке пишут в функциональном стиле — это проблема, неправильно выбрали язык.

>> > При любом изменении создаем новый экземпляр. Ессно при таком подходе

>> > важно наличие GC.
> kan>Объект соответствует записи в субд. Ку?
> И что Ку? Если тебе нужна транзакционность объектов то это на форум
> Архитектуры. Она обычно делается внешними средствами. К данной
> проблематике отношение не имеет.
В общем можно, но слишком сфероконично.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[9]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 10.11.06 15:45
Оценка:
Здравствуйте, GlebZ, Вы писали:

V>>>>Re[6]: Нет возможности использовать константные ссылки
Автор: prVovik
Дата: 10.11.06

GZ>>>И что? Ссылка на класс immutable, сам экземпляр mutable. И еще наверняка singleton. Нормально и без косяков.

V>>Можно ли вызывать методы, которые пишут что-то в лог, у объекта по immutable ссылке?

GZ>Конечно. А разве в этом есть противоречие? Даже сам объект который пишет в лог может быть immutable
GZ>
GZ>public class Logs
GZ>{
GZ>    static string fileName;
GZ>    public static void WriteLog(string logString)
GZ>    {
GZ>        using (StreamWriter sw=File.OpenWrite(fileName))
GZ>        {
GZ>            sw.WriteLine(logString);
GZ>        }
GZ>    }
GZ>}
GZ>

GZ>Данное ограничение ни на временные объекты, ни на файл не накладываются.

А на консоль? А на сеть? А на ремотинг? А на WinAPI вызовы? Список можно продолжать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[10]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 16:10
Оценка:
Здравствуйте, prVovik, Вы писали:

V>А на консоль? А на сеть? А на ремотинг?

На здоровье. В remoting ты же получаешь при сериализации — клон, а не сам объект.
V>А на WinAPI вызовы? Список можно продолжать.
Так ведь никто и не предлагал сделать все объекты immutable. Если сделать все объекты таковыми, то получится чисто функциональный язык. А этого никто и не предлагал.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 10.11.06 16:22
Оценка:
Здравствуйте, kan, Вы писали:

kan>Я прекрасно понимаю, что аналогичный код можно переписать в функциональном стиле, но зачем? Императивныые языки нужны

kan>для того, чтобы писать в императивном стиле. А в этом случае const весьма полезен.
Видишь ли, никто и не предлагал отказаться от mutable объектов. В данном случае очень показательны константные строки в C++. Там есть режим компиляции(по моему во многих компиляторах) когда константная строка единая на все приложение. То есть, если ты делаешь:
strcpy(s, "bla");
strcpy(s1, "bla");

строка "bla" указывает на одну и ту же область памяти. И заметь это никому и не мешает. В С# imho immutable технологически это сделать легче. Там так строки уже работают. В C++ вся идея изгажена тем, что константу можно перевести в указатель без константы, и соответсвенно нарушить данное правило.

kan>Если на императивном языке пишут в функциональном стиле — это проблема, неправильно выбрали язык.

Нет. Если ты посмотришь на все введения в императивные языки за последние 5 лет, то все они пришли из функциональных языков. К тому же, например C# особенно трешка, напрямую поддерживает функциональное программирование. Только менее императивным он не стал. Или например, если возьмешь к примеру STL — то это прямая эмуляция функций высшего порядка.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: недостатки системы типов .NET
От: AndreiF  
Дата: 11.11.06 06:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Те предлогаешь каждый раз когда в системе появляется новый код перекомпилировать всю систему?


Ты будешь смеяться, но и в этом может быть смысл. Например, если нужно выжать из системы максимум производительности — в этом случае тотальная кросс-оптимизация всех модулей будет вполне уместна.
В любом случае, код, от которого зависят все остальные модули, меняется не так уж и часто.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Нет возможности использовать константные ссылки
От: AndreiF  
Дата: 11.11.06 11:40
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Не-а. Тут как раз и есть плюсы такого подхода. Для того чтобы получить другую сеть не обязательно клонировать объекты. Один и тот же объект неизменяем и может лежать в любой подсети. Меняется ведь только ссылка на него.


А с чего ты взял, что ссылка на объект только одна?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 11.11.06 11:59
Оценка:
Здравствуйте, AndreiF, Вы писали:

GZ>>Не-а. Тут как раз и есть плюсы такого подхода. Для того чтобы получить другую сеть не обязательно клонировать объекты. Один и тот же объект неизменяем и может лежать в любой подсети. Меняется ведь только ссылка на него.


AF>А с чего ты взял, что ссылка на объект только одна?

Не понял? Ссылок может быть много. Экземпляр объекта один.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[7]: недостатки системы типов .NET
От: FDSC Россия consp11.github.io блог
Дата: 11.11.06 14:07
Оценка:
Здравствуйте, kan, Вы писали:

kan>WolfHound wrote:


>>> > Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.

>> kan>А в каком языке есть const, но нет const_cast?
>> Ты лучше покажи язык кроме С++ где этот самый const_cast есть...
kan>Потому что это единственный (мне известный) язык (не функциональный) где есть const.
kan>Автор вопроса о const явно подразумевал C#, на крайняк CLI, что явно не функциональные языки.

Т.е. кроме C++ ты больше языков и не знаешь? Кроме функциональных...
Re: недостатки системы типов .NET
От: Igor Trofimov  
Дата: 11.11.06 19:11
Оценка:
AF>Нет ни множественного наследования реализаций, ни его заменителей.

+1, непомешала бы автоматизация реализации интерфейса через агрегацию, как это умеет Delphi. Но вообще это не так уж часто нужно.

AF>Нельзя перегружать методы по типу возвращаемого значения.


И как компилятор будет различать, какой метод вызывать, если ты забиваешь на возвращаемое значение или засовываешь его в object ИМХО, нафиг не надо. Ну вот ни разу не сталкивался с такой проблемой.

AF>Нет кортежей.

C# 3.0?

AF>Критически важные системные исключения (OutOfMemoryException, ThreadAbortException, ExecutionEngineException и т.п.) наследуются от того же базового класса, что и частно используемые ArgumentException, NotSupportedException и так далее. Это провоцирует плохих программистов писать конструкции наподобие

AF>catch (Exception) { return false; }

По-моему такое ничто никого не провоцирует писать. Не видел. Не понимаю.
Хотя критические исключения, конечно, стоило бы отделить.

AF>Наличие типов, которые явно обозначаются как передаваемые через стек, и все связанные с этим усложнения системы типов (боксинг) и ограничения (нельзя наследовать от структур). На самом деле, решать, каким образом передавать объект в каждом конкретном случае – это задача оптимизатора.


Не согласен. Более того, там все не так просто, если подумать. Как только ты допускаешь наследование — ты принципиально теряешь возможность размещения объекта в стеке/в теле другого объекта, т.к. размер перестает быть фиксирован.

AF>Просчеты в реализации энумов. Например, любое числовое значение можно привести к любому перечислимому типу, даже если в том нет соответствующего значения, и это не вызовет никакой ошибки во время выполнения. Фактически, целевой переменной перечислимого типа будет присвоено некоторое «неопределенное» значение. No comments.


Это ерунда. Пишешь свой класс с перечислением по аналогии и все. Можно туда еще методов любых напихать, будет как в JDK 1.5

AF>Коллекции

AF>Одновременное применение в системе типов .NET массивов, нетипизированных коллекций, специализированных коллекций и генерик-коллекций, которые все «немного похожи» и «немного разные». Соответственно, методы из FCL возвращают разные типы — это создает лишнюю путаницу и сложности при программировании.

Это обратная совместимость Куда деваться?

AF>Для массивов возможна ко/контра-вариантность элементов, для остальных коллекций – нет. Массивы можно инициализировать списком значений в коде, для коллекций это невозможно.


AF>Большинство коллекций поддерживают возможность добавлять элементы без пересоздания объекта, для массивов эта возможность недоступна. Для большинства коллекций доступен метод AsReadOnly() или аналог, для массивов такой возможности нет.


Это нормально.

AF>Генерики

AF>Много лишней писанины, если нужно создать систему из нескольких связанных типов, имеющих общие параметры.

Можно подробнее?

AF>Нельзя использовать Enum в качестве констрэйнта на тип.


Еще странные ограничения generics: CBO, Attribute, Delegate.
И очень не хватает авто-интерфейсов-враперов, чтобы можно было использовать в качестве параметров generic'ов типы, которые создавались без оглядки на generics.
Re[5]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.06 19:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Ради справедливости надо заметить, что тогда по уму нужно отказываться вообще от вэлью-типов. Это снимет море проблем.

WH>Каких проблем?

Коваринтность будет доступна почти везде. Можно будет отказаться от боксинга. Упростится модель абстракйий. В общем, много чего упростится. А компилятор может скомпенсировать потери в производительности.

В общем, я считаю, что когда-то, когда уровень рантаймов и компиляторов выростет до невероятных высот такой дизайн будет самым верным (собственно дизайн Смолтока, от части). Но на время выпуска первого фрэймворка выбор МС был конечно оправдан.

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

WH>И должен он будет работать в глобальном масштабе...

Джит уже работает в глобальном масштабе, если таковым считать масштаб процесса.

WH>Ибо если на тойже виртуальной машине сделать межпроцессное общение типа как в сингулярити...


И что будет? Все будет ОК. Там взаимодействие ведется неизменяемыми типами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.06 19:51
Оценка:
Здравствуйте, vdimas, Вы писали:

V>И потеряем одно интересное св-во. Для вэлью типа логически верно то экземпляр и его копия — это одно и то же. Удобное весьма св-во. Для классического ОО два экземпляра объекта — это как бы означает два разных объекта.


Не потеряем. Семантика вэлю-типов отлично эмулируется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.06 19:51
Оценка:
Здравствуйте, kan, Вы писали:

kan>А в каком языке есть const, но нет const_cast?


Вольфхаунд прав. const_cast — это бред придуманный только в С++.

В других языках обычно и const нет. Вместо этого там просто есть неизменяемые переменные. Более того есть зыки в которых все переменные не изменяемые (Хаскель, например).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.06 19:51
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Пардон, и правда ошибся. Просто в первой версии этого не было.

AF>Странно только, зачем они сделали этот метод у массивов статическим.

Потому-что массив на самом деле не объект, а встроенный тип данных. Но в конкретном ЯП можно было бы это и скрыть. В C# 1-2 не скрыли. В трешке будут методы расширения и на них можно будет все поправить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.06 02:26
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Так неизменяемые переменные не нужны, а нужен контекст, в котором

C>нельзя изменять объекты.

Это ты сказал не подумав.

C>На самом деле, const — это один простейших типов программирования по

C>контракту. Модификатором 'const' мы обозначаем, что метод не меняе
C>инвариант класса.

const в С++ используется для разных целей. Собственно это и приводит к путаннице.
Не спорю идея пометки тел методов как неизменяемых — хорошая идея. Но идеи неизменяемых переменных это не отменяет.

C>Как раз стоило бы развить эту идею для большего статического контроля

C>правильности программы. Или ты против статического контроля?

Не против. Но хотелось бы, чтобы пометка метода как неизменяющего состояние класса гарантировало бы это на сто процентов. А вот в С++ такой гарантии нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Нет возможности использовать константные ссылки
От: AndreiF  
Дата: 12.11.06 06:21
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Не понял? Ссылок может быть много. Экземпляр объекта один.


Всё очень просто. Если у тебя есть объекты, которые образуют граф, то ты не можешь скопировать один из объектов в отдельности. В частном случае это бывает возможно, но в общем случае — нет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: недостатки системы типов .NET
От: AndreiF  
Дата: 12.11.06 06:21
Оценка:
Здравствуйте, Igor Trofimov, Вы писали:

AF>>Генерики

AF>>Много лишней писанины, если нужно создать систему из нескольких связанных типов, имеющих общие параметры.

iT>Можно подробнее?


Очень упрощенный пример (на самом деле там должна быть еще куча разных методов и пропертей)
        public class EpsTransition
        {
            public State Target;
        }

        public class Transition
        {
            public char Token;
            public State Target;
        }

        public class State
        {
            public List<EpsTransition> EpsTransitions = new List<EpsTransition>();
            public List<Transition> Transitions = new List<Transition>();
        }

        public class StateMachine
        {
            public State EntryPoint;
            public List<State> States = new List<State>();
        }

А теперь пробуем сделать очень простую вещь — заменить тип Transition.Token, вместо char сделать параметризованный тип.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: недостатки системы типов .NET
От: Cyberax Марс  
Дата: 12.11.06 13:18
Оценка:
VladD2 wrote:
> C>Так неизменяемые переменные не нужны, а нужен *контекст*, в котором
> C>нельзя изменять объекты.
> Это ты сказал не подумав.
Я имею в виду, что не нужны для тех целей, для которых используется const.

> Не спорю идея пометки тел методов как неизменяемых — хорошая идея. Но

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

> C>Как раз стоило бы развить эту идею для большего статического контроля

> C>правильности программы. Или ты против статического контроля?
> Не против. Но хотелось бы, чтобы пометка метода как неизменяющего
> состояние класса гарантировало бы это на сто процентов. А вот в С++
> такой гарантии нет.
Есть мнение, что 100% гарантия не очень нужна. Сейчас посмотрел свой код
— на 4Мб исходников на С++ приходится 120 const_cast'ов. Примерно
половину из них можно убрать без всяких проблем (там они просто
сберегают несколько строк кода), еще часть можно было бы убрать, если
хорошо подумать. Но вот что делать с остальными — непонятно.

Так что я лучше буду жить с не-100%-ной гарантией, что объект не
изменится в const-методе или через const-ссылку.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[9]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 12.11.06 15:05
Оценка:
Здравствуйте, kan, Вы писали:

kan>Так разговор идёт о const — позволяет делать что-то типа мутабельности (но не совсем её) на уровне методов, притом

kan>проверка compile-time (!), а не "as documented". Как в C# узнать, что данный объект немутабельный? Правильно — залезть в
kan>документацию (если она есть, иначе — сорцы, если они есть, иначе — вешаться) и прочитать. Больше никак. Как узнать, что
kan>данный метод можно вызвать без клонирования объекта, дабы чьи-нибудь данные не попортить? Правильно — залезть в
kan>сорцы/документацию. Больше никак.
kan>А если вдруг какой-нибудь метод изменили и он стал изменять состояние? Старый код об этом никак не узнает.
Это не свойство ссылки как в С++. Это свойство типа. Мы же не возмущаемся что unsigned int кто-то может перебить как signed int,

>> случае очень показательны константные строки в C++. Там есть режим

kan>Не понял что этот пример показывает... просто оптимизация, сташвая возможной, благодая нестрогости стандарта.
Нет. Это эквивалентность.

>> нарушить данное правило.

kan>Нет, идея С++ в том, что он небезопасный — можно нарушить любое правило.
Это не идея C++. Это проблема С++. Нельзя ни в чем быть увереным, и чаще короткий путь — путь нарушения контракта.

kan>Как именно поддерживает? Чем эта поддержка принципиально отличается от C++? Можно ссылку.

MSDN.

kan>Мягко говоря, не очень... скорее тут "виноваты" шаблоны, stl не при чём, а это исчисление типов, метапрограммирование.

Советую проникнуться что такое функциональное программирование и что эмулирует функтор.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[9]: недостатки системы типов .NET
От: GlebZ Россия  
Дата: 12.11.06 15:30
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

GZ>>
GZ>>immutable i=10;
GZ>>mutable i=10;
GZ>>


АХ>Во-первых ключевого слова immutable в Nemerle нет (все по умолчанию immutable), пишут просто

Пришлось жертвовать ради наглядности.

АХ>А во-вторых FR говорил вот про что:

АХ>
АХ>[Record]
АХ>class A
АХ>{
АХ>  public mutable x : int;

АХ>  public static Main() : void
АХ>  {
АХ>    def a1 = A(1);
        
АХ>        //a1 = A(2);  // ошибка компиляции - a1 неизменяемая!
АХ>    a1.x = 5;            // a объект на который она указывает - изменяемый!
    
АХ>    System.Console.WriteLine($"a1.x = $(a1.x)"); // выдает "a1.x = 5"
АХ>  }
АХ>}
АХ>

Нехороший стиль.

АХ>В С++ можно действовать более гибко, хотя больше писанины:

А теперь оказывается что нельзя быть увереным что объект не изменяется. Нарушать это правило может как другой код, написанный другим программистом. А в случае многопоточки вообще нехорошо получается. В immutable типе размывается понятие value — reference типа при передаче в функцию. В случае если у компилятора доступна информация о том, что объект не будет изменяться он его может передавать как по ссылке, так и по значению. И вообще более часто задействовать редукцию/инлайнинг.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[9]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.06 15:32
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я имею в виду, что не нужны для тех целей, для которых используется const.


Еще раз повторюсь — const в С++ используется для разных вещей. Это перегруженное ключевое слово.

C>Естественно, иммутабельные переменные, в частности, значительно упрощают

C> многопоточное программирование.

Это пока только на словах. А в реальной жизни они позволяют количество место в которыхз может появиться ошибока.
Разумно вообще стараться не использовать изменяемые переменные если на то нет реальной необхдимости.

C>Есть мнение, что 100% гарантия не очень нужна.


Я бы все же желал иметь больше гарантий. Гарантии не всегда достижимы, но всегда хочется их иметь.

C> Сейчас посмотрел свой код

C>- на 4Мб исходников на С++ приходится 120 const_cast'ов.

Дык, это же твой код на С++. А ты посмотри мой код на Nemerle:
http://nemerle.org/svn/vs-plugin/trunk/Nemerle.Compiler.Utils
Там как раз mutable встречается намного реже чем неизменяемые переменные. А const_cast нет в принцие, так как язык типобезопасный.

C>Примерно

C>половину из них можно убрать без всяких проблем (там они просто
C>сберегают несколько строк кода), еще часть можно было бы убрать, если
C>хорошо подумать.

Вот ивдишь? А каждый const_cast — это потенциальная ошибка.

C>Но вот что делать с остальными — непонятно.


И как же в других то языках получается без него писать? Загадка ветка.

C>Так что я лучше буду жить с не-100%-ной гарантией, что объект не

C>изменится в const-методе или через const-ссылку.

Давай. А я лучше буду жить без кривого и запутанного С++.
Хотя согласен, что идея помечать методы (да и классы) как неизменяемые — это хорошая идея. И надо будет ее реализовать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Нет возможности использовать константные ссылки
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.06 15:32
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Ну вот мы указали, что класс imutable. А он внутри себя пишет в лог. Как в этом случае должен поступить компилятор?


Очевидно должна быть возможность пометить любой метод как безопасный с точки зрения инварианта типов программы. Так что методы вывода на консоль надо просто пометить таким атрибутом и компилятор будет пропускать его.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: недостатки системы типов .NET
От: Cyberax Марс  
Дата: 12.11.06 15:53
Оценка:
VladD2 wrote:
> C>Я имею в виду, что не нужны для тех целей, для которых используется const.
> Еще раз повторюсь — const в С++ используется для разных вещей. Это
> *перегруженное* ключевое слово.
Не перегружено. Разве что для констант можно было final добавить.

"const" обозначает константные переменные и функции, работающие в
константном контексте. Из константного контекста все переменные (за
исключением mutable) видные тоже как константные.

В С++ном const'е разве что сложны правила его распространения (т.е.
разница между const char* и char const *).

Где тут перегруженность?

> C>Есть мнение, что 100% гарантия не очень нужна.

> Я бы все же желал иметь больше гарантий. Гарантии не всегда достижимы,
> но всегда хочется их иметь.
Только вот стопроцентные гарантии часто встают боком, когда их все-таки
надо нарушить.

Мое ИМХО — нужно делать так, чтобы гарантии МОЖНО было нарушать, но
чтобы это требовало явных требований со стороны программиста.

> C> Сейчас посмотрел свой код

> C>- на 4Мб исходников на С++ приходится 120 const_cast'ов.
> Дык, это же *твой* код на *С++*. А ты посмотри мой код на Nemerle:
> http://nemerle.org/svn/vs-plugin/trunk/Nemerle.Compiler.Utils
> Там как раз mutable встречается намного реже чем неизменяемые
> переменные. А const_cast нет в принцие, так как язык типобезопасный.
Некорректно сравнивать разные языки. Вот мне лично в C#/Java мешает
иммутабельность строк.

> C>Примерно

> C>половину из них можно убрать без всяких проблем (там они просто
> C>сберегают несколько строк кода), еще часть можно было бы убрать, если
> C>хорошо подумать.
> Вот ивдишь? А каждый const_cast — это потенциальная ошибка.
Бери выше, каждый оператор — потенциальная ошибка. Как раз в случае с
const_cast'ом весьма легко найти потенциальные места ошибок — запустив
поиск по нему.

> C>Но вот что делать с остальными — непонятно.

> И как же в других то языках получается без него писать? Загадка ветка.
Так самый простой вариант — убрать все const. Тогда не нужны будут и
const_cast'ы, но вот только потеряется некоторая доля безопасности.

> C>Так что я лучше буду жить с не-100%-ной гарантией, что объект не

> C>изменится в const-методе или через const-ссылку.
> Давай. А я лучше буду жить без кривого и запутанного С++.
> Хотя согласен, что идея помечать методы (да и классы) как неизменяемые —
> это хорошая идея. И надо будет ее реализовать.
А что это даст?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[3]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.06 19:08
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Странно только, зачем они сделали этот метод у массивов статическим.


Как раз очень правильно. Потому что утилитный метод лучше делать статическим. Если же тебе просто хочется синтаксиса с точкой, то C# 3 этому горю поможет.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[4]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.06 19:30
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>
VD>interface ICloneable<T>
VD>{
VD>    T Clone();
VD>}

VD>class Test : ICloneable<Test>
VD>{
VD>  public Test Clone() // OK
VD>    {
VD>    ...
VD>    }
VD>}
VD>


Тут попа. ICloneable обычно используется как кто так:
object EditValue(object value)
{
    ICloneable cln = value as ICloneable;
    object editValue = cln != null ? cln.Clone : CloneUtils.CloneViaSerialization(value);
    using (EditForm ef = new EditForm(editValue))
        if (ef.ShowDialog() == DialogResult.OK)
            return editValue;
    return value;
}

Т.е., по сути, ICloneable это такой аналог ISerializable.
Провернуть аналогичный финт ушами с ICloneable<T> конечно можно, но, мягко говоря, не тривиально. Поэтому, кстати, IEnumerable<T> наследуется от IEnumerable.
Не очень красиво, конечно. Но альтернативой, навскидку, мне видится разве что ковариантность дженерик-интерфейсу по type parameter, чтобы ICloneable<SomeObject> можно было прокастить к ICloneable<object>, но это невозможно из-за логических нестыковок (разное направление ковариантности для in и out параметров членов).
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[3]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.06 19:30
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Чушь.

AF>
AF>// made by Vasya
AF>class Document : IDisposable
AF>{
AF>....
AF>}

AF>// made by Petya
AF>static class Printer
AF>{
AF>  public static Print(Document doc)
AF>    {
AF>      ...
AF>        doc.Dispose(); // опа!
AF>    }
AF>}
AF>

AF>Ну так что, документ он какой — изменяемый или неизменямый?

Тут, вобще то, архитектурная больше проблема, а не проблема реализации. Обычно в таких случаях делают read only интерфейс IDocument, и его реализацию с возможностью модификации. Одну из реализаций. А другую, вполне возможно, и без таковой.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[5]: Нет возможности использовать константные ссылки
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.06 19:55
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Только тут есть одна сложность. По настоящему этим воспользоваться нельзя. Есть unsafe режим которому все эти модификаторы по барабану.


А есть рефлекшен, которому по барабану модификаторы доступа. И что, это делает бесполезным эти модификаторы?
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[6]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 12.11.06 20:28
Оценка:
Здравствуйте, AndrewVK, Вы писали:

GZ>>Только тут есть одна сложность. По настоящему этим воспользоваться нельзя. Есть unsafe режим которому все эти модификаторы по барабану.

AVK>А есть рефлекшен, которому по барабану модификаторы доступа. И что, это делает бесполезным эти модификаторы?
Нет, конечно. Но в данном случае поведение нельзя спрогнозировать. Например почему прикрыли генерацию нескольких строк в StringBuilder

But earlier implementations of StringBuilder actually exposed a security hole when used in this manner. It was possible to create mutable strings, where the result of StringBuilder.ToString could be modified. This was a huge security hole and it was fixed.


здесь
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[7]: Нет возможности использовать константные ссылки
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.06 20:31
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Например почему прикрыли генерацию нескольких строк в StringBuilder

GZ>

GZ>But earlier implementations of StringBuilder actually exposed a security hole when used in this manner. It was possible to create mutable strings, where the result of StringBuilder.ToString could be modified. This was a huge security hole and it was fixed.


Это из другой оперы.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[7]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 12.11.06 23:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вот тебе ситуация, объекты А и Б циклически связаны друг с другом:

Это плохо. Нелюблю такого, особенно если нет GC.
C>
C>struct A
C>{
C>     B *b;
C>};
C>struct B
C>{
C>     A *a;
C>};
C>


C>Если я создаю новый A, оставив у него ссылку на старый объект, то

C>получится интересная ситуация:
C>
C>A *oldA;
C>A *newA=doSomething(oldA);

C>assert(newA->b->a == newA); //WTF?????
C>


C>Чтобы ее разрулить нужно будет клонировать еще и объект B. Ну и все

C>связаные с ним объекты.
Да уж. Нехорошо. Обычно такие вещи сравнивают с помощью идентификатора.
Давай я покажу о чем я:
Давай сделаем аналогию работающую на функц. языках. Допустим задача:
Есть список объектов в котором каждый второй мы должны поменять с третьей, а после этого каждый первый с четвертым. Список имеет конструктор и три функции функции — Current(), Next(), Append(). Пишу на императивном псевдоязыке похожем на С++(чтобы было понятно всем).
list<obj> a={...}
list<obj> b=Multiply2(ChangePos23(a))
где
list<obj> ChangePos23(list<obj> a)
{
    obj& l;
    int i=0;
    list<obj> resChange=new list<obj>();
    while (a.Current()!=null)
    {
        if (i%2)
            tmp=a.Current();
        else
        if (i%3)
        { resChange.append(a.Current());
            resChange.append(l);
        }
        else
            resChange.append(a.Current());
        i++;
        a.Next();
    }
}
list<obj> Multiply2(list<obj> a)
{
    list<obj> resMult=new list<obj>();
    while (a.Current()!=null)
    {
        if (a.Current()<10)
            resMult.append(a.Current()*2);
        else
            resMult.append(a.Current());
        j++;
        a.Next();
    }
}

Чудненько и прекрасно если не считать что мы генерим каждый раз новый список. Поэтому сделаем некоторую перетрубацию, заменив в ChangePos32 append() на тело цикла в Mult2less10 и получим эквивалентный код.
list<obj> GetResult(list<obj> a)
{
    obj& l;
    int i=0;
    list<obj> res=new list<obj>();
    while (a.Current()!=null)
    {
        if (i%2)
            tmp=a.Current();
        else
        if (i%3)
        { 
            if (a.Current()<10)
                res.append(a.Current()*2);
            else
                res.append(a.Current());
            if (l<10)
                res.append(l*2);
            else
                res.append(l);
        }
        else
        {
            if (a.Current()<10)
                res.append(a.Current()*2);
            else
                res.append(a.Current());
        }
        i++;
        a.Next();
    }
}

Ну и немного подсократим вышеописанное:
void AppendResult(list<obj>& list, obj& value)
{
    if (value<10) res.append(value*2);
    else res.append(value);
}
list<obj> GetResult(list<obj> a)
{
    obj& l;
    int i=0;
    list<obj> res=new list<obj>();
    while (a.Current()!=null)
    {
        if (i%2)
            tmp=a.Current();
        else
        if (i%3)
        { 
            AppendResult(res, a.Current());
            AppendResult(res, l);
        }
        else
            AppendResult(res, a.Current());
        i++;
        a.Next();
    }
}

И код сократился и получилось что нам не понадобились промежуточные списки. И кстати, если провести аналогию до получения конечного результата, то здесь могут вообще списки не генериться. Например понадобилось на получить сумму списка, то будет:
sum AppendResult(obj sum, obj& value)
{
    if (value<10) return sum+value*2;
    else sum+value;
}
list<obj> GetResult(list<obj> a)
{
    obj& l;
    int i=0;
    obj res=0;
    while (a.Current()!=null)
    {
        if (i%2)
            tmp=a.Current();
        else
        if (i%3)
        { 
            res=AppendResult(res, a.Current());
            res=AppendResult(res, l);
        }
        else
            res=AppendResult(res, a.Current());
        i++;
        a.Next();
    }
}

То есть копирование списка как такового не понадобилось.
В данном случае мы обыграли случай транзитивности операций. Это правда не всегда возможно. Но данный подход вполне подходит и для деревьев и для графов. Просто если помнить что доступ нужно осуществлять через функциональные итераторы, то такие уравнения строятся на ура. В чистых функциональных языках такие оптимизации делаются автоматически. Но для них важно быть immutable и побочные эффекты. Если внутренний объект изменится в результате выполнения функции — то теряется вся математика, и в том числе свойства транзитивности во многих операциях.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[11]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.06 01:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>Я имею в виду, что не нужны для тех целей, для которых используется const.

>> Еще раз повторюсь — const в С++ используется для разных вещей. Это
>> *перегруженное* ключевое слово.
C>Не перегружено. Разве что для констант можно было final добавить.

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

>> Хотя согласен, что идея помечать методы (да и классы) как неизменяемые —

>> это хорошая идея. И надо будет ее реализовать.
>А что это даст?

Возможность гарантировать, что метод не изменяет объект. Плюс в будущем компилятор может учитывать эти атрибуты чтобы автоматически распараллеливать код.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.06 01:14
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Тут попа. ICloneable обычно используется как кто так:

AVK>
AVK>object EditValue(object value)
AVK>{
AVK>    ICloneable cln = value as ICloneable;
AVK>    object editValue = cln != null ? cln.Clone : CloneUtils.CloneViaSerialization(value);
AVK>    using (EditForm ef = new EditForm(editValue))
AVK>        if (ef.ShowDialog() == DialogResult.OK)
AVK>            return editValue;
AVK>    return value;
AVK>}
AVK>

AVK>Т.е., по сути, ICloneable это такой аналог ISerializable.

Может для тебя это и обычно. Я вообще с object-ами не работаю. И для меня это не обычно. А вот типизированный Clone использовал часто.

AVK>Провернуть аналогичный финт ушами с ICloneable<T> конечно можно, но, мягко говоря, не тривиально. Поэтому, кстати, IEnumerable<T> наследуется от IEnumerable.


Он для совместимости наследуется. Лично я вообще не применяют IEnumerable.

AVK>Не очень красиво, конечно.


Почему не красиво? Вполне нормально. Все зависит от программиста. Не захочет он с обжектами возиться и не будет.

AVK> Но альтернативой, навскидку, мне видится разве что ковариантность дженерик-интерфейсу по type parameter, чтобы ICloneable<SomeObject> можно было прокастить к ICloneable<object>, но это невозможно из-за логических нестыковок (разное направление ковариантности для in и out параметров членов).


Самое смешное, что коваринтности интерфейсов нет только в Шарпе. Дотнет ее поддерживает. Но в твоем случае это безтолку. Тут дизайн приложения надо менять. Обжекты выбрасывать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 03:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Тут, вобще то, архитектурная больше проблема, а не проблема реализации. Обычно в таких случаях делают read only интерфейс IDocument, и его реализацию с возможностью модификации. Одну из реализаций. А другую, вполне возможно, и без таковой.


Это то же самое, что и константная ссылка на объект, только вручную.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 03:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Как раз очень правильно. Потому что утилитный метод лучше делать статическим.


А почему тогда у List<T> его сделали экземплярным?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: недостатки системы типов .NET
От: prVovik Россия  
Дата: 13.11.06 07:23
Оценка:
Здравствуйте, AndreiF, Вы писали:

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


AVK>>Тут, вобще то, архитектурная больше проблема, а не проблема реализации. Обычно в таких случаях делают read only интерфейс IDocument, и его реализацию с возможностью модификации. Одну из реализаций. А другую, вполне возможно, и без таковой.


AF>Это то же самое, что и константная ссылка на объект, только вручную.


Зато все явно и гибко.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[6]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 07:43
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Зато все явно и гибко.


И там тоже явно и гибко, только не надо каждый раз закатывать солнце вручную.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: недостатки системы типов .NET
От: prVovik Россия  
Дата: 13.11.06 08:02
Оценка:
Здравствуйте, AndreiF, Вы писали:

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


V>>Зато все явно и гибко.


AF>И там тоже явно и гибко...


Ну да, ну да, const_cast'ы рулят!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[3]: недостатки системы типов .NET
От: WolfHound  
Дата: 13.11.06 08:24
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Очень упрощенный пример (на самом деле там должна быть еще куча разных методов и пропертей)

хъ
AF>А теперь пробуем сделать очень простую вещь — заменить тип Transition.Token, вместо char сделать параметризованный тип.
Легко
    public class StateMachine<T>
    {
        public class EpsTransition
        {
            public State Target;
        }
        
        public class Transition
        {
            public T Token;
            public State Target;
        }
        
        public class State
        {
            public List<EpsTransition> EpsTransitions = new List<EpsTransition>();
            public List<Transition> Transitions = new List<Transition>();
        }
        
        public State EntryPoint;
        public List<State> States = new List<State>();
    }
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 13.11.06 08:55
Оценка:
Здравствуйте, GlebZ, Вы писали:


GZ>Давай сделаем аналогию работающую на функц. языках. Допустим задача:

GZ>Есть список объектов в котором каждый второй мы должны поменять с третьей, а после этого каждый первый с четвертым.
Обшибочка. Пока писал немного изменил задачу. Поздно было. Читать каждый второй поменять с третьим местами и каждый объект меньший десяти домножить на два.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[12]: недостатки системы типов .NET
От: kan Великобритания  
Дата: 13.11.06 09:45
Оценка:
VladD2 wrote:

>> > C>Я имею в виду, что не нужны для тех целей, для которых используется

> const.
>> > Еще раз повторюсь — const в С++ используется для разных вещей. Это
>> > *перегруженное* ключевое слово.
> C>Не перегружено. Разве что для констант можно было final добавить.
> const используется для объявления констант, не изменяемых переменных и
А чем константа отличается от неизменяемой переменной в данном случае?

> пометки методов признаком неизменения состояния объекта. Спорить с этим

> глупо. Извини, но доказывать тебе очевидные прописные истины у меня
> времени нет.
Объявление константного метода, это по сути приписывание const "скрытой" переменной this. Так что в точности тоже самое.

>> > Хотя согласен, что идея помечать методы (да и классы) как неизменяемые —

>> > это хорошая идея. И надо будет ее реализовать.
>>А что это даст?
> Возможность гарантировать, что метод не изменяет объект. Плюс в будущем
> компилятор может учитывать эти атрибуты чтобы автоматически
> распараллеливать код.
Насчёт распараллеливания не уверен, но вот для оптимизации точно можно.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: недостатки системы типов .NET
От: Cyberax Марс  
Дата: 13.11.06 09:50
Оценка:
VladD2 wrote:
> C>Не перегружено. Разве что для констант можно было final добавить.
> const используется для объявления констант, не изменяемых переменных и
> пометки методов признаком неизменения состояния объекта.
И что? Называть это "перегруженостью" я бы не стал.

Ну замени "const" для методов на "immutable" — что от этого лучше станет?

>> > Хотя согласен, что идея помечать методы (да и классы) как неизменяемые —

>> > это хорошая идея. И надо будет ее реализовать.
>>А что это даст?
> Возможность гарантировать, что метод не изменяет объект. Плюс в будущем
> компилятор может учитывать эти атрибуты чтобы автоматически
> распараллеливать код.
Распараллелить автоматически можно (иногда) только если выполняются
одновременно два немутирующих метода. Да и то не всегда.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[9]: Нет возможности использовать константные ссылки
От: kan Великобритания  
Дата: 13.11.06 10:03
Оценка:
GlebZ wrote:

> Читать каждый

> второй поменять с третьим местами и каждый объект меньший десяти
> домножить на два.
Я честно говоря, не понял, как это отвечает на вопрос Киберакса.
Арифметика это здорово. Но реальный мир банальнее. Представь себе 2 объекта: Client/Address. Они ссылаются друг на
друга. У них есть свойства Client.Name, Client.Age, Address.House, Address.Country.
И вот на одной форме юзер подредактировал данные клиента, на другой данные адреса. Что где склонируется и почему?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: Нет возможности использовать константные ссылки
От: Cyberax Марс  
Дата: 13.11.06 10:08
Оценка:
GlebZ wrote:
> То есть копирование списка как такового не понадобилось.
На ленивых списках это бы еще красивее смотрелось. Ты фактически просто
строил бы функциональные виды над списком.

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

С навигационным доступом тоже будут проблемы — так как после пары-тройки
изменений у тебя при каждом обращении оно будет проходить через
несколько списков. Кэширование поможет, но тогда уж проще будет
скопировать граф.

Ну и мелочи — графовые алгоритмы часто и так уже сложны, так что как
сделать их в виде функциональных итераторов может быть задачей для
диссертации.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: Нет возможности использовать константные ссылки
От: kan Великобритания  
Дата: 13.11.06 10:18
Оценка:
GlebZ wrote:

> kan>сорцы/документацию. Больше никак.

> kan>А если вдруг какой-нибудь метод изменили и он стал изменять
> состояние? Старый код об этом никак не узнает.
> Это не свойство ссылки как в С++. Это свойство типа. Мы же не
> возмущаемся что unsigned int кто-то может перебить как signed int,
Согласен. Однажды созданный final тип должен остаться им навечно. Просто в С++ это не проблема, если какой-то метод из
константного поменять в неконстантный, то код, который рассчитывал на константность — не скомпилится.

>> > случае очень показательны константные строки в C++. Там есть режим

> kan>Не понял что этот пример показывает... просто оптимизация, сташвая
> возможной, благодая нестрогости стандарта.
> Нет. Это эквивалентность.
Подробнее можно? Особенно как в данном случае это можно распространять на непримитивные типы, которые могут ссылаться на
другие объекты.

>> > нарушить данное правило.

> kan>Нет, идея С++ в том, что он небезопасный — можно нарушить любое правило.
> Это не идея C++. Это проблема С++. Нельзя ни в чем быть увереным, и чаще
> короткий путь — путь нарушения контракта.
Кто не понимает этой идеи, видит в этом проблему?

> kan>Как именно поддерживает? Чем эта поддержка принципиально отличается

> от C++? Можно ссылку.
> MSDN.
Спасибо, что не гугл.
Намекну по-другому. А на каком языке нельзя программировать в функциональном стиле?

> kan>Мягко говоря, не очень... скорее тут "виноваты" шаблоны, stl не при

> чём, а это исчисление типов, метапрограммирование.
> Советую проникнуться что такое функциональное программирование и что
> эмулирует функтор.
Ключевое слово "эмулирует". Иначе, благодаря наличию boost::lambda, можно С++ смело называть функциональным.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: недостатки системы типов .NET
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.11.06 11:10
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Т.е., по сути, ICloneable это такой аналог ISerializable.
AVK>Провернуть аналогичный финт ушами с ICloneable<T> конечно можно, но, мягко говоря, не тривиально. Поэтому, кстати, IEnumerable<T> наследуется от IEnumerable.
Совершенно верно. Поэтому имеет смысл ICloneable<T> отнаследовать от ICloneable — для работоспособности в нетипизированных сценариях, подобных приведенному тобой.
AVK>Не очень красиво, конечно. Но альтернативой, навскидку, мне видится разве что ковариантность дженерик-интерфейсу по type parameter, чтобы ICloneable<SomeObject> можно было прокастить к ICloneable<object>, но это невозможно из-за логических нестыковок (разное направление ковариантности для in и out параметров членов).
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.11.06 11:14
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Может для тебя это и обычно. Я вообще с object-ами не работаю. И для меня это не обычно.


Это не вопрос того, с чем ты работаешь. Это кусок кода для поддержки компонентной модели дотнета. И тип объекта там на этапе компиляции неизвестен принципиально.

VD> А вот типизированный Clone использовал часто.


Типизированный Clone это без проблем. Речь о типизированном ICloneable<T>. Вот в нем смысла не очень много, разве что в качестве контрейнта для другого дженерика.

VD>Почему не красиво? Вполне нормально. Все зависит от программиста. Не захочет он с обжектами возиться и не будет.


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

VD>Самое смешное, что коваринтности интерфейсов нет только в Шарпе. Дотнет ее поддерживает. Но в твоем случае это безтолку. Тут дизайн приложения надо менять. Обжекты выбрасывать.


Ну выброси обжекты в UITypeEditor
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[5]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.11.06 11:24
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Это то же самое, что и константная ссылка на объект, только вручную.


Нет, не то же самое. Главное отличие того, что предлагается в шарпе, от того, что есть в С++, это местоположение ответственности. В случае плюсового const ответственность несет вызываемая сторона, в случае immutable в шарпе — вызываемая. Говорить о том, какой вариант лучше, вот так навскидку я не берусь. На первый взгляд шарповский вариант все же пологичнее.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[6]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.11.06 11:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Совершенно верно. Поэтому имеет смысл ICloneable<T> отнаследовать от ICloneable — для работоспособности в нетипизированных сценариях, подобных приведенному тобой.


Но в таком раскладе вернемся к тому, от чего пытались уйти — придется делать две реализации одного и того же метода — типизированную и нетипизированную.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[10]: недостатки системы типов .NET
От: _FRED_ Черногория
Дата: 13.11.06 11:45
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>А теперь оказывается что нельзя быть увереным что объект не изменяется. Нарушать это правило может как другой код, написанный другим программистом. А в случае многопоточки вообще нехорошо получается. В immutable типе размывается понятие value — reference типа при передаче в функцию. В случае если у компилятора доступна информация о том, что объект не будет изменяться он его может передавать как по ссылке, так и по значению. И вообще более часто задействовать редукцию/инлайнинг.


Давай-ка расставим всё по своим местам

Вроде говорили
Автор: kan
Дата: 10.11.06
о константности состояния объекта (константности методов, к которой имеет отношение const_cast<>). Так ведь?

И тут ты упомянул
Автор: GlebZ
Дата: 10.11.06
про "mutable/unmutable", которые, как я заметил
Автор: _FRED_
Дата: 10.11.06
, применяются не к методам, а к переменным, что имеет совсем другой смысл, как разъяснили
Автор: Андрей Хропов
Дата: 11.11.06
. Верно?

А здесь вот, вообще, говоришь об "immutable типе" И вот причём же здесь mutable/def переменные Nemerle

Как-то никакой нити логической не заметно
... << RSDN@Home 1.2.0 alpha rev. 665>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Re[13]: недостатки системы типов .NET
От: kan Великобритания  
Дата: 13.11.06 11:55
Оценка:
Cyberax wrote:

>> Возможность гарантировать, что метод не изменяет объект. Плюс в будущем

>> компилятор может учитывать эти атрибуты чтобы автоматически
>> распараллеливать код.
> Распараллелить автоматически можно (иногда) только если выполняются
> одновременно два немутирующих метода. Да и то не всегда.
Можно один, но много раз. Теоретически можно что-то типа такого:
int sum = 0
for(Iter iter = container.begin(); iter != container.end(); ++iter)
{
   sum += iter.getValue();
}

Так вот, теоретически, если методы begin/end/getValue — константные, то компилятор может предположить, что коллекцию
можно обходить в любом порядке, а значит тут можно суммирование распараллелить — для нескольких частей коллекции по
процессору.
Но, насколько я знаю, теоретические измышления по этому поводу до серьёзной практики так и не дошли...
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: недостатки системы типов .NET
От: Cyberax Марс  
Дата: 13.11.06 11:58
Оценка:
kan wrote:
>> Распараллелить автоматически можно (иногда) только если выполняются
>> одновременно два немутирующих метода. Да и то не всегда.
> Можно один, но много раз. Теоретически можно что-то типа такого:
А если ты из константного метода используешь mutable-переменные?

> Но, насколько я знаю, теоретические измышления по этому поводу до

> серьёзной практики так и не дошли...
Дошли, в принципе в OpenMP это делается, но для массивов.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[9]: Нет возможности использовать константные ссылки
От: GlebZ Россия  
Дата: 13.11.06 12:07
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> То есть копирование списка как такового не понадобилось.

C>На ленивых списках это бы еще красивее смотрелось. Ты фактически просто
C>строил бы функциональные виды над списком.
Собственно, оттуда вся идея. В случае ленивых языков переформирование производит сам компилятор.

C>Но в моем случае не пойдет — тебе нужно модифицировать не список, а

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

C>С навигационным доступом тоже будут проблемы — так как после пары-тройки

C>изменений у тебя при каждом обращении оно будет проходить через
C>несколько списков. Кэширование поможет, но тогда уж проще будет
C>скопировать граф.
С навигационным недекларативным доступом — да.

C>Ну и мелочи — графовые алгоритмы часто и так уже сложны, так что как

C>сделать их в виде функциональных итераторов может быть задачей для
C>диссертации.
На 90 процентов алгоритмы — это итераторы прохода через граф.
Re[13]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.06 12:14
Оценка:
Здравствуйте, kan, Вы писали:

kan>А чем константа отличается от неизменяемой переменной в данном случае?


Тем что константа получает свое значение при компиляции, а не изменяемая перепменная при инициализации (в рантайме).

kan>Объявление константного метода, это по сути приписывание const "скрытой" переменной this. Так что в точности тоже самое.


Не совсем. Все же тут гарантируется (должно по крайней мере), инвариант класса. Плюс по уму должно гарантироваться неизменность и других объектов. То есть должно гарантироваться отсуствие побочных эффектов.

kan>Насчёт распараллеливания не уверен,


Это 100%.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Нет возможности использовать константные ссылки
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.06 12:14
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Вот именно, я об этом и говорю. Но чем этот подход будет отличаться от const_cast'a? Ну да, чисто с эстетической точки зрения красивее, но суть таже.


Вообще-то const_cast тут вообще ни с какого боку не уперся. Более того, он позволяет нарушить данный контракт. А это уже нарушение принципов типобезопасности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Нет возможности использовать константные ссылки
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.06 12:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Вот только AndreiF хочет иметь возможность с одним и темже объектом в одном контексте работать как с изменяемым, а в другом как с не изменяемым. Те мешает мух с котлетами.


Может ты его не так понял? Или он не точно выразился?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Нет возможности использовать константные ссылки
От: WolfHound  
Дата: 13.11.06 12:21
Оценка:
Здравствуйте, VladD2, Вы писали:

WH>>Вот только AndreiF хочет иметь возможность с одним и темже объектом в одном контексте работать как с изменяемым, а в другом как с не изменяемым. Те мешает мух с котлетами.

VD>Может ты его не так понял? Или он не точно выразился?
А по моему он явно говорит о плюсовых const те объект в одном месте может быть изменяемым, а в другом (по константной ссылке) не изменяемым.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Нет возможности использовать константные ссылки
От: Cyberax Марс  
Дата: 13.11.06 12:25
Оценка:
GlebZ wrote:
> C>Но в моем случае не пойдет — тебе нужно модифицировать не список, а
> C>граф. То есть, фактически, имея набор вершин получить список дуг. Так
> C>что у тебя нулевой задачей будет пронумеровать вершины в графе, что уже
> C>само по себе нетривиально.
> Нумерация — это просто часть задачи для списка которую я взял для
> простейшего примера трансформации. Доступ все-таки происходит не
> индексный а именно через итераторы. А через итераторы можно выразить
> обход графа в той же степени, как и списка. Некоторые проблемы могут
> возникнуть с метками прохода, но они IMHO решаемы.
Обход графа — это абсолютный мизер. Граф еще надо и модифицировать при
проходе. Я даже не представляю как это в функциональном стиле сделать
(точнее представляю, но с гигантским оверхедом).

> C>С навигационным доступом тоже будут проблемы — так как после пары-тройки

> C>изменений у тебя при каждом обращении оно будет проходить через
> C>несколько списков. Кэширование поможет, но тогда уж проще будет
> C>скопировать граф.
> С навигационным недекларативным доступом — да.
С декларативным — тоже.

> C>Ну и мелочи — графовые алгоритмы часто и так уже сложны, так что как

> C>сделать их в виде функциональных итераторов может быть задачей для
> C>диссертации.
> На 90 процентов алгоритмы — это итераторы прохода через граф.
Уууу.... У меня алгоритмы поиска разломов, например, требуют временной
модификации графа для хранения промежуточных результатов. С
многочисленными возвратами и т.п.

Я читал некоторые работы:
http://web.engr.oregonstate.edu/~erwig/papers/InductiveGraphs_JFP01.pdf
http://www.cs.indiana.edu/pub/techreports/TR330.pdf
по функциональному представлению графов, но ни один из этих подходов мне
не подходит. Там либо эффективные модификции графа, либо эффективное его
хранение — совместно оно не получается.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[7]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.06 12:49
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


VD>>Может для тебя это и обычно. Я вообще с object-ами не работаю. И для меня это не обычно.


AVK>Это не вопрос того, с чем ты работаешь. Это кусок кода для поддержки компонентной модели дотнета. И тип объекта там на этапе компиляции неизвестен принципиально.


Малоги куски какого унаследованого старья ты где выкопаешь? Это никак не отменяет возможности лично мне использовать типизированный Clone().

VD>>Самое смешное, что коваринтности интерфейсов нет только в Шарпе. Дотнет ее поддерживает. Но в твоем случае это безтолку. Тут дизайн приложения надо менять. Обжекты выбрасывать.


AVK>Ну выброси обжекты в UITypeEditor


Это какая-то аномашия — говорить не в тему.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.11.06 13:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Малоги куски какого унаследованого старья ты где выкопаешь?


Это не унаследованное старье, это актуальная часть.

VD> Это никак не отменяет возможности лично мне использовать типизированный Clone().


Ты можешь использовать типизированный Clone, только если ты знаешь тип объекта во время компиляции. В случае работы дизайн-тайма дотнета ты этого не знаешь принципиально.

AVK>>Ну выброси обжекты в UITypeEditor


VD>Это какая-то аномашия — говорить не в тему.


Очень даже в тему. Если ты еще не понял — метод EditValue, это из этого класса. Вот теперь и расскажи, как мне написать этот метод используя типизированный Clone, учитывая то, что конкре5тный редактор совсем не обязан быть привязанным к конкретному типу.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[9]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 13:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Вот только если не делать так как ты говоришь можно и из системы выжать все и не перекомпилировать весь код.


вот только выжимать придется вручную

WH>Нет. В твоей системе придется перекомпилировать вобще все и вобще всегда. Ибо любое изменение кода может повлечь за собой невозможность оптимизации которое цепной реакцией распространиться на всю систему.


И даже код, который от измененного кода никак не зависит?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: недостатки системы типов .NET
От: kan Великобритания  
Дата: 13.11.06 13:07
Оценка:
VladD2 wrote:

> kan>А чем константа отличается от неизменяемой переменной в данном случае?

> Тем что константа получает свое значение при компиляции, а не изменяемая
> перепменная при инициализации (в рантайме).
Константы времени компиляции в С++ сущность совсем другая, и со словом const они почти никак не связаны.

> kan>Объявление константного метода, это по сути приписывание const

> "скрытой" переменной this. Так что в точности тоже самое.
> Не совсем. Все же тут гарантируется (должно по крайней мере), инвариант
> класса. Плюс по уму должно гарантироваться неизменность и других
> объектов. То есть должно гарантироваться отсуствие побочных эффектов.
Понятие побочного эффекта для объекта вещь довольно расплывчатая. Так что спец-конструкцией тут не обойтись.

Смысл const в языке С++ довольно чёткий и вполне однозначный, ничего не перегружено, так что это заблуждение:

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

А вот когда ты пытаешься выяснять как там "должно по крайней мере" быть — сразу всё плохо становится.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 13:12
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Нет, не то же самое. Главное отличие того, что предлагается в шарпе, от того, что есть в С++, это местоположение ответственности. В случае плюсового const ответственность несет вызываемая сторона, в случае immutable в шарпе — вызываемая. Говорить о том, какой вариант лучше, вот так навскидку я не берусь. На первый взгляд шарповский вариант все же пологичнее.


э... не понял
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: недостатки системы типов .NET
От: kan Великобритания  
Дата: 13.11.06 13:14
Оценка:
Cyberax wrote:

>> > Распараллелить автоматически можно (иногда) только если выполняются

>> > одновременно два немутирующих метода. Да и то не всегда.
>> Можно один, но много раз. Теоретически можно что-то типа такого:
> А если ты из константного метода используешь mutable-переменные?
Вот тут и опаньки — mutable и const_cast портят всю малину, о чём Влад2 и скорбит.

>> Но, насколько я знаю, теоретические измышления по этому поводу до

>> серьёзной практики так и не дошли...
> Дошли, в принципе в OpenMP это делается, но для массивов.
Насколько эти случаи нетривиальны, что сложно сделать или легко забыть сделать пометки возможности параллелизации в коде
вручную?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 13:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Легко


Я тоже так и сделал, вот только это очень коряво. Даже если разнести вложенные классы по файлам с помощью частичного определения класса, испещренный типами вида StateMachine<byte>.EpsTransition код оччень напрягает.
В принципе, элементарный typedef помог бы делу, но они даже этого не сделали в C#.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: недостатки системы типов .NET
От: WolfHound  
Дата: 13.11.06 13:33
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>И даже код, который от измененного кода никак не зависит?

В твоей системе зависимоти не предсказуемые. Либой код может привести к перекомпиляции всего. Либо основу придется держать не оптимизированной что есть очень медленно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.11.06 13:41
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>э... не понял


В шарпе — вызывающая.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[5]: недостатки системы типов .NET
От: WolfHound  
Дата: 13.11.06 13:45
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>В принципе, элементарный typedef помог бы делу, но они даже этого не сделали в C#.

using SMByteEps = ConsoleApplication3.StateMachine<byte>.EpsTransition;
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.06 13:52
Оценка:
Здравствуйте, kan, Вы писали:

kan>Константы времени компиляции в С++ сущность совсем другая, и со словом const они почти никак не связаны.


Это не так.

kan>Понятие побочного эффекта для объекта вещь довольно расплывчатая.


Это тоже не так.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 13:53
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Но в таком раскладе вернемся к тому, от чего пытались уйти — придется делать две реализации одного и того же метода — типизированную и нетипизированную.


При наличии множественного наследования реализаций — не придется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Нет возможности использовать константные ссылки
От: AndreiF  
Дата: 13.11.06 13:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

Я не понимаю, где ты нашел смешение мух и котлет в очень простом желании — иметь возможность удостовериться, что определенный метод, куда я передаю свой объект, не сможет его изменить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 13:59
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>В твоей системе зависимоти не предсказуемые.


С чего ты так решил?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 13:59
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>В шарпе — вызывающая.


Ну на самом деле в случае C++ отвтственность несет ни одна из этих сторон. Ответственность там несет компилятор. Другой вопрос, что в С++ оставили слишком много дырок, которые позволяют все-таки изменить неизменяемое
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 13.11.06 14:00
Оценка:
Здравствуйте, VladD2, Вы писали:

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


V>>Вот именно, я об этом и говорю. Но чем этот подход будет отличаться от const_cast'a? Ну да, чисто с эстетической точки зрения красивее, но суть таже.


VD>Вообще-то const_cast тут вообще ни с какого боку не уперся. Более того, он позволяет нарушить данный контракт. А это уже нарушение принципов типобезопасности.


Я точно также могу пометить, метод, который форматирует винчестер (удаляет все объекты, ваш вариант), как якобы безопасный с точки зрения инварианта типов программы (как ты предлагал помечать методы записи в лог) — и приплыли.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[6]: недостатки системы типов .NET
От: AndreiF  
Дата: 13.11.06 14:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>
WH>using SMByteEps = ConsoleApplication3.StateMachine<byte>.EpsTransition;
WH>


Плохо только, using придется писать для каждого типа и в каждом файле, где они используются.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.11.06 14:22
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Ну на самом деле в случае C++ отвтственность несет ни одна из этих сторон. Ответственность там несет компилятор.


Понятно, что компилятор. Ты просто не понял мысль — в С++ константность задается как свойство обрабатывающего метода, в шарпе как свойство самих данных. А уж кем конкретно это контроллируется, дело десятое.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[12]: недостатки системы типов .NET
От: WolfHound  
Дата: 13.11.06 14:37
Оценка:
Здравствуйте, AndreiF, Вы писали:

WH>>В твоей системе зависимоти не предсказуемые.

AF>С чего ты так решил?
Элементарно:
Допустим у нас есть некий класс типа такого:
public class Foo
{
    public mutable x : int;
    public mutable y : int;
    public mutable z : int;
    public static DoSome(..., fn : Foo -> Foo) : void
    {
        ....
    }
}

Это класс использует все кому не лень както так
    public static Asd(...) : void
    {
        ...
        Foo.DoSome(..., foo => {foo.x = foo.y - foo.z; foo});
        ...
    }
    public static Qwe(...) : void
    {
        ...
        Foo.DoSome(..., foo => {foo.x = foo.y + foo.z; foo});
        ...
    }

Наш мегакомпилятор пронюхал что все работают с Foo как с value типами и все под это дело заоптимизировал.

Теперь вдруг появляется какойто левый код в котором написали чтото типа такого:
    public static Zxc(...) : List<Foo>
    {
        ...
        def fooList = List<Foo>();
        ...
        Foo.DoSome(..., foo => {fooList.Add(foo); foo});
        ...
        fooList
    }

Те вдруг у нас начали работать с Foo как reference типом ибо в по факту у него именно такая семантика.
И по цепной реакции у нас все посыпалось...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: недостатки системы типов .NET
От: _FRED_ Черногория
Дата: 13.11.06 15:01
Оценка:
Здравствуйте, VladD2, Вы писали:

kan>>Константы времени компиляции в С++ сущность совсем другая, и со словом const они почти никак не связаны.


VD>Это не так.


Гхм…
Автор: c-smile
Дата: 10.01.06
... << RSDN@Home 1.2.0 alpha rev. 665>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Re[13]: недостатки системы типов .NET
От: AndreiF  
Дата: 14.11.06 03:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Те вдруг у нас начали работать с Foo как reference типом ибо в по факту у него именно такая семантика.

WH>И по цепной реакции у нас все посыпалось...

Ничего не посыпалось. Никто не запрещает использовать один и тот же тип как по ссылке, так и по значению в зависимости от контекста.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: недостатки системы типов .NET
От: AndreiF  
Дата: 14.11.06 03:47
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Понятно, что компилятор. Ты просто не понял мысль — в С++ константность задается как свойство обрабатывающего метода, в шарпе как свойство самих данных. А уж кем конкретно это контроллируется, дело десятое.


В С++ никто не запрещает создавать неизменяемые типы, если есть такая необходимость. А вот создать константную ссылку в шарпе нельзя. В этом и есть главное различие
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.06 03:48
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Гхм…
Автор: c-smile
Дата: 10.01.06


И это тоже.
При некоторых обстаятельствах компилятор порождает именно константы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Нет возможности использовать константные ссылки
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.06 03:48
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Я точно также могу пометить, метод, который форматирует винчестер (удаляет все объекты, ваш вариант), как якобы безопасный с точки зрения инварианта типов программы (как ты предлагал помечать методы записи в лог) — и приплыли.


Это твои проблемы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Нет возможности использовать константные ссылки
От: AndreiF  
Дата: 14.11.06 03:50
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Я точно также могу пометить, метод, который форматирует винчестер (удаляет все объекты, ваш вариант), как якобы безопасный с точки зрения инварианта типов программы (как ты предлагал помечать методы записи в лог) — и приплыли.


Ты точно так же можешь назвать метод форматирования винчестера PrintDocument или ValidateData, и потом вызвавший этот метод программист очень сильно удивится. И что ты этим докажешь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: недостатки системы типов .NET
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.11.06 05:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Но в таком раскладе вернемся к тому, от чего пытались уйти — придется делать две реализации одного и того же метода — типизированную и нетипизированную.
Ага. Несмотря на тривиальную реализацию, это не вполне удобно.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 14.11.06 06:39
Оценка:
Здравствуйте, VladD2, Вы писали:

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


V>>Я точно также могу пометить, метод, который форматирует винчестер (удаляет все объекты, ваш вариант), как якобы безопасный с точки зрения инварианта типов программы (как ты предлагал помечать методы записи в лог) — и приплыли.


VD>Это твои проблемы.


Точно. Это проблемы программиста. Как и в случае с const_cast'ом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[12]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 14.11.06 06:39
Оценка:
Здравствуйте, AndreiF, Вы писали:

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


V>>Я точно также могу пометить, метод, который форматирует винчестер (удаляет все объекты, ваш вариант), как якобы безопасный с точки зрения инварианта типов программы (как ты предлагал помечать методы записи в лог) — и приплыли.


AF>Ты точно так же можешь назвать метод форматирования винчестера PrintDocument или ValidateData, и потом вызвавший этот метод программист очень сильно удивится. И что ты этим докажешь?


То, что это будет аналог const_cast'a. Теже яйца, вид сбоку.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[11]: недостатки системы типов .NET
От: _FRED_ Черногория
Дата: 14.11.06 06:54
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

VD>>Хотя согласен, что идея помечать методы (да и классы) как неизменяемые — это хорошая идея. И надо будет ее реализовать.


АХ>На самом деле правильная идея (которая хорошо ложится на философию Немерле) как раз делать их (классы и методы) по умолчанию неизменяемыми, а как раз помечать изменяемые случаи!


Что значит "делать … классы … неизменяемыми" Разве, если объявить все поля класса как readonly (в C#), он не станет сам по себе "неизменяемым"?

АХ>А то ведь в основном людям лень дополнительно чего-то дописывать.


Да и неизменяемые методы нужны, ИМХО, _только_ для изменяемых классов (в неизменяемых классах не может быть изменяемых методов по определению), а классы — по умолчанию неизменяемы, => в изменяемых классах довольно часто надо будет делать методы изменяемыми в то время, как в неизменяемых классах — никогда. Получается, что было бы удобнее всего, если бы в изменяемых классах по-умолчанию методы были бы изменяемыми.

АХ>поэтому Nemerle провоцирует делать неизменяемые переменные (чтобы не писать mutable),


Дело, скорее всего, не в Немерле, а в концепции (функционального программирования), диктуемой языком. Я, когда начал использовать Linq и обработку последовательностей через класс Sequence, так же заметил за собой маниакальное пристрастие к отметке полей класса как readonly и попытке построить архитектуру так, что бы количество [public] set-терров свойств свести к минимуму.
... << RSDN@Home 1.2.0 alpha rev. 665>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Re[13]: Нет возможности использовать константные ссылки
От: AndreiF  
Дата: 14.11.06 07:47
Оценка:
Здравствуйте, prVovik, Вы писали:

V>То, что это будет аналог const_cast'a. Теже яйца, вид сбоку.


Нет, ты просто не понимаешь. От преднамеренных диверсий, равно как и от непробиваемой глупости (которая часто бывает намного хуже по своим последствиям), никакая защита не даст гарантий. Но это не значит, что на защиту надо вообще забить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: недостатки системы типов .NET
От: _FRED_ Черногория
Дата: 14.11.06 08:00
Оценка:
Здравствуйте, VladD2, Вы писали:

AF>>Плохо только, using придется писать для каждого типа и в каждом файле, где они используются.


VD>Тогда переходи на Nemerle . В нем объявляешь:

VD>type SMByteEps = ConsoleApplication3.StateMachine<byte>.EpsTransition;

VD>и используй SMByteEps в любом месте.

Блин, вот ведь: всё, как надо :о) А этот type виден на уровне исходников, в пределах сборки или каким-то образом "экспортируется"?
... << RSDN@Home 1.2.0 alpha rev. 665>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Re[16]: недостатки системы типов .NET
От: kan Великобритания  
Дата: 14.11.06 09:10
Оценка:
VladD2 wrote:

> kan>Константы времени компиляции в С++ сущность совсем другая, и со

> словом const они почти никак не связаны.
> Это не так.
Определения в студию. А рассуждения типа "при некоторых обстоятельствах... как мне кажется..." не катят.

> kan>Понятие побочного эффекта для объекта вещь довольно расплывчатая.

> Это тоже не так.
Давай тогда точное определение, годное хотя бы для создания стандарта.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 14.11.06 09:32
Оценка:
Здравствуйте, AndreiF, Вы писали:

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


V>>То, что это будет аналог const_cast'a. Теже яйца, вид сбоку.


AF>Нет, ты просто не понимаешь. От преднамеренных диверсий, равно как и от непробиваемой глупости (которая часто бывает намного хуже по своим последствиям), никакая защита не даст гарантий. Но это не значит, что на защиту надо вообще забить.


С этим я согласен. Я просто утверждал, что нападки на const_cast необоснованы и что предложенный Владом метод ничем принципиально от const_cast не отличается и что подобные ему механизмы вводить придется полюбому.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[11]: недостатки системы типов .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 14.11.06 10:43
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>В С++ никто не запрещает создавать неизменяемые типы, если есть такая необходимость.


Ну и слава богу.

AF> А вот создать константную ссылку в шарпе нельзя. В этом и есть главное различие


Вопрос в том, насколько эта константная ссылка нужна, и ответ на него не так уж и однозначен.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[14]: недостатки системы типов .NET
От: WolfHound  
Дата: 14.11.06 11:19
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Ничего не посыпалось. Никто не запрещает использовать один и тот же тип как по ссылке, так и по значению в зависимости от контекста.

Проблема в том что этот контекст может разполстись на всю систему. И ничто этому помешать не может.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: недостатки системы типов .NET
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 14.11.06 19:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Другое дело, что не сделали обошенной реализации Sort для IList<T>. Вот это уже действительно не грамотно.


Собственно, я это и имел в виду. Просто не всегда реализация IList<T> сделана на массивах. А массив, вообще-то — это частный случай IList<T>. Зачем было писать реализацию для менее общего случая?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: недостатки системы типов .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.06 22:44
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Блин, вот ведь: всё, как надо :о) А этот type виден на уровне исходников, в пределах сборки или каким-то образом "экспортируется"?


Вроже бы только внутри сборки, но могу ошибаться. В компиляторе он рассматривается как синоним.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Нет возможности использовать константные ссылки
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.06 22:44
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Точно. Это проблемы программиста. Как и в случае с const_cast'ом.


const_cast — это проблемы пользвателя которые ты ему создаешь используя const_cast.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: недостатки системы типов .NET
От: Vermicious Knid  
Дата: 14.11.06 23:09
Оценка:
Здравствуйте, VladD2, Вы писали:

_FR>>Блин, вот ведь: всё, как надо :о) А этот type виден на уровне исходников, в пределах сборки или каким-то образом "экспортируется"?

VD>Вроже бы только внутри сборки, но могу ошибаться. В компиляторе он рассматривается как синоним.
Да нет, не только внутри сборки. Из других сборок он тоже доступен(если конечно помечен как публичный). Но выглядит в рефлекторе это довольно забавно, и соответственно из C# использовать невозможно.
Re[14]: Нет возможности использовать константные ссылки
От: prVovik Россия  
Дата: 15.11.06 07:35
Оценка:
Здравствуйте, VladD2, Вы писали:

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


V>>Точно. Это проблемы программиста. Как и в случае с const_cast'ом.


VD>const_cast — это проблемы пользвателя которые ты ему создаешь используя const_cast.


А в твоем варианте разве не так?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
лэт ми спик фром май харт
Re[11]: недостатки системы типов .NET
От: Алексей П Россия  
Дата: 15.11.06 12:21
Оценка:
Здравствуйте, Vermicious Knid, Вы писали:

VK>Да нет, не только внутри сборки. Из других сборок он тоже доступен(если конечно помечен как публичный). Но выглядит в рефлекторе это довольно забавно, и соответственно из C# использовать невозможно.


Подтверждаю, и снаружи видно.
Nemerle:
type Context = string -> float

Рефлектор:
[TypeAlias(".f(System.String()System.Single())")]
public interface Context { }
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: недостатки системы типов .NET
От: _FRED_ Черногория
Дата: 15.11.06 15:45
Оценка:
Здравствуйте, Алексей П, Вы писали:

VK>>Да нет, не только внутри сборки. Из других сборок он тоже доступен(если конечно помечен как публичный). Но выглядит в рефлекторе это довольно забавно, и соответственно из C# использовать невозможно.


АП>Подтверждаю, и снаружи видно.

АП>Nemerle:
type Context = string -> float

АП>Рефлектор:
АП>[TypeAlias(".f(System.String()System.Single())")]
АП>public interface Context { }


А ссылку на документиацию можешь дать? А то я не нашёл только здесь

Может ли псевдоним (alias) быть незавершённым дженерик-типом? То есть примерно
АП>Nemerle:
type Context[T] = System.Collection.Generic.List[T]
... << RSDN@Home 1.2.0 alpha rev. 665>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Re[15]: Нет возможности использовать константные ссылки
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.11.06 23:16
Оценка:
Здравствуйте, prVovik, Вы писали:

V>А в твоем варианте разве не так?


Я где-то использовал const_cast? Я даже кога на С++ писал, то его никогда не использовал.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.