Встречайте ECMAScript4. Обзор нового стандарта сетевого языка

Следующая версия AS будет ES4?

AS3 - это реализация раннего черновика ES4. Адобы обещали придерживаться стандарта.

Реально же получается, что они не только его придерживаются, но и влияют на его создание.

Завтра я достаю из загашника черновик, где об этом подробно написано.

Ориентированные на производительность типы данных (такие как Vector) малой ценой избавляют от излишеств слишком общих типов данных — таких как Array.

Кстати а есть ли уже готовые реализации стандарта ECMAScript4? Хоть в ввиде прототипа?

Ориентированные на производительность типы данных (такие как Vector) малой ценой избавляют от излишеств слишком общих типов данных — таких как Array.

Это как?
С каких это пор Array стал слишком общим типом?

Вадим, имеется в виду, что тип Array содержит нетипизированные значения. Vector решает эту проблему, типизируя их. Возможно, я перевел эту фразу слишком вольно:

Performance-oriented data types like Vector remove the overhead of very general data types like Array...

— поправьте, если ошибаюсь.

Кстати а есть ли уже готовые реализации стандарта ECMAScript4? Хоть в ввиде прототипа?

ActionScript3 реализует черновой вариант. Почти все перечисленные под заголовком "Краткий обзор характеристик ES4" возможности уже есть в ActionScript3.

Рост, а можно пример инициализации и заполнения Vector-а типизированными значениями?
Ато я далек от ActionScript, и слабо себе это представляю.

Рост, а можно пример инициализации и заполнения Vector-а типизированными значениями?
Ато я далек от ActionScript, и слабо себе это представляю.

Вадим, класса Vector в ActionScript, к сожалению, пока нет. А выглядеть это будет вот так:

//создает Вектор, содержащий занчения типа Point

var pointVector:Vector = new Vector<Point>

Наколько я знаю, аналогичная констукция есть в C#, называется List. Так?

Реализация типизированных массивов в Java:
Card[] cards = new Card[36];
Инициализируется и сохраняется в переменной cards массив состоящий из 36 элементов типа Card. Изначально значениями этих элементов будет null.

Привет всем!
Мне вот эта фраза - "Указание типов также позволяет компилятору отказаться от проверки типов на этапе выполнения", очень "понравилась", только в обратном смысле.
Короче, валите все на программиста, пусть все это дерьмо за компилятор разгребает.
Может скажешь заодно, что от этого сама программа будет быстрей или лучше работать?
ECMA 262 (JavaScript 1.5) - в этом смысле намного проще и лучше.
Не надо путать концепцию OOП с типизацией и вешать такую лапшу на уши.
И если все эти приваты, инты да протекты, да еще всякую дрянь собрать в одну кучу, количество строк составит неплохую программу.
Поэтому я лично, никаких приемуществ не вижу.
Посмотри новый язык nesla-0.9.0, он почти копия ECMAScript и найди там типизацию.
Может они дураки по твоему?
Посмотри язык, который используется в GameMaker - это тоже ECMA. Где ты там типизацию увидишь?
А люди, между прочим, на этом делают очень даже классные вещи.
Я бы мог привести еще с 10 примеров, где эта идея типизацией - полная чушь.
Так что, на самом деле, не все так красочно, как ты это тут описал и разрисовал.
Удачи.

2index - банально, но не стоит впадать в крайности, то всем статику подавай, то давайте убьемся об стену с динамикой. а не лучше ли иметь возможность и статику пользовать и любимый многими duck typing? в этом смысле я поддерживаю ecma4 подход. если появится хоть часть этого дела в as4 - буду рад.

Вообще-то там должно быть не "компилятору", а "виртуальной машине".
AS1.0 / AS2.0 типизация была не строгой.
Можно было описать переменную как Number, а присвоить значения типа String.
Соответственно, каждое значение таскало вместе с собой информацию о типе. И при вызове методов/выполнении операторов виртуальной машине надо было сперва посмотреть тип операндов, а потом уже думать, что с ними делать.
Например: C = A + B;
Если A или B типа String, то будет операция конкатенации. Если A и B типа Number, то будет операция сложения. И определить ху из ху и что делать с A и B можно было только на этапе выполнения.

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

А по поводу того, что строгая типизация требует дополнительных буковок.
Эти "лишние" буковки очень окупаются. Поработай в Intellij IDEA или, если касаемо AS, то в FDT и ты поймёшь как указание типа облегчает дальнейшую жизнь, а неуказание - усложняет.

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

А вот если у тебя проектик, в котором хотя бы двадцать-тридцать классов, то без типизации запаришься его отлаживать. Да и писать сложнее - автоподстановки кода толковой не будет.

Кстати, в HaXe очень прикольный компромис в плане типизации. Если явно тип переменной не указан, то будет назначен тип первого присвоенного значения.
Т.е. s = "Hello" автоматически означает, что s будет типа String.

2Dan - это уже крайность статики :) Я вот тоже пишу на java в Idea и понимаю о чем ты.
Но в последнее время рад пользовать Groovy. Все же есть прелесть и в динамических языках, особенно когда какой нибудь DSL заваять нужно или сплошные итераторы, то есть там где действительна нужна динамика. И поддерживаю в том, что язык должен быть удобен для IDЕ, только это должна быть не сама-цель, и как это путь к ограничению средств программирования и к разбуханию кода, а бонус. То есть идеал для меня - хочу прелести автоматизации, рефакторинг и подстановку - указываю тип, там где нужно сделать, чтото "волшебное", трюк, пользую статику.

> трюк, пользую статику.
имел ввиду пользую динамику, конечно :)

Ахренеть, какую теперь дурь нужно будет брать, чтоб на AS4 писать?
Новость, на самом деле, замечательная!
Жду: + AS4

Может поступят проще: возьмут Java (вместе с JVM) и объявят это новым стандартом AS4.
(Ну может топориком поработают как обычно, чтобы уж не так много весила).

Привет Dan.
Ты совершенно прав, на счет "виртуальной машины"(интерпретатора), а не компилятора.
Но по поводу типизации и другой чепухи, которая якобы чему-то способсвует ...
Приведу пару простых аргументов на примере С#, который как раз всем этим дерьмом напичкан:
- замечал ли ты большую скорость этих программ?
- а может эти программы отличаются особой защитой?
Если бы их целью, было просто расширить классы языка, недостаток которых ощущаешь, особенно при работе с WSH, я бы с этим согласился на все 100%.
Удачи.

2index - "приведу пару аргументов" - в смысле аргументы как произнесение умных слов C# и WSH? ;)
я вот в виртуальной машине .Net не особо пониманию, но полагаю (так как истоки в JVM), и защищены - песочница, подписи, безопасность на уровне исполнения и класс-лоадеров, и скорость - смотрел бичмарки, очень шустрый язык (среда исполнения).

"замечал ли ты скорость этих программ" - блин, не смешите мои седые ....

фсе, хорош флеймить, пошел работать.

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

index™, спасибо за дельные замечания, но не забывай: вежливый ответ звучит всегда убедительнее.

Мне кажется, тебя одолевают эмоции. Но кодинг - это не та область, где эмоции помогают. Скорее, наоборот.

Отвечу подробнее на твои коментарии - сейчас нужно работать...

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

Рост!
Конечно прошу прощения, ежели что.
Я вообще твой ресурс уважаю,считаю его крайне полезным и уважаю всех тех, кто здесь находится.
Даже не вопрос.
Ты прав, по поводу эмоций, загрызли собаки, но это все к ES4.

Да все окей. Кстати, Николя Канасье, автор языка haXe, тоже отреагировал на событие.

да здравствуют "var" и "unknown"!

2index

Я вот другой пример приведу.

Берём AS1.0, язык, где рулит динамика (хотя её чуть-чуть меньше, чем в javaScript, но всё равно).
Берём AS3.0, язык, где почти рулит статика. Ну, по крайней мере, её стало куда больше, чем раньше.

И на том и на другом пишем махонькую программку, которая просто в цикле увеличивает переменную на 1.

Разница в скорости - в 600 раз.

Почему такой разрыв? Потому что:
1. тип int быстрее, чем Number
2. компилятор знает, что мы работаем именно с int и заранее строит код, который заточен именно под int
3. виртуальная машина работает не как интерпретатор, а как Just-In-Time Compiler, который сперва переводит байт-код в нативный код процессора, а потом уже выполняет.

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

Я сам долгое время тащился от динамики. Основная причина тому - лень. Ну лень мне описывать тип, я лучше напишу просто var и всё. А может и его писать не буду - нихай будет глобальная переменная. Лень писать новый класс - создам объектики через фигурные скобочки.
Вот типа такого:
[code]obj = {x: 100, y:100, move:function(dx, dy){x+=dx;y+=dy}};[/code]
Вторая причина - свобода. Можно создавать поля на лету, можно обращаться к полям, которых нет, можно вызывать методы у null и никто тебе ничего плохого не скажет (ни компилятор, ни среда выполнения), можно перемешать в массиве числа, строки, объекты и другие массивы, можно украсть метод load у LoadVars и приделать его своему объекту, можно почти всё.

Но поделав всякие Flash-игрушки, я понял, что свобода имеет оборотную сторону: отлаживать такой вольнодумный код - сплошная мука.

А однажды поработал в IDEA и понял, что я раньше как-то неправильно жил.
Оказалось, что типы-то нужны не только для того, чтобы компилятор создавал более оптимальный исполняемыйкод, но и для того, что среда разработки начинала писать исходный код за меня (не полностью, конечно:) ).

Правильно описанная переменная позволит мне не писать методы и свойства самому, а выбрать из списка после нажатия точки. А модификатор private, который я раньше так не любил, позволяет выкинуть из этого списка лишнее. А throws, которого я вообще я боялся, позволяет сразу сгенерировать конструкцию try...catch буквально в два клика.
И моя лень повернулась в другую сторону.

Сейчас пишу на AS2.0 в FDT. И вписываю типы везде, где только можно именно из-за своей лени.
Например, написал я что-нить типа:
[code]var card = deck.attachMovie("card","card"+i,i)[/code]
Дальше мне надо проинициализировать поля, вызвать методы... А мне лень их руками писать, потому что можно и пропустить буковку или местами случайно переставить, или ещё какую-нибудь опечатку допустить...
И её меняю вот так:
[code]var card:Card = Card(deck.attachMovie("card","card"+i,i))[/code]
И всё! Моя ленивая душа довольна.
Дальше мне надо напечатать только:
[code]card.[/code]
и выбрать нужное свойство или метод из списка.

И ещё я теперь очень не люблю Array в AS именно за то, что его элементы нетипизированные. Я бы лучше в одном месте в программе сказал: это будет массив чисел, а это будет массив клипов, и потом бы радоовался автоподстановке и тому, что редактор показывает мне, где я накосячил.
На данный момент массивы, на мой взгляд - самое слабое место в AS.

Dan™.
Возможно ты в чем то и прав, со одной стороны.
Но вот вопрос, почему в свое время, флеш так быстро вытеснил явовские аплеты?
Что способствовало ему стать таким популярным за короткое время?
Только векторная анимация?
Я не думаю, что появись он сразу с AS3, все произошло именно так.
Как сказал один очень мудрый человек: "Я не люблю Microsoft, но если бы мне нужно было выбирать между Windows и Linux, я бы непременно выбрал Windows".
Почему он так сказал, как сам думаешь?

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

Но сейчас флеш годиться для чего-то большего, чем просто баннер/шапка/менюшка/заставочка.
И то, что раньше создавало простоту, теперь создаёт лишние сложности.

Кстати, в то время, когда я тащился от динамики, я написал вот такой вот "Hello, world":

_root.createTextField("q",0,0,0,200,30);
function __resolve(s) {return s}
e = {print: function(s) {_root.q.text = s}}

e["print"](hello+", "+world);

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

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

2index,

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

2Dan,

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

вот так -

library.books?.pages.grep{it?.text =~ /flex/}*.print()


или -


if(library.books != null)
{
for(Book book in library.getBooks())
{
for(Page page in book.getPages())
{
Pattern pattern = Pattern.compile(".*flex.*");
if(pattern.match(page.text).matches())
{
page.print()
}
}
}
}


а далее начинается, ага, много кода, а нужно тут бороться со сложностью, ага, выделим это дело в метод, хотя нет! лучше сделаем инкапсуляцию по полной и выделим в класс. А может это еще пару раз понадобится? ага, давай как сделаем рефакторинг (с дублированием нужно бороться) и забабахаем мега-универсальный метод. Сделаем, откинемся на спинку кресла и скажем - "я крут, я гуру".

хм, как бы обернул в ... что не так?

Жду типизированных массивов/списков как никто другой.

2Евгений Потапенко™.
2Dan™.
Все это называется "валить с больной головы на здоровую".
Вы не понимаете или не хотите понимать о чем я говорю.
А говорю я о том что сам синтаксис усложняться не должен, нужно совершенствовать компилятор и плеер.
Введение типизации - это усложнение языка.
Время покажет кто прав.

2index
А каким образом типизация усложняет синтаксис?

Вот смотри ситуацию:

var a = Math.random()>0.5 ? 1 : "Hello";
И как компилятор догадается, какого типа у меня должна быть переменная a?
А самое главное, откуда компилятору знать, правда ли я хочу в одну и ту же переменную помещать числа и строки, или я просто кавычки забыл написать?

И вообще, здоровая голова - это голова программиста.
Соответственно, он должен иметь как можно больше контроля над программой.
Если я знаю, что в массив надо помещать только числа и причём только целые, то я хочу иметь возможность написать что-нибудь такое:
var a:Array;

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

А идеальный вариант - как в Делфи:
var a:array[0..1023] of integer;
чтобы заодно были проверки на выход за пределы массива.
Если размер массива заранее неизвестен, тогда уже так:
var a:array of integer;
Если и тип заранее неизвестен, то так:
var a:array of variant;

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

2Евгений Потапенко

Учитывая, что динамика всегда выполняется на интерпретаторе, можно забубенить класс-интерпретатор и затем делать так:

DynamicSuperPuperInterpreter.execute("#0.get.books?.pages.grep{it?.text =~ /flex/}*.print()", library);

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

P.S.

Когда-то, используя все чудеса динамики в AS 2.0, я написал класс, заменитель mx.utils.Delegate (и всяких других, сделанных "по мотивам").
Если обычный Delegate используется вот так:
btn1.onPress = Delegate.create(this, this.onButton, 1);
btn2.onPress = Delegate.create(this, this.onButton, 2);
btn3.onPress = Delegate.create(this, this.onButton, 3);
то мой использовался вот так:
btn1.onPress = new Call(this).onButton(1);
btn2.onPress = new Call(this).onButton(2);
btn3.onPress = new Call(this).onButton(3);

Буковок меньше, смотрится красивее, для новичков - ещё и более интуитивно-понятно.
Но вот компилятору и редактору приходиться вкалывать успокоительное, чтобы не кричали об ошибках.
В результате - вообще никакой проверки ошибок. Допустил опечатку - сиди и сам ищи.

Блин. Съел скобочки.
Должно было быть так:
var a:Array<int>

Привет Dan™.
- "И как компилятор догадается, какого типа у меня должна быть переменная a?"
А почему бы комплятору не проанализировать твой код и самому не расставить куда надо эти типы? Ты об этом не думал? Разве такое решение нереально?

-"И не надо молиться на компилятор и использовать всякие мегахаки, которые позволяют "подсказать" компилятору ...."
Не надо на него молиться и ничего ему подсказывать тоже не надо. Раз он не умеет сам думать, значит он далек от совершешенства и работать надо именно над этим.

Они же поступают совершенно иначе, и типизация - это лишь часть айсберга.

Посмотришь, что в конечном счете, синтаксис флеша, по сложности, мало чем будет отличаться от C# или Java. И скорее всего, 90% остановятся на 8 версии.
C практической точки зрения, лучше потратить время и изучить эти языки, т.к. возможностей у них гораздо больше,нежели у флеш.
Флеш развивался только из-за простоты, которая способствовала его массовости, а не из-за элитарности.
Так что теперь он вряд ли будет доминировать над теми же SilverLight или Java Applet или еще ...
Удачи.

> А почему бы комплятору не проанализировать твой код и самому не расставить куда надо
> эти типы? Ты об этом не думал? Разве такое решение нереально?

Думал. И предлагал тебе тоже подумать. Но ты не стал :(

Итак, вот ещё раз код на засыпку:

var a;
var b;
var c;
var d;

if (Math.random() else a = "Hello";

b = {};

c = a+a;

b[a] = c;

for (var i in b) {
d = b[i];
}

Теперь объясни, как компилятору узнать тип переменной d?
Если переменная a у нас то ли целое, то ли строка, переменная с тоже целое, то ли строка.
Переменная b - какой-то объект с динамически добавляемыми свойствами неизвестного типа, к которым мы обращаемся косвенно.

Без run-time типизации здесь не обойтись, если только ты не подскажешь способ, как запрограммировать дар пресказания.

А run-time типизация - это гибко, но медленно, и не позволяет найти ошибки на этапе компиляции, а значит потребуется утомительная отладка.

Ты когда-нибудь тратил 3 часа только из-за того, что поставил скобочку не в том месте, а копилятор это проигнорировал? Я тратил. Поэтому я - за строгие языки.

Хмм... Что-то тег <code> работает как-то не так.

Поправочка:

if (Math.random()<0.5) a=1;
else a="Hello";

2Dan™
Возможно мы не совсем друг друга понимаем, я говорю об этом:

var arr:Array=new Array(1,2,3);
Спрашивается, зачем тыкать "var arr:Array", а не просто "var arr=new Array(1,2,3);"?
Компилятор не может отличить "Array" от "TextField"?

2Dan™
Этот лишь 1 пример, 1 звено той цепочки, которая в кончечном счете приводит к ненужному усложнению языка.
И если раньше человек мог открыть флеш и что то, пусть даже простенькое, да и написать, то теперь он как откроет AS3, так и закроет.
Простота вызывала интерес к флешу, а уже потом приходили и мастерство, и сложные проекты.
Но только не наоборот.
Ты же смотришь и рассуждаешь только со своей "колокольни".

2index

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

В AS2/AS3 на указанный пример могу привести контрпример:

var arr = new Array(1,2,3);
...
var n = arr[1];


И всё! Тип элементов массива нам неизвестен, а значит выражение arr[1] нетипизированное, а значит n тоже останется без типа.
Ты можешь возразить: а пускай, дескать, копилятор посмотрит, что в массиве у нас 1, 2, 3.
А низя компилятору делать такие далеко идущие выводы.
Видишь, я оставил в примере троеточие? В том месте может быть код, который переиначивает массив как угодно, так что нет никакой гарантии, что arr[1] - это именно число.

А вот если бы можно было сделать так:
var arr:Array<int>=new Array(1,2,3);
...
var n = arr[1];

То компилятору сразу всё становится ясно. А всего-то дописали 5 буковок!

По поводу простоты... Насколько я понимаю, никто не обязывает всё описывать.
Нравиться мало печатать, много отлаживать - оставляй всё нетипизированным.
Ломает писать private или public - ну и не пиши, будет модификатор по умолчанию.

А если любишь поиск ошибок перекидывать на компилятор - будь добр, описывай нормально.

2Dan™

Я посмотрел на HaXe, и как только увидел это:

'static var name : String = "MyString";',

сразу закрыл, дальше смотреть нет смысла.

"А низя компилятору делать такие далеко идущие выводы."
Это почему нельзя? Ты пробовал сделать такой компилятор?
А вот мне кажется, как раз то и льзя...
Во всяком случае, попробовать стоит.

[b]2index[/b]

> static var name : String = "MyString";

Это "полноценная" запись.

Никто не мешает написать:

> static var name = "MyString";

Будет упрошённый эквивалент того же самого. Кстати, сам Николя не особо любит типы писать, компилятору доверяет.
А вот static тут нужон. Если static убрать - совсем другая штука получиться.
Но увы, некоторых пугают незнакомые слова... Я сам его раньше боялся - когда не понимал смысла.

> Это почему нельзя? Ты пробовал сделать такой компилятор?

Расскажи мне алгоритм однозначного определения типа по исходному коду, и я попробую его реализовать. А ты заодно получишь много-много денег и +1 апгрейд учёной степени.
Но я уверен, что нельзя, хотя я в этом вопросе и не специалист: комплятор писал всего один раз и с очччччень простым и лаконичным синтаксисом. Правда, из-за этого страдала читабельность, но ведь главное - это простота, да?

[сарказм]Кстати, многих ещё пугают сообщения об ошибках. Было бы лучше, если бы компилятор вообще никогда не сообщал об ошибках, а сам пытался бы их исправить. Круто ж было бы, да?[/сарказм]

2Dan™
"Расскажи мне алгоритм однозначного определения типа по исходному коду".
Такой алгоритм уже есть, а сам компилятор будет через ....
Но не для C#,AS3 или ES4 и им подобных - это уже вчерашний день.
У тебя будет возможность "почувствовать разницу".
Да, к стати, не надо валить в одну кучу: "проверку синтаксиса" и "компиляцию".
Удачи.

> Да, к стати, не надо валить в одну кучу: "проверку синтаксиса" и "компиляцию".

Оооо. Новый алгоритм позволяет компилировать без синтаксического анализа?
Это действительно обещает быть революцией.

Правда, с подходом "как только я дошёл до... тут же бросил", боюсь, мы так и не увидем этот новый потрясающий компилятор, который сам знает, что корень из четырёх - это целое число.

Но желаю удачи. Особенно в создании IDE под новый мегаязык.

А вот ещё примерчик...

function messUpCompiler(param) {
// тут что-то делаем
}

messUpCompiler(1);
messUpCompiler("Hello, world");
messUpCompiler([1,2,3]);
messUpCompiler({x:1, y:2});
messUpCompiler(new Date());
messUpCompiler(function() {});

Внимание, вопрос: что сделает компилятор?

1. Выдаст сообщение type mismath уже на втором вызове, так как параметр решили делать целочисленным (с помощью первого вызова).

2. Нормально прожует. Тип param будет определяться в процесе выполнения.
Программисту торжественно вручается typeof() - пусть сам решает как функции на каждый тип реалигировать.

3. Прозрачно перегрузит функцию messUpCompiler, создав 6 копий этой функции, отличающихся типом аргумента, и скомпилирует каждую из них, оптимизируя под конкретный тип.

// Ответы

1. Полная фигня. Вызовы функции могут находиться не в одном месте, как в примере, а раскиданы по методам и по разным классам. В результате неясно, кого считать первым "эталонным" вызовом.

2. Именно так происходит в AS1.0, AS2.0, JavaScript и в сотнях других скриптовых языков.
Гибко, но уменьшает скорость работы приложения + дополнительные затраты памяти + велика вероятность сделать ошибку, которую компилятор просто не найдёт.

3. Оптимально с точки зрения скорости выполнения, но слишком большие затраты памяти: метод может запросто дублироваться не 6 раз, а 60 раз или 600 раз - смотря сколько разных типов засунем на вход. Непонятно, что делать, если засунули свосем нетипизированную переменную. Кроме того, есть вероятность ошибки возникающей именно из-за клонирования и специфической работы некоторых клонов, которую вообще будет нереально найти, поскольку клонирование функции скрыто от программиста и повлять он никак не может.

2Dan™

"Оооо. Новый алгоритм позволяет компилировать без синтаксического анализа?"
Где ты видел, что бы я об этом говорил?
Это и коню понятно, что нереально.
А IDE не я создаю, моя роль в этом другая.

FYI: http://progopedia.ru/typing/type-inference/