Цитата:
|
Цитата:
func = (name:String, parent:Module)-> compile to: var _typeCkeck = function(Class, inst){ if(!(inst instanceof Class)) { throw TypeError('бла бла бла') } } var func = function(name, parent){ _typeCkeck(String, name); _typeCkeck(Module, parent); } Я просто не уверен что представляю как сделать статическую проверку типов при том что могут приходить новые данные по аяксу например, или что скрипт наш может взаимодействовать с другими библиотеками в которых нет проверки типа. НО как минимум вот такую проверку сделать это офигенно, сахар, который полезен и для IDE для автокомплита, и собственно для разработчика. К тому же я сомневаюсь что вызов instanseof по нескольку раз на каждый вызов каждой функции замтено снизит производительность скрипта и будет являться узким горлышком бутылки. Это ни чем не отличается от того случая когда бы мы это руками писали. Кроме того указание типов не обязательно. Иными словами где хотим сделать проверку типа, пишем Type:argName и он все автоматом делает. Сниппет такой. В принципе можно делать статическую проверку а там где я сомневаюсь делать динамическую проверку? Или как? ЧТО думаешь? п.с. ты прост тут единственный кто со мной может на уровне поговорить) Кстати вот еще классную штуку придумал, мозжно чтобы он еще генерил комментарии для GCC в экстримальном сжатии)) классно же) чтобы что бы ты не писал он тебе варнинги не будет выдвавть. Потому что на этапе трансляции сам TypeCoffeescript выдаст варнинг) ну или идешка подсветит если научить. |
Цитата:
|
Цитата:
// описывам регулярками токины AST.addToken('word', '[$\w]+') AST.addToken('dot', '.') // описваем структуры выражениями где есть спецсимволы например [токен], капсом пишется имя структуры, * значит повторение 0 или больше раз и.т.п. все по аналогии с регулярками) AST.addStructure('PROP', '[word]') AST.addStructure('ACCESS', 'PROP([dot]PROP)*') Ну типа того. Строить грамотное AST я умею, а потом транслировать его в что угодно тоже умею. А проверку типов сделать не трудно, вообще не трудно. Трудно когда даныне могут придти в скрипт ИЗВНЕ. Понимаешь? как мне тогда проверку статическую делать? |
Цитата:
вам еще не надоело тролля кормить? :) |
nerv_, весело же :victory:
|
ТОТ_САМЫЙ, ну дерзай :)
|
Цитата:
|
ТОТ_САМЫЙ, я тебя не обозвал, а задал вопрос, а ты утвердил. Разницу чувствуешь или тупой? (это вопрос, надеюсь ты понял? :D).
|
Цитата:
|
ТОТ_САМЫЙ, ты явно под чем то. Ибо так тупить нереально,сори)
|
Пасоны, я тут модули юишки переписал на commonjs. И написал враппер файлов для этого https://www.npmjs.com/package/gulp-commonjs-wrapper
Смотрите в чем дело, почему не браузерифай? потму что он подключает компилит толко те модули которые реквайрятся, а в юишке мы зарание не знаем что будет реквайрится потому что когда свойство запрашивается в скоупе и доходит до корня и не находится, юишка пытается подгрузить и инициализировать контроллер с таким именем, делается это при помощи геттеров, следовательно мы зарание должны знать список всех контроллеров которые реквайрим. браузеривай этого не делает по этому я напсиал этот плагин. НО я подумал что он лишен той фитчи браузерифая, например если мы вайл не указали в gulp.src то он его не подгрузит и не подключит, я подумал а не добавить ка ли мне функционал браузерифая)??? что думаете? может оно вообще кому-то понадобиться? получается на выходе мы будем иметь что-то вроде браузерифая с несколькими "точками входа" (файлами которые мы укажем в src). А потом они все будут либо склеиваться либо транслироваться либо просто сохранятьяс в общем все что захочит пользователь плагина. КАК думаете нужная это фитча? Например я хочу исользовать в юишке дефолтный модуль ноды parse для работы с путями. Теперь я просто заинклюдю его куда нибудь где хочу, и все, мой плагин его автоматом тоже подцепит и поместит в код юишки. Удобно жи) |
Цитата:
Цитата:
Цитата:
|
Мнп ясно что ты дибил которому не хватает мозга зайти на кофескрии ком где на голавной прризводится сравнение. Мне яснь чтт ты дибил раз мои слова вызывпют у тебя срмнение. Тут даже вопроса по поводу этих 20 пренмуществ не стоит. То есть я даже не нес мысль чоо вот мол вы не зпали поо эти 20 преемуще та. А они есть.ОЧЕВИДНО что ссп знмют про них.
Ну окей раз ту появился такой даун как ты. Я погуглю за тебя: http://coffeescript.org Крути коолесиео мпльчик ситай буковки. А если у тебя еще и хапти мозга заявить "их тааам ри дваацать" то ты реально конченый. И Я ПОПРОШУ тебя удалиться с трада. Тут дяди кофескрипт и яваскрипт сравнивают. Аты не знаеш кофескрипт. Вначале выучи все его плюсы. Потом пииходи. Иначе как ты сраанивать собрался. |
Извини, ты это мне сейчас?)
|
Цитата:
Цитата:
|
Цитата:
Это короче будет ES6 + Typescript + Coffeescript |
Цитата:
|
Ну вот такой короче будет типа парсер, точнее вначале я напишу тулсу для описания языком, чтобы вы потом сами смогли если че свои языки влегкую пилить)
AST.token 'dot', '\.' AST.token 'word', '[$\w]+' AST.token 'bracket-open', '\[' AST.token 'bracket-close', '\]' AST.structure 'EXP', 'описание выражений' AST.structure 'IDENTIFER', '[word]' AST.structure 'PROP_ACCESS', '[dot][word]' AST.structure 'DYNAMIC_ACCESS', '[bracket-open] EXP [bracket-close]' AST.structure 'PATH', 'IDENTIFER (PROP_ACCESS|DYNAMIC_ACCESS)*' code = 'User.name[user.soname]' ast = [ { type: 'PATH' value: 'User.name[user.soname]' contents: [ [ { type: 'IDENTIFER' value: 'User' }, { type: 'PROP_ACCESS' value: '.name' contents: [ { type: 'word' value: 'name' } ] }, { type: 'DYNAMIC_ACCESS' value: '[user.soname]' contents: [ { type: 'exp' value: 'user.soname' contents: [ #... ] } ] }, ] ] } ] Потом напишу язык для описания того как из ast строить выходное дерево, то есть то же самое только в обратную сторону)) и все. Будетекрасиво описывать в стиле регулярок что ожидаете на входе и как оно должн выводится. Красота?? Таким образом можно будет например написать препроцессор для css или компилятор из С++ в яваскрипт. Все что угодно. Максимум что я НЕ придумал это как задать универсальный формат AST... Языки то разные. |
Часовой пояс GMT +3, время: 17:33. |