Хаха... снова Ява снова ООП :p Ява испохабила идею классов и типов на столько, что изза этого теперь рождаются такие споры. В теории категорий сила, а Ява курит в сторонке. Между типами и классами нет ничего общего, и их частичное пересечение - случайность возведенная в степень правила языками для идиотов. :)
Числа - типы, булевые величины - типы, строки в AS3 - вообще не понятно что, тяжелое наследие ECMAScript, так же как и массивы, очевидно. Очевидно, что литералы должны были это как-то выделить / объяснить программисту, но попытка не удалась, и никто этого не понял, а еще хуже, использовал в итоге не правильно, добавив еще литералов "по образцу" не поняв смысл образца...
Тип определяется набором правил применимых ко всем "особям" типа. Класс это фабрика создающая, иногда, однотипные объекты. Заметте, что "особи", я просто лучшего слова не придумал, не обязаны вообще быть объектами, или могут быть объектами разных классов.

ЗЫ. Слава богу AS3 еще не совсем Ява.
:away: нету смайлика :fight: ....

Мне эквипенисуален способ расстановки фигурных скобок. Скажу больше: я работал в компании, где в Java и C++ были разные правила расстановки фигурных скобок и меня ни разу не стошнило.

Так что если Вы считаете, что знаете некий сакральный, самый правильный способ их ставить -- Вам еще многое предстоит. :)

Добавлено через 51 секунду
В слове "C++" Вы допустили 3 ошибки. :)

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

OK, ладно, Ява усугубила и углУбила, если другими словами. Т.с. закрепила эффект :)

Друг мой, Вы традиционно прочитали в моем сообщении то, что там не было написано. И не прочитали то, что было.

Традиционно специально для Вас расскажу второй раз и медленно: мне приходилось работать с таким количеством способов расстановки фигурных скобок, что ни один из них более не вызывает у меня рвотных судорог. Соответственно, IDE у меня настроена на тот способ, который указан в стайлгайде. А в IDEA у меня указан для Java совсем другой способ. И меня это совершенно не беспокоит.

А вера в единственно правильный способ оформления -- это у Вас пройдет.

Добавлено через 3 минуты
Куда уж там усугулять-то? C++ был первым, простите за нецензурное ругательство, "гибридным языком", который и сделал эту концепцию обычной практикой. Java язык на редкость ублюдочный, но тут она не при делах -- сделали "comme il faut"

P.S. В смысле -- не первым гибридным, а первым популярным гибридным.

Странно, что еще никто не упомянул, что на уровне байткода new Object и {} (как и new Array и []) вещи разные, с прикруткой тру пути.

Тупо в качестве примера фигурных скобок и двойных стандартов: http://www.flasher.ru/forum/showpost...27&postcount=8 :)

Добавлено через 5 минут
Вполне нормально, что код разный.

(источник)

Разница в скорости действительно странна (особенно то, кто быстрее), но ничего странного в том, что код разный, я не вижу.

Эта странность объясняется в комментах на джире. Вся фишка в джиттере.

Ссылка из указанной мной статьи, так что я в курсе. Только это не объяснение -- это констатация факта. :)

C++ все еще оставлял лазейку для инакомыслящих, ну, уже хотя бы в виде вседозволенности. Т.е. если сравнивать с историей - C++ - это Окрябрьская революция, а Ява - это 22-53 годы. Можно сказать, что причиной была революция, но могло бы получится и по-другому, а не получилось.

ЗЫ. Я думаю, что если покопать ECMA документацию, то можно докопаться и до ответа на вопрос почему по-разному создаются объекты. Я так подозреваю, что способ с new должен создать все свойства, которые объявили на прототипе, а {} должен создать "без прикрас". Но зачем это нужно, этого уже никто не поймет. К сожалению не первый факт из ECMA сочинений, который вызывает недоумение. А может причина была еще прозаичнее - какой-нибудь представитель компании производящей браузеры на заседании коммитета по особо важным делам поведал о том, что они уже воплотили это в жизнь способом #1, а представитель конкурирующей организации не согласился, т.как они уже воплотили, но способом #2. И, как всегда, чтобы никого не обидеть, решили, что вместо стандарта лучше предложить венигрет.

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


PS Сильно сомневаюсь в необходимости преобразовывать лексемы "Object" и "{}" в разные токены (по сути это один и тот же). Скорее всего так сложилось исторически и разность в производительности пример того, что рефакторингом в Адоби не очень пахло.

Дениса поддерживаю. Незачем в хорошем ЯП поддерживать множесто синонимов языка.

И я поддерживаю Дениса, что синонимы не к чему.
Но я за литерал.
Например, {} позволяют сразу вбить значение что порой помогает избавиться от лишней локальной переменной, которая захламляет код. И работает быстрее. Это, конечно, мелочи, но я серьезно не услышал ни одного объективного довода в пользу new Object, помимо "это выглядит по ООП". По ООП конкатенация строк выглядит через String#concat. В повседневной жизни часто его используют? Конечно, оверлоадить плюс - это тоже ООП, но не в контексте единообразия кода в AS3.

new -- вот где единообразие. Остальное -- Perl.

Добавлено через 2 минуты
Что до "работает быстрее" - это проблема компилятора. Ты же написал тьюринга, остальное - его проблемы.

Хм... Раз синонимы поддерживаются языком, значит они разрешены. Остальное треп.

Но это не синонимы для компилятора ) На выхлопе разный байткод. Трепа нет.

Компилятор реализует спецификацию, а не наоборот.

Забытая аналогичная спецификация, ставшая синонимом.

Не понял.

...что признано ошибкой, судя по баглисту.

Crazy
Обычно, баги долгожители перекачевывают в фичи...

Может еще E4X посмотреть?

Только путем документирования. 8-)