yar333314 ноя 2014 в 01:45

Haxe: конвертируем исходный код

5 мин

25K

Haxe * Программирование *

+29

Комментарии 24

askeet 14 ноя 2014 в 06:30

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

SerafimArts 14 ноя 2014 в 06:46

1) Любой продукт из серии JetBrains
2) В зависимости от компилятора\конечногого языка и платформы

yar3333 14 ноя 2014 в 09:29

«Родная» среда разработки — FlashDevelop. Полная поддержка автодополнения через вызов компилятора, которая на данный момент ещё и работает довольно быстро даже для больших проектов. Из минусов — нет дебаггера. Производительность, как и сказал SerafimArts, зависит от целевой платформы. Практика показала, что код для C++ не очень эффективный (слишком много обвязки и допущений — например, int-ы могут хранить и null — отсюда невозможность использования простого типа данных), а вот код для других платформ очень даже неплох.

SerafimArts 14 ноя 2014 в 09:36

а вот код для других платформ очень даже неплох.

За исключением JS. Помнится была демка с «мячиками» прямо в каталоге с примерами и для отрисовки каждого мячика использовался отдельный канвас, а поворот и всякие издевательства осуществлялись средствами CSS.

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

yar3333 14 ноя 2014 в 09:40

Вы сейчас говорите про библиотеку OpenFL — да, использование её для HTML5-игр пока не оправдано, вы правы. Я лично склоняюсь к использованию easeljs, например.

SerafimArts 14 ноя 2014 в 09:46

Да, верно, скорее всего именно OpenFL.

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

remal 14 ноя 2014 в 10:22

А сам haxe, как язык, тут совершенно не при чем. Это лишь проблема тех, кто реализовал на нем таким образом эти мячики.

SerafimArts 14 ноя 2014 в 11:44

Мячики были представлены в виде объекта спрайта. Есть варианты как сделать это по другому, чтоб openfl при компиляции не делал тучки html тегов?

Keyten 14 ноя 2014 в 17:53

Вариант 1. Не использовать OpenFL. Для canvas в самом деле есть очень много фреймворков, а haxe, как я понял, может работать с ними всеми.
Вариант 2. Залезть в OpenFL и переписать. Не зря же он Open, в самом деле.

YuriHx 15 ноя 2014 в 23:02

Вариант 3. Использовать OpenFL, но в качестве бэкенда (OpenFL поддерживает альтернативные бэкенды) для трансляции в html5 использовать bitfive

Вариант 4. Использовать Flambe — на момент это возможно лучшее решение для создания html5 игр на haxe.

AxG 11 ноя 2019 в 18:11

Лично для сейчас меня фаворитом является VSCode.
Со списком самых популярных можно ознакомиться тут: haxe.org/documentation/introduction/editors-and-ides.html
По поводу генерации С++. Теперь используется как-раз простой тип.
И при попытки присвоение null к int haxe выдаст ошибку.

impwx 14 ноя 2014 в 08:15

Не смотрели в сторону Typescript? На нем теперь тоже можно писать и клиентский, и серверный код со строгой типизацией, практически идентичный JS.

SirEdvin 14 ноя 2014 в 08:25

TypeScript основан на JS, в том время, как Haxe, вроде как, можно транслировать во множество языков.

impwx 14 ноя 2014 в 08:56

Да, так и есть, но это довольно сомнительный плюс. Я слабо представляю себе проект, в котором возможность в любой момент сменить целевую платформу важнее, чем обилие и качество готовых библиотек под конкретный язык — а под Haxe их, смею предположить, минимум на порядок меньше чем под PHP или JS.

SirEdvin 14 ноя 2014 в 09:13

Какая-то кроссплатформенная разработка, к примеру)

yar3333 14 ноя 2014 в 09:36

Думаю, что для ряда случаев вы правы, однако могу привести контпример: пару лет назад написали с другом ряд онлайн-игр на haxe с компиляцией в php, а через некоторое время перекомпилировали их в neko. В результате смогли снизить расходы, избавившись от половины серверов.

yar3333 14 ноя 2014 в 09:32

Недавно смотрел. Использовал файлы *.def.ts для генерации аналогичных обёрток для haxe. Синтаксис haxe мне больше нравится.

SerafimArts 14 ноя 2014 в 09:38

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

Indexator 14 ноя 2014 в 11:14

компилятор лишь транслирует

Так и говорите — транслятор.

yar3333 14 ноя 2014 в 11:32

Решил не нарушать традицию: в англоязычной документации везде используется «compiler». Кроме того, haxe всё же имеет встроенную поддержку компиляции в байт-код машины nekovm.

SirEdvin 14 ноя 2014 в 11:33

интересно, а он не умеет компилироватся в байткод java?)

datacompboy 14 ноя 2014 в 11:39

пока не умеет.

AxG 11 ноя 2019 в 18:03

Теперь умеет
haxe.org/manual/target-java-getting-started.html

YuriHx 16 ноя 2014 в 10:43

Так ведь изначально он и был только компилятором. Первой целью была именно компиляция в байт-код swf. И только вторым добавился js, в который уже нужно было транслировать. И до сих пор swf — один из самых взрослых таргетов, так что не nekovm единым.)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий