ВВ>>>Теперь имя файл читает правильно и умеет работать в интерактивном режиме (при запуске без параметров). T>>Интерактивный режим появился, аргумент тихо пропускает. То есть ElaConsole.exe hw.ela всё равно запускает интерактивный режим.
ВВ>Да, это я тормознул, пардон. Сейчас все должно работать: ВВ>http://files.rsdn.ru/16070/ElaConsoleSingle.rar
Да, теперь работает отлично.
ВВ>Спасибо за тестинг под Линуксом
Кстати, можно на самом деле встретиться и бухнуть. ы?
В данном случае открывающая скобка — мусор, не приносит пользы. А в остальном, очень мило, да.
В питоне то же самое:
f = lambda y: y + 1
ВВ>>>Это не тип, это значение. Как раз признаков типа у него никаких нет.
T>>Понятие тип также не подразумевает, что с ним нельзя оперировать как с значением. T>>А какие признаки ты имеешь в виду?
ВВ>Тип предоставляет некоторый контракт, используя который мы можем работать со значениями, которые он описывает. Например, int — это тип, но значением переменной является не int, а 2, 33, 0x20. ВВ>template же никаких правил не создает, хотя может показаться и наоборот. Он просто-напросто используется для того, что бы создании объекта указать его первоначальное значение.
Кажется, там выше был шаблон, который предоставляет такой контракт, что все объекты порождённые от этого шаблона имеют поле User.
А при наличии небольшого вывода типов ещё и "User имеет тип int".
T>>>>У меня два вопроса. Оба про то "зачем нужны шаблоны". T>>>>1. (про то, почему нужны шаблоны, когда есть объекты) Почему нельзя var t = new : object { Foo = fun(x) => x++ }; как в жаваскрипте? ВВ>>>Что должно произойти если поменять родителя? T>>Что значит "поменять родителя"?
ВВ>
В Foo аттрибуты тоже поменяются потому что их не меняли в Foo.
var Foo = new : Bar { Uid = 100500 };
Bar.Uid = 12;
var Goo = new : Bar {};
Foo.Uid == 100500
Bar.Uid == Goo.Uid == 12
Есть такая MMORPG Deliantra с уродливой двумерной графикой, но довольно богатым движком (и на безумно производительной библиотеке событий libev). Так вот там в серверной части используется такое прототипное ООП. Щас, увы не смог найти, автор писал в чём были проблемы при создании.
Одна из основных проблем это наследование удаления аттрибутов. Он там заводил список удалённых аттрибутов и из-за этого усложняется резолвинг имён.
Ну слава богу Все-таки дотнет — кроссплатформенная технология.
ВВ>>Спасибо за тестинг под Линуксом T>Кстати, можно на самом деле встретиться и бухнуть. ы?
Здравствуйте, Temoto, Вы писали:
T>В данном случае открывающая скобка — мусор, не приносит пользы. А в остальном, очень мило, да. T>В питоне то же самое: T>f = lambda y: y + 1
(Комментарий шепотом — а тебе не кажется, что lamdba и : выполняют тут "одну и ту же функцию"? )
Вот только это уже не Си-подобный синтаксис, а поэтому вступает в некий конфликт со всем остальным. К тому же, когда параметров несколько (у нас все же не математика, а язык программирования ), то выглядит уже не очень:
var f = fun x, y, z x++;
Вообще скобки или должны всегда быть, или их не должно быть никогда. В этом плане синтаксис вида:
var f = fun() x++;
var f = fun(x) x++;
var f = fun(x, y) x + y;
начинает мне казаться вполне разумным.
T>Кажется, там выше был шаблон, который предоставляет такой контракт, что все объекты порождённые от этого шаблона имеют поле User. T>А при наличии небольшого вывода типов ещё и "User имеет тип int".
Что-то ты путаешь. Все объекты имеют поле? Вывод типов? Какой еще вывод типов? Куда вывод? Поле класса на тех правах абсолютно, что и обычная переменная — с ней никакая информация о типе не связана. Тип есть у самого значения и "выводится" еще парсером — даже не парсером, сканером, когда тот токенизацию делает.
А объект — это просто ассоциативный массив. Например, такой шаблон (если бы это было вообще возможно грамматически) не имел бы смысла:
var t = template { Uid };
var o = new : t {};
Потому что абсолютно равносильно:
var o = new {};
var x = o.Uid; //можно и так, ошибки не будет
o.Uid = 0; //и так тем более не будет
Шаблон, повторюсь, это что-то типа конструктора, позволяющего задавать первоначальные значения. Никакого контракта он в себе не несет вообще.
Почему отдельная сущность, а не другой объект?
Мне хотелось разделить "образцы" и собственно экземпляры, причем, чтобы "образец", template был недоступен для изменения вообще. Чтобы нельзя было сделать так:
var Foo = function(obj) {
obj.Uid = function() {...};
};
...
var Object = new { Uid = 0 };
...
Foo(Object);
Т.е. чтобы было видно по крайней мере, какие конкретно данные ты используешь при создании.
T>В Foo аттрибуты тоже поменяются потому что их не меняли в Foo.
Ну уверен, что понял. Если Bar — базовый, а Foo — его потомок, то когда мы меняет значение в Bar, то оно поменяется и в Foo? А наоборот?
И зачем вообще тогда создавать еще какой-то дополнительный Foo? Почему бы Bar не использовать?
Или я что-то не понимаю, или ты предлагаешь вариант, при котором полиморфизм накроется медным тазом.
Воронков Василий wrote:
> Собственно, мой вопрос, как вы считаете — если в языке есть синтаксис > для явного объявления переменных, насколько необходима поддержка > неявного объявления? Если эту возможность убрать (т.е. в примере выше > была бы ошибка) потеряет ли язык в выразительности?
Это очень сильно зависит от самого языка и его других фич.
Идеологии.
Например, в FORTRAN (в старых версиях) неявное объявление было
абсолютным злом, а например в COMMON LISP будет ровно наоборот.
Так что однозначного ответа на твой вопрос быть не может.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Собственно, мой вопрос, как вы считаете — если в языке есть синтаксис для явного объявления переменных, насколько необходима поддержка неявного объявления? Если эту возможность убрать (т.е. в примере выше была бы ошибка) потеряет ли язык в выразительности?
Ну как бы по опыту того же VB/VBA, на котором написаны были в свое время просто мегатонны бизнес-кода, всегда настоятельно рекомендуют использовать strict-режим, т.е. с объявлением переменных. Это сухая выжимка из мирового многолетнего опыта и многих-многих миллионов строк кода.
Да и вообще, тут нечего обсуждать. Один var читабельности не ухудшит, скорее — наоборот, и доп. контроль со стороны инструмента — всегда благо.
T>>В данном случае открывающая скобка — мусор, не приносит пользы. А в остальном, очень мило, да. T>>В питоне то же самое: T>>f = lambda y: y + 1
ВВ>(Комментарий шепотом — а тебе не кажется, что lamdba и : выполняют тут "одну и ту же функцию"? )
Конечно! Питон стремится к краткому синтаксису, но пока ещё не достиг.
ВВ>Вот только это уже не Си-подобный синтаксис, а поэтому вступает в некий конфликт со всем остальным. К тому же, когда параметров несколько (у нас все же не математика, а язык программирования ), то выглядит уже не очень:
ВВ>
ВВ>var f = fun x, y, z x++;
ВВ>
Да, я же говорил, что там только открывающая скобка мусор. Разделитель между списком аргументов и лямбда-выражением полезен.
Мне сегодня табы снились в качестве такого разделителя. Жалко, что бредовая идея.
ВВ>Вообще скобки или должны всегда быть, или их не должно быть никогда. В этом плане синтаксис вида:
ВВ>
ВВ>var f = fun() x++;
ВВ>var f = fun(x) x++;
ВВ>var f = fun(x, y) x + y;
ВВ>
ВВ>начинает мне казаться вполне разумным.
Конечно, он подходит к остальному.
T>>Кажется, там выше был шаблон, который предоставляет такой контракт, что все объекты порождённые от этого шаблона имеют поле User. T>>А при наличии небольшого вывода типов ещё и "User имеет тип int".
ВВ>Что-то ты путаешь. Все объекты имеют поле? Вывод типов? Какой еще вывод типов? Куда вывод? Поле класса на тех правах абсолютно, что и обычная переменная — с ней никакая информация о типе не связана. Тип есть у самого значения и "выводится" еще парсером — даже не парсером, сканером, когда тот токенизацию делает.
Для парсера поле Player1 = new : User { Uid = 0 } и поле Created = new : Datetime { Year = 2010, Month = 2 } имеют одинаковый тип object, да?
ВВ>А объект — это просто ассоциативный массив. Например, такой шаблон (если бы это было вообще возможно грамматически) не имел бы смысла:
ВВ>Шаблон, повторюсь, это что-то типа конструктора, позволяющего задавать первоначальные значения. Никакого контракта он в себе не несет вообще.
Поскольку объект, это не просто набор значений, а словарь, то шаблон таки несёт в себе контракт в виде имен этих первоначальных значений.
Я понял идею насчёт шаблона, но из-за словаря не получится отделить значения от имён.
Допустим, будет шаблон Fun = { Name = "", Expr = "", LexParent = "" }.
Очевидно, любой объект, созданный по этому шаблону имеет поле Name. Вот о каком контракте речь.
ВВ>Почему отдельная сущность, а не другой объект?
ВВ>Мне хотелось разделить "образцы" и собственно экземпляры, причем, чтобы "образец", template был недоступен для изменения вообще. Чтобы нельзя было сделать так:
Понятно, шаблон это имутабельный объект и наследоваться можно только от шаблонов. Ну я и говорил, что это классы.
ВВ>Т.е. чтобы было видно по крайней мере, какие конкретно данные ты используешь при создании.
T>>В Foo аттрибуты тоже поменяются потому что их не меняли в Foo.
ВВ>Ну уверен, что понял. Если Bar — базовый, а Foo — его потомок, то когда мы меняет значение в Bar, то оно поменяется и в Foo? А наоборот?
А наоборот не поменяется.
И после того, как в Foo поменяли поле, изменение его в базовом объекте не произведёт эффекта на поле Foo.
Самый близкий аналог такого поведения — это копия объекта на STM. http://en.wikipedia.org/wiki/Software_transactional_memory
ВВ>И зачем вообще тогда создавать еще какой-то дополнительный Foo? Почему бы Bar не использовать?
Конечно, можно использовать просто Bar. Прототипное программирование как раз предполагает, что каждый объект именно что используется. Но при этом он может быть родителем для новых объектов, если это удобно. Просто ради выражения общности новые объекты не создают.
ВВ>Или я что-то не понимаю, или ты предлагаешь вариант, при котором полиморфизм накроется медным тазом.
ВВ>>var f = fun() x++;
ВВ>>var f = fun(x) x++;
ВВ>>var f = fun(x, y) x + y;
ВВ>>
ВВ>>начинает мне казаться вполне разумным.
T>Конечно, он подходит к остальному.
На самом деле тут есть два соображения:
1. Синтаксис function expression и function statement должен быть однообразным. Т.е. в данном случае:
var f = fun(x) x++;
var f = fun(x) { x++; }
2. При выборе синтаксиса надо учитывать тот факт, что в языке попросту нету других возможностей объявления функции. Т.е. как бы ни хорош бы синтаксис C# в таком вот виде:
x => x++;
мне кажется он не подходит как единственный способ объявления функции, ибо этот самый lamda operator => может попросту теряться в коде. Ключевое слово здесь все же удобней.
T>Для парсера поле Player1 = new : User { Uid = 0 } и поле Created = new : Datetime { Year = 2010, Month = 2 } имеют одинаковый тип object, да?
Да, конечно. Есть только стандартные типы: Integer, Real, Boolean, String, Object, Function...
T>Поскольку объект, это не просто набор значений, а словарь, то шаблон таки несёт в себе контракт в виде имен этих первоначальных значений.
Я пытался показать, что контракт в виде набора имен не несет никакой пользы. По крайней мере, если учитывать текущую архитектуру. Можно сказать, что "по умолчанию" у любого объекта содержится поле с любым названием значение которого равно null.
var obj = new {};
cout obj.Name; //null
T>Я понял идею насчёт шаблона, но из-за словаря не получится отделить значения от имён.
А я не понял, что значит отделить значение от имени
T>Допустим, будет шаблон Fun = { Name = "", Expr = "", LexParent = "" }. T>Очевидно, любой объект, созданный по этому шаблону имеет поле Name. Вот о каком контракте речь.
Нет, любой объект созданный по этому шаблону имеет поле Name, значением которого является пустая строка. Именно это и важно.
Любой объект, созданный без шаблона, и так имеет как бы виртуальное поле Name, значением которого является null.
Шаблон лишь устанавливает значение, не поле.
T>Понятно, шаблон это имутабельный объект и наследоваться можно только от шаблонов. Ну я и говорил, что это классы.
Если ты хочешь проводить аналогию, то шаблон это константа:
const int I4 = 0x80;
var i = I4;
Это код родственнен:
var t = template { I4 = 0x80 };
var i = new : t {};
Классы же обычно используются не для того, чтобы задавать значения по умолчанию, а чтобы задавать контракт.
Хотя видно, что эта идея с template не отличается самоочевидностью. Фактически хотелось упростить создание объектов, т.е. реализовать некие конструкторы что ли, при этом не вводить какие-либо "статические" объявления, конструкции, классы...
Что еще можно сделать?
ВВ>>Т.е. чтобы было видно по крайней мере, какие конкретно данные ты используешь при создании.
T>>>В Foo аттрибуты тоже поменяются потому что их не меняли в Foo.
ВВ>>Ну уверен, что понял. Если Bar — базовый, а Foo — его потомок, то когда мы меняет значение в Bar, то оно поменяется и в Foo? А наоборот?
T>А наоборот не поменяется. T>И после того, как в Foo поменяли поле, изменение его в базовом объекте не произведёт эффекта на поле Foo. T>Самый близкий аналог такого поведения — это копия объекта на STM. T>http://en.wikipedia.org/wiki/Software_transactional_memory
Гм, т.е. если хочу создать объект, полностью независимый от прототипа (которым у нас является другой объект, живущий ровно по тем же законам, что и наш), то мне придется вручную пробежаться по всем его полям и переназначить их значения, чтобы они не дай бог не поменялись, если поменялся родитель?
Мне как раз хотелось бы избавиться от такого поведения. Мне оно в том же ДжаваСкрипте кажется весьма запутывающим.
T>Что именно угрожает полиморфизму?
Отражение изменений в Bar на Foo и изменений в Foo на Bar. Но я, видимо, просто неправильно тебя понял.
ВВ>2. При выборе синтаксиса надо учитывать тот факт, что в языке попросту нету других возможностей объявления функции. Т.е. как бы ни хорош бы синтаксис C# в таком вот виде:
ВВ>
ВВ>x => x++;
ВВ>
ВВ>мне кажется он не подходит как единственный способ объявления функции, ибо этот самый lamda operator => может попросту теряться в коде. Ключевое слово здесь все же удобней.
Извини за тролль, но синтаксис 'x = 90' не подходит как единственный способ изменения значения переменной. Нужно ключевое слово let (или change/set/update).
Чтобы что-то в коде не терялось придумали подсветку синтаксиса.
T>>Поскольку объект, это не просто набор значений, а словарь, то шаблон таки несёт в себе контракт в виде имен этих первоначальных значений.
ВВ>Я пытался показать, что контракт в виде набора имен не несет никакой пользы. По крайней мере, если учитывать текущую архитектуру. Можно сказать, что "по умолчанию" у любого объекта содержится поле с любым названием значение которого равно null.
Ясно, это всё меняет.
T>>Я понял идею насчёт шаблона, но из-за словаря не получится отделить значения от имён.
ВВ>А я не понял, что значит отделить значение от имени
Тупл (10, 20) имеет значения, но не имеет имён.
Можно прочитать как Point { X = 10, Y = 20 }, а можно прочитать как Time { Hour = 10, Minute = 20 }.
ВВ>Хотя видно, что эта идея с template не отличается самоочевидностью. Фактически хотелось упростить создание объектов, т.е. реализовать некие конструкторы что ли, при этом не вводить какие-либо "статические" объявления, конструкции, классы... ВВ>Что еще можно сделать?
Как насчёт const? Числовые и строковые константы тоже полезны, а тут заодно одинаковый синтаксис будет.
T>>А наоборот не поменяется. T>>И после того, как в Foo поменяли поле, изменение его в базовом объекте не произведёт эффекта на поле Foo. T>>Самый близкий аналог такого поведения — это копия объекта на STM. T>>http://en.wikipedia.org/wiki/Software_transactional_memory
ВВ>Гм, т.е. если хочу создать объект, полностью независимый от прототипа (которым у нас является другой объект, живущий ровно по тем же законам, что и наш), то мне придется вручную пробежаться по всем его полям и переназначить их значения, чтобы они не дай бог не поменялись, если поменялся родитель?
Да. Ты просто описал горький синтаксис.
На самом деле должно ли быть создание независимой копии явным (а ссылка по-умолчанию) или создание ссылки явным (а копия по-умолчанию) — каждый язык даёт свой ответ на этот вопрос и тут вряд ли можно сказать, что какое-то решение точно неудачное. В шарпе, например, насколько мне известно, struct копируются, а объекты ссылаются.
Но у object может быть метод copy или ещё какое-нибудь средство языка, создающее независимую копию без гемора.
ВВ>Мне как раз хотелось бы избавиться от такого поведения. Мне оно в том же ДжаваСкрипте кажется весьма запутывающим.
Ну, это прототипное ООП. Ты можешь его вводить в свой язык или нет.
Есть мнение, что такое поведение более близко натуральному человеческому мышлению (то есть мышлению человека, мозг которого не насиловали сотнями противоречивых програмерских парадигм, синтаксисов и пр.), потому что определяет новые объекты *относительно* (то есть указывается только разница) уже существующих.
Я не хотел бы комментировать это мнение, но наследование объектов без классов мне нравится.
Здравствуйте, Temoto, Вы писали:
T>Извини за тролль, но синтаксис 'x = 90' не подходит как единственный способ изменения значения переменной. Нужно ключевое слово let (или change/set/update). T>Чтобы что-то в коде не терялось придумали подсветку синтаксиса.
Тебе был бы удобен язык, в котором все функции объявлялись только как x => x++?
ВВ>>А я не понял, что значит отделить значение от имени T>Тупл (10, 20) имеет значения, но не имеет имён. T>Можно прочитать как Point { X = 10, Y = 20 }, а можно прочитать как Time { Hour = 10, Minute = 20 }.
А зачем отделять значения от имен? Я чего-то не понимаю не нужно имен — используй списки:
var f = fun => [10, 20];
ВВ>>Хотя видно, что эта идея с template не отличается самоочевидностью. Фактически хотелось упростить создание объектов, т.е. реализовать некие конструкторы что ли, при этом не вводить какие-либо "статические" объявления, конструкции, классы... ВВ>>Что еще можно сделать? T>Как насчёт const? Числовые и строковые константы тоже полезны, а тут заодно одинаковый синтаксис будет.
Надо подумать.
ВВ>>Мне как раз хотелось бы избавиться от такого поведения. Мне оно в том же ДжаваСкрипте кажется весьма запутывающим. T>Ну, это прототипное ООП. Ты можешь его вводить в свой язык или нет.
Неважно, как это называется в общем-то. Важно придумать удобный механизм, который позволяет решать задачу и не создает неоднозначных или неочевидных ситуаций, которых просто до фига в том же ДжаваСкрипте.
Отсюда первый вопрос — насколько нужна возможность управлять состоянием объекта через его прототип?
Здравствуйте, Temoto, Вы писали:
T>Я не хотел бы комментировать это мнение, но наследование объектов без классов мне нравится.
Собственно говоря, мне вообще class based OOP в динамическом языке кажется излишним. Ибо оно решает те задачи, которые и так решены, благодаря динамике и duck typing-у.
Вот, например, вполне ОО-код:
var Driver = function(car)
{
for (var i = 0; i < 300; i+=10)
{
var res = car.Drive(i);
cout res[1];
if (!res[0])
return;
}
};
var DriveAny = function(speed, limit)
{
return speed > limit ?
[false, "I can't drive over " + limit + " mph!"] :
[true, "I am driving at " + speed + " mph!"];
};
var Car = function()
{
return new
{
Drive = DriveAny(_, 120)
};
};
var SportsCar = function()
{
return new
{
Drive = DriveAny(_, 200)
};
};
cout "*Regular car*";
var regularCar = Car();
Driver(regularCar);
cout "";
cout "*Sports car*";
var sportsCar = SportsCar();
Driver(sportsCar);
Заметь, как функции используются в качестве конструкторов для объектов. Глядя на этот пример, я думаю, не как добавить в язык ООП, а как реализовать механизм, упрощающий конструирование объектов.
T>>Извини за тролль, но синтаксис 'x = 90' не подходит как единственный способ изменения значения переменной. Нужно ключевое слово let (или change/set/update). T>>Чтобы что-то в коде не терялось придумали подсветку синтаксиса.
ВВ>Тебе был бы удобен язык, в котором все функции объявлялись только как x => x++?
Я писал на хаскеле, в котором для объявления функции не нужны ключевые слова. Да, это мега-удобно. Конкретно токен '=>' мне не нравится.
ВВ>>>А я не понял, что значит отделить значение от имени T>>Тупл (10, 20) имеет значения, но не имеет имён. T>>Можно прочитать как Point { X = 10, Y = 20 }, а можно прочитать как Time { Hour = 10, Minute = 20 }.
ВВ>А зачем отделять значения от имен? Я чего-то не понимаю не нужно имен — используй списки: ВВ>var f = fun => [10, 20];
Там выше было про контракты и имена. Забей.
ВВ>>>Мне как раз хотелось бы избавиться от такого поведения. Мне оно в том же ДжаваСкрипте кажется весьма запутывающим. T>>Ну, это прототипное ООП. Ты можешь его вводить в свой язык или нет.
ВВ>Неважно, как это называется в общем-то. Важно придумать удобный механизм, который позволяет решать задачу и не создает неоднозначных или неочевидных ситуаций, которых просто до фига в том же ДжаваСкрипте. ВВ>Отсюда первый вопрос — насколько нужна возможность управлять состоянием объекта через его прототип?
Я не к тому, как это называется, я к тому, что это мм.. не то чтобы широко, но используемая, распространённая техника, а не что-то выдуманное в этом треде.
Насколько нужна такая возможность определяется не объективными факторами (все языки тьюринг-полны и всё такое), а идеологией языка. Поэтому тебе придётся самому ответить на этот вопрос, а потом сделать вывод: удачное было решение или нет.
Но если ты хочешь такой же абсолютный, не привязанный ни к каким реалиям ответ, как и вопрос, то любое неявное изменение состояния это потенциальный баг и минус возможная оптимизация.
T>>Я не хотел бы комментировать это мнение, но наследование объектов без классов мне нравится.
ВВ>Собственно говоря, мне вообще class based OOP в динамическом языке кажется излишним. Ибо оно решает те задачи, которые и так решены, благодаря динамике и duck typing-у. ВВ>Вот, например, вполне ОО-код:
ВВ>
ВВ>var Car = function()
ВВ>{
ВВ> return new
ВВ> {
ВВ> Drive = DriveAny(_, 120)
ВВ> };
ВВ>};
ВВ>
ВВ>Заметь, как функции используются в качестве конструкторов для объектов. Глядя на этот пример, я думаю, не как добавить в язык ООП, а как реализовать механизм, упрощающий конструирование объектов.
Здравствуйте, Temoto, Вы писали:
T>Я не к тому, как это называется, я к тому, что это мм.. не то чтобы широко, но используемая, распространённая техника, а не что-то выдуманное в этом треде.
Prototype based OOP бывает в разных ипостасях, на ДжаваСкрипте мир клином не сошелся. Потом, честно говоря, у меня есть глубокое подозрение, что большинство пользователей этого языка попросту не используют всех его возможностей, в т.ч. и прототипы. Разве что последнее время с популяризацией ряда библиотек наметился некоторый сдвиг. А это может означать, что его концепции не до конца проверены на практике.
Я вот часто вижу в них площадку для потенциального багодрома.
T>Насколько нужна такая возможность определяется не объективными факторами (все языки тьюринг-полны и всё такое), а идеологией языка. Поэтому тебе придётся самому ответить на этот вопрос, а потом сделать вывод: удачное было решение или нет. T>Но если ты хочешь такой же абсолютный, не привязанный ни к каким реалиям ответ, как и вопрос, то любое неявное изменение состояния это потенциальный баг и минус возможная оптимизация.
Меня интересуют просто идеи и критика. А выдумано ли оно в этом треде или в каком-то другом n-лет назад — не суть важно.
Поэтому все просто — задача не что-то выдумать, а просто подумать, какой механизм в принципе нужен и какой был бы удобен, скажен, лично тебе. Достаточно ли тебе просто конструкций для создания объектов ex nihilo? Или же нужен еще какой-то механизм?
T>>var obj = { Speed = 120 }; T>>Куда ещё проще?
ВВ>Ты имей в виду, что пример очень упрощен. У объекта может быть десять полей-функций, а у нам нужно поменять только одну. Придется писать: ВВ>Неудобно и неочевидно.
Ты сказал "упрощающий конструирование объектов", я тебе привёл пример наиболее простого конструирования.
Нужны копирующие конструкторы? — их тоже можно сделать.
Например, так:
var newobj = oldobj with { Speed *= 1.5, Name = "Fast" }
ещё можно подумать о множественном наследовании. Но это фичеризм. Какие задачи должен решать язык?
Кроме того, синтаксис может эволюционировать с появлением новых задач. Если сделаешь систему макросов, как в Lisp или Nemerle, то сможешь эксперементировать с синтаксисом без изменения интерпретатора.
ВВ>Prototype based OOP бывает в разных ипостасях, на ДжаваСкрипте мир клином не сошелся. Потом, честно говоря, у меня есть глубокое подозрение, что большинство пользователей этого языка попросту не используют всех его возможностей, в т.ч. и прототипы. Разве что последнее время с популяризацией ряда библиотек наметился некоторый сдвиг. А это может означать, что его концепции не до конца проверены на практике. ВВ>Я вот часто вижу в них площадку для потенциального багодрома.
Ну, потенциально баги записаны везде, где не проверено их отсутствие. Один способ уменьшить их количество — уменьшить выразительность языка, другой способ — увеличить количество проверок. Как пользователю языка мне больше нравится второй.
Это не относится только к прототипному ООПу, конечно, просто потенциальным багодромом можно назвать всё что угодно.
T>>Насколько нужна такая возможность определяется не объективными факторами (все языки тьюринг-полны и всё такое), а идеологией языка. Поэтому тебе придётся самому ответить на этот вопрос, а потом сделать вывод: удачное было решение или нет. T>>Но если ты хочешь такой же абсолютный, не привязанный ни к каким реалиям ответ, как и вопрос, то любое неявное изменение состояния это потенциальный баг и минус возможная оптимизация.
ВВ>Меня интересуют просто идеи и критика. А выдумано ли оно в этом треде или в каком-то другом n-лет назад — не суть важно.
ВВ>Поэтому все просто — задача не что-то выдумать, а просто подумать, какой механизм в принципе нужен и какой был бы удобен, скажен, лично тебе. Достаточно ли тебе просто конструкций для создания объектов ex nihilo? Или же нужен еще какой-то механизм?
В начале были задачи, потом инструменты.
Для создания — конечно достаточно, причём слово new — лишний мусор.
Для создания копий — точно недостаточно.
Если создание копий с какими-то отличиями я ещё вижу, как более менее самособой разумеющуюся необходимость, то дальше уже надо пытаться что-то писать на языке и смотреть чего не хватает.
Здравствуйте, Temoto, Вы писали:
T>ещё можно подумать о множественном наследовании. Но это фичеризм. Какие задачи должен решать язык? T>Кроме того, синтаксис может эволюционировать с появлением новых задач. Если сделаешь систему макросов, как в Lisp или Nemerle, то сможешь эксперементировать с синтаксисом без изменения интерпретатора.
Ну скажем так, я нахожу любое чужое мнение по данному вопросу полезным, т.к. мой собственный взгляд все же сильно зашорен долгим опытом работы с языками определенного рода. А задачи, которые должен решать язык, довольно просты:
1. Мой собственный чисто исследовательский интерес
2. Embeddable script для .NET с удобными интерфейсами для создания хостов
Это, конечно же, не исключает и других задач.
Для #2 мне нужно определиться с маршаллингом, а соотв. и с тем как должны быть представлены объекты.
Касательно prototype based OOP, то на мой взгляд prototype based просто означает, что новый объекты у нас создаются путем клонирования старых. Все. Остальное — уже детали реализации конкретных языков, вроде ДжаваСкрипта.
В этом плане даже то, что уже есть в версии, которую я выкладывал, уже есть "наивная" поддержка P-OOP (т.к. шаблоны на самом деле необязательны, и "отклонироваться" можно и от обычного класса).
Мне не нравится путь ДжаваСкрипта и компании, и я просто рассуждаю об альтернативах. По большому счету даже те же шаблоны — не столь уж и оригинальное решение. Вот, сейчас посмотрел — есть MOO, где используется очень схожий подход с рид-онли клонируемыми объектами.
T>>ещё можно подумать о множественном наследовании. Но это фичеризм. Какие задачи должен решать язык? T>>Кроме того, синтаксис может эволюционировать с появлением новых задач. Если сделаешь систему макросов, как в Lisp или Nemerle, то сможешь эксперементировать с синтаксисом без изменения интерпретатора.
ВВ>Ну скажем так, я нахожу любое чужое мнение по данному вопросу полезным, т.к. мой собственный взгляд все же сильно зашорен долгим опытом работы с языками определенного рода. А задачи, которые должен решать язык, довольно просты:
ВВ>1. Мой собственный чисто исследовательский интерес
То есть задачи нет.
Тогда и решения быть не может.
ВВ>2. Embeddable script для .NET с удобными интерфейсами для создания хостов
Это называется Conscript, оно уже есть и довольно удобное.
ВВ>Это, конечно же, не исключает и других задач. ВВ>Для #2 мне нужно определиться с маршаллингом, а соотв. и с тем как должны быть представлены объекты.
ВВ>Касательно prototype based OOP, то на мой взгляд prototype based просто означает, что новый объекты у нас создаются путем клонирования старых. Все. Остальное — уже детали реализации конкретных языков, вроде ДжаваСкрипта. ВВ>В этом плане даже то, что уже есть в версии, которую я выкладывал, уже есть "наивная" поддержка P-OOP (т.к. шаблоны на самом деле необязательны, и "отклонироваться" можно и от обычного класса). ВВ>Мне не нравится путь ДжаваСкрипта и компании, и я просто рассуждаю об альтернативах. По большому счету даже те же шаблоны — не столь уж и оригинальное решение. Вот, сейчас посмотрел — есть MOO, где используется очень схожий подход с рид-онли клонируемыми объектами.
Все-таки дотнет — кроссплатформенная технология.
)
не нужно имен — используй списки: