DG>>все эти названия под твое определение подходят, какое из них выбрать?
U>1 название более-менее, 2 плохое, т.к. список не только заполняется, но и создается, 3 вообще не в тему. Хорошее название здесь подобрать сложно, т.к. непонятно для решения каких задач такой универсальный метод имеет смысл.
и где определение, как необходимо называть методы, на основе которого ты сделал эти выводы?
Здравствуйте, Jack128, Вы писали:
Z>>Я кстати не очень понимаю, почему в C# сделали так как сделали, Хейлсберг в делфи использовал как конструкторы обычные статик методы.
J>Это не так, в дельфи конструкторы — это тоже отдельные сущности, и не везде, где можно юзать статические методы, можно юзать конструкторы.
Возможно. Но их вызов выглядел один в один как вызов статик метода.
Здравствуйте, Silver_S, Вы писали:
S_S> Суть в том, что одними философствованиями и игрой слов в отрыве от конкретного языка(синтаксиса) невозможно выбрать один из двух вариантов — использовать new или нет . Одного ответа на все случаи нет. S_S>Во-первых не две градации — нужен,не нужен. А хотя бы тысячу — до какой степени нужен. S_S>А во-вторых это зависит от тысячи мелочей. Разработка синтаксиса это огромная сеть причинно-следственных связей. Один элемент изменишь и в других местах что-то изменится.
В философии оно конечно так, но на практике в языках ужасающее количество решений не продумываются толком, а берутся из других языков практически без изменений.
S_S>Даже наличие Garbage Collector, немного меняет суть "new".
GC это не мелочь и меняет он суть отнюдь не немного.
S_S>Есть ведь еще конструкции, в некоторых языках: S_S>var v = new Class{Fld=1}; S_S>var v = new Class(){Fld=1};
Первые два примера с конструктором связанны чисто условно, взгляни на with
, ему конструктор не нужен.
S_S>var v = new Class[1000]; S_S>var v = new Class[]{1,2}; S_S>Даже если бы неоднозначности другим способом устранили, все-равно костыль new тут только ускоряет чтение.
Вторые к конструктору типа никакого отношения не имеют, это конструктор массива. Особый подход к массиву на уровне языка в современных языках считаю неоправданным (особенно когда кроме особого синтаксиса конструктора ничего в язык не вводится).
S_S>А в некоторых языках в паттерн матчинге конструкторы используются.На полезность new это тоже влияет.
Nemerle прекрасно использует конструкторы в PM без new. Уж в PM new совсем не нужен, он там больше сбивает с толку.
S_S>Когда быстрый вычислительный алгоритм, с вызовом кучи функций, тогда хорошо что new выделяется от обычных функций. S_S> Когда сложный сценарий создания и сам объект сложный(что даже конструктор без параметров закрытый) тогда тоже может быть с new лучше.
Чем лучше?
S_S>Не ответишь о полезности new, в отрыве от тысячи других фич конкретного языка. И даже надо учитывать программы, которые на языке предполагается писать (наиболее типичные сценарии использования).
new полезен там, где для каждого его вызова требуется аналогичный delete.
Здравствуйте, DarkGray, Вы писали:
DG>и где определение, как необходимо называть методы, на основе которого ты сделал эти выводы?
Я тебе его уже дважды приводил:
Название функции должно включать в себя действие, которое функция выполняет.
Что делает приведенная тобой функция? Создает ряд натуральных чисел. Соответственно хорошее название должно звучать именно так. Из твоих вариантов более-менее был первый, т.к. был неполным, но по крайней мере не ложным, второй и третий вариант были очень плохими, т.к. вместо информации содержали дезинформацию.
Здравствуйте, DarkGray, Вы писали:
DG>стандартный пример, берем список одинаковых элементов DG>т.к. мир иммутабельный, то нет разницы между двумя следующими записями
Вот есть у нас мутабельная сущность item с изменяемым x. Если мы создаем этот item один раз, а дальше передаем его по ссылке, то изменив x в одном месте, я имею полную уверенность, что x измениться во всех 124 местах, в которых этот item используется. Если же мы используем мегаконцепцию эмуляция мутабельных сущностей на иммутабельных объектах и создали item 124 раза, то когда нам наконец-то захотелось x изменить, то нам надо все 124 места вспомнить, а за тем в каждом месте item заменить. А в остальном да никакой разницы, подумаешь в одном случае надо изменить код только в одном месте, а в другом — в 124 местах, разве это разница?
DG>этот пример показывает, что если мир иммутабельный, то даже несмотря на операции изменяющие мир — нам не важно, создавались ли отдельные экземпляры или не создавались
Кошмар. И этот человек раньше умел делать мир проще...
U>Если мы создаем этот item один раз, а дальше передаем его по ссылке, то изменив x в одном месте, я имею полную уверенность, что x измениться во всех 124 местах, в которых этот item используется.
если это происходит в неявном виде — это чревато.
а если говорить про явный вид, то значит есть явная операция конструирования "мира" на основе item.
и соответственно при изменении item — операция конструирования "мира" еще раз вызовется, и построит мир с измененным item
Здравствуйте, Silver_S, Вы писали:
S_S>И даже от текста программы зависит. Когда дерево собирается вручную (типа XML), может new мешает. S_S>Когда быстрый вычислительный алгоритм, с вызовом кучи функций, тогда хорошо что new выделяется от обычных функций. S_S> Когда сложный сценарий создания и сам объект сложный(что даже конструктор без параметров закрытый) тогда тоже может быть с new лучше.
Выходит, что язык тут не причем, а дело в контексте использования?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>GC это не мелочь и меняет он суть отнюдь не немного. Z>... Z>Первые два примера с конструктором связанны чисто условно, взгляни на with
, ему конструктор не нужен. Z>... Z>Вторые к конструктору типа никакого отношения не имеют, это конструктор массива. Особый подход к массиву на уровне языка в современных языках считаю неоправданным (особенно когда кроме особого синтаксиса конструктора ничего в язык не вводится).
+1
S_S>>А в некоторых языках в паттерн матчинге конструкторы используются.На полезность new это тоже влияет. Z>Nemerle прекрасно использует конструкторы в PM без new. Уж в PM new совсем не нужен, он там больше сбивает с толку.
Думаю он это и имел в виду. Что мол в языке с ПМ new совсем лишний.
S_S>>Когда быстрый вычислительный алгоритм, с вызовом кучи функций, тогда хорошо что new выделяется от обычных функций. S_S>> Когда сложный сценарий создания и сам объект сложный(что даже конструктор без параметров закрытый) тогда тоже может быть с new лучше.
Z>Чем лучше?
Наверно тем, что видно динамическое выделение памяти, значит тормоза. Но тогда надо убрать new для создания структур. Они ведь не в куче создаются. Т.е. это видимо референс в сторону С++.
S_S>>Не ответишь о полезности new, в отрыве от тысячи других фич конкретного языка. И даже надо учитывать программы, которые на языке предполагается писать (наиболее типичные сценарии использования).
Z>new полезен там, где для каждого его вызова требуется аналогичный delete.
Откровенно говоря наличие new и delete на мой взгляд — это ошибка дизайна. В С++ все (толковые программисты) только и занимаются тем, что скрывают использование delete. Вот и надо было эту практику сразу спрятать под покровы абстракции.
Скажем запретить явно использование new с delete и заставить программистов создавать для таких классов некие обертки. Если для этого предусмотреть спец.синтаксис, то можно получиться весьма не плохо, и управление памятью в С++ не стало бы "искусством".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DarkGray, Вы писали:
U>>Кстати, понял чем мне не понравился пример с цветом. Цвет это не объект, а readonly структура, т.е. сущность, которую бессмысленно сравнивать по ссылке, ее можно сравнивать только по значению. Для таких сущностей действительно не важен способ получения, т.к. не важно получаем ли мы один и тот же экземпляр или разные экземпляры, важно лишь его значение.
DG>в большинстве моделей и остальные сущности тоже сраниваются по идентификатору, а не по экземплярам. DG>user('undying') и еще раз user('undying') — это одна и таже сущность.
Это называется структурная эквивалентность. В линейке С такой фичи не поддерживалось.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DarkGray, Вы писали:
U>>Если мы создаем этот item один раз, а дальше передаем его по ссылке, то изменив x в одном месте, я имею полную уверенность, что x измениться во всех 124 местах, в которых этот item используется.
DG>если это происходит в неявном виде — это чревато.
Чем? Автоматический кэш, что делает? Заменяет явные модификации на неявные. И какой код проще с автоматическими кэшами или явными модификациями?
DG>а если говорить про явный вид, то значит есть явная операция конструирования "мира" на основе item.
Бедный мир, который должен уметь конструироваться на основе каждой песчинки.
DG>и соответственно при изменении item — операция конструирования "мира" еще раз вызовется, и построит мир с измененным item
Пример можно? Только не уровня отдельного экземпляра/коллекции, а чего-то мало-мальски сложного и реального. Например, есть иерархия world -> carList -> car -> sensorList -> sensor. Как будет выглядеть замена конкретного AnalogSensor на DiscreteSensor?
U>Чем? Автоматический кэш, что делает? Заменяет явные модификации на неявные. И какой код проще с автоматическими кэшами или явными модификациями?
ручное управление кэшами — это такой же анахронизм, как ручное управление памятью
DG>>а если говорить про явный вид, то значит есть явная операция конструирования "мира" на основе item.
U>Бедный мир, который должен уметь конструироваться на основе каждой песчинки.
система автоматических кэшей — это и есть конструирование мира из песчинки, записанное на коленке.
DG>>и соответственно при изменении item — операция конструирования "мира" еще раз вызовется, и построит мир с измененным item
U>Пример можно? Только не уровня отдельного экземпляра/коллекции, а чего-то мало-мальски сложного и реального. Например, есть иерархия world -> carList -> car -> sensorList -> sensor. Как будет выглядеть замена конкретного AnalogSensor на DiscreteSensor?
как будет записываться? или как будет исполняться?
Здравствуйте, DarkGray, Вы писали:
U>>Чем? Автоматический кэш, что делает? Заменяет явные модификации на неявные. И какой код проще с автоматическими кэшами или явными модификациями? DG>ручное управление кэшами — это такой же анахронизм, как ручное управление памятью
И что можно автоматизировать в кэше? Он вроде и так полностью декларативный, от чего ты собрался автоматически избавиться? От вычисления значения или от указания источников?
U>>Пример можно? Только не уровня отдельного экземпляра/коллекции, а чего-то мало-мальски сложного и реального. Например, есть иерархия world -> carList -> car -> sensorList -> sensor. Как будет выглядеть замена конкретного AnalogSensor на DiscreteSensor?
DG>как будет записываться? или как будет исполняться?
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, DarkGray, Вы писали:
DG>>и где определение, как необходимо называть методы, на основе которого ты сделал эти выводы?
U>Я тебе его уже дважды приводил:
U>
U>Название функции должно включать в себя действие, которое функция выполняет.
U>Что делает приведенная тобой функция? Создает ряд натуральных чисел. Соответственно хорошее название должно звучать именно так. Из твоих вариантов более-менее был первый, т.к. был неполным, но по крайней мере не ложным, второй и третий вариант были очень плохими, т.к. вместо информации содержали дезинформацию.
Не создаёт, а возвращает. Может, у неё таблица заранее созданных списков есть? Какую именно часть действия надо заключать в название? А если описание функции подразумевает возврат списка от 0 до N без раскрытия деталей, откуда именно она его берёт? Что тогда писать? ReturnListFrom0ToN?
Здравствуйте, VoidEx, Вы писали:
VE>Не создаёт, а возвращает. Может, у неё таблица заранее созданных списков есть? Какую именно часть действия надо заключать в название? А если описание функции подразумевает возврат списка от 0 до N без раскрытия деталей, откуда именно она его берёт? Что тогда писать? ReturnListFrom0ToN?
В общем случае это будет FindOrCreate. Если создание не обладает побочными эффектами (т.е. создании при получении любым способом гарантируется), тогда Get.
U>И что можно автоматизировать в кэше? Он вроде и так полностью декларативный, от чего ты собрался автоматически избавиться? От вычисления значения или от указания источников?
избавиться от указания самих кэшей.
вот данного кода достаточно, чтобы все кэши были расставлены автоматически при изменении любого объекта: list1, list2 и т.д.
var list1 = list(1, 2, 4);
var list2 = GetList2();
var list = list1 + list2;
textBox.Text = list.Length.ToString();
причем здесь может быть расставлен даже инкрементальный кэш, когда при добавлении элемента в list1, textBox.Text автоматически щелкает на единичку, без перевычисления всего.
U>>>Пример можно? Только не уровня отдельного экземпляра/коллекции, а чего-то мало-мальски сложного и реального. Например, есть иерархия world -> carList -> car -> sensorList -> sensor. Как будет выглядеть замена конкретного AnalogSensor на DiscreteSensor?
DG>>как будет записываться? или как будет исполняться?
U>Для начала, как будет записываться.
раз это конкретный sensor, то значит известен его идентификатор
U>В общем случае это будет FindOrCreate. Если создание не обладает побочными эффектами (т.е. создании при получении любым способом гарантируется), тогда Get.
в данном примере, хорошим названием будет GenerateItems или GenerateNItems
слово Generate указывает на то, что из меньшего кол-ва информации генерится бОльшее кол-во информации.
указания List/Array и т.д. — нафиг не нужны, и фактически это продолжение венгерской нотации из C.
для указания, что Item-ов возвращается много достаточно суффикса -s
N-указывает на то, что генерация идет по кол-ву, а не другим способом.
т.е. в хорошем названии указывается, как трансформируется информация, а не что происходит в данном конкретном языке в данной конкретной реализации.
Здравствуйте, DarkGray, Вы писали:
DG>в данном примере, хорошим названием будет GenerateItems или GenerateNItems
Ничего против Generate не имею, это аналог Create, возможно в данном контексте более точный. Соответственно наилучшим названием будет GenerateNaturalNumbers.
Здравствуйте, DarkGray, Вы писали:
DG>избавиться от указания самих кэшей. DG>вот данного кода достаточно, чтобы все кэши были расставлены автоматически при изменении любого объекта: list1, list2 и т.д. DG>
А если не надо, чтобы list изменялся при изменении list1 и list2?
DG>причем здесь может быть расставлен даже инкрементальный кэш, когда при добавлении элемента в list1, textBox.Text автоматически щелкает на единичку, без перевычисления всего.
Это шаманство, при котором шаг влево-шаг вправо расстрел. Т.е. гибкость снижается на порядок, в лаконичности выигрываем копейки, ну и нафиг такое счастье?
U>>Для начала, как будет записываться. DG>раз это конкретный sensor, то значит известен его идентификатор
