_>>Ну и хочу заметить, что VM у WASM имеется только в том же смысле, что и LLVM, а не как JVM или CLR. ))) N>И это правильно. Я вообще надеюсь, что jvm и .НЕТ языки когда-нибудь можно будет нацелить прямо на wasm.
Ну учитывая Net Native это не большая проблема. Другое дело, что в нем все равно есть GС, хотя и значительно менее прожорливый.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, novitk, Вы писали:
_>>Вообще то если уж Qt умудряются скомпилировать под asm.js, то уж с Питоном (встраивание которого в C++ приложения является давно отработанной техникой) то точно не должно быть никаких проблем — просто пересобрать под wasm и всё. N>Вообще то Питон без доступа к DOM-у нафиг никому не нужен. Это как бы основной посыл.
Питон уже был в браузере. Не взлетел. И tcl был, и perl, и даже rexx. Уродец JS сделал всех героев
Здравствуйте, Serginio1, Вы писали:
V>>Не опционально, надо явно указывать, что это dynamic. Никакого автоматического fallback до object или dynamic в случае автовывода типов не будет, будет ошибка компиляции. S> И в чем разница?
Явно vs неявно.
V>>Но ты не можешь вызывать никакие методы целевого объекта через Object, в этом смысл. V>>Сначала приведи к нужному типу, потом вызывай, если такое приведение было успешным. V>>Подобных ср-в в TS нет и быть не может. S> А с dynamic могу
Это явное поведение.
V>>Даже от reflection, считай, уже отказываются. S> Нет не отказались. Просто нужно указать к каким типам применяется рефлексия
Явное поведение в квадрате.
V>>Это тебе захотелось так допилить мою логику. S>Ну как же тебя понять если ты за строгую типизацию.
Я за отсутствие нежданчиков.
Строгая типизация даёт такое отсутствие изкаробки.
Т.е., наоборот, в строгой типизации для нежданчика надо сделать "что-то дополнительное".
V>>>>Ты с кем тут споришь? Сам с собой? Оставить тебя наедине? )) S>>>Ну ты же говоришь, что TS не нужен ибо типизация опциональна.
Она опциональна изкаробки, т.е. в TS изкаробки идут нежданчики, поэтому на помоечку.
S>У меня включена опция определения типа. Так что у меня типизация присутствует и я где тип неопределен пишу any.
Не должно быть такой опции, да еще которую надо дополнительно включать.
S>И чем Dart лучше TypeScript?
Кратко? Всем.
S>И используют именно TS а не Dart ибо у TS больше премуществ.
Никаких не больше. Я не считаю интеоперабельность с имеющимся JS-кодом преимуществом.
Это серьезный недостаток.
Это дыра (портал) в еще большую дыру.
Если ты выдаёшь интероперабельность TS с JS-кодом за преимущество, то ты слился еще до начала обсуждения.
Просто надо принять как факт — либы на JS не валидны. Любые.
Тут надо сделать вдох/выдох, поднять руку, произнести японское заклинание хусим, и жить спокойно дальше.
S>А на голом JS пишут только те, кто хочет стрелять себе в ногу.
Ты сам себе противоречишь.
Потому что если ты отрицаешь интероперабельность TS с JS, т.. если такая интероперабельность тебе не нужна, то у нас кроме Angular-2 ничего и нет для TS. Поэтому, с еще больше чистой совестью бери Angular-2 на Дарте.
S>Рассматривай JS как ассемблер для TS и Dart
Э, нет.
Чтобы из Dart обратиться к JS, надо будет сделать нехило приседаний.
А из TS — напрямую.
В первом случае тебя это остановит, если ты не любишь приседания, и заставит сделать RTFM, т.е. найти требуемую функциональность в мощнейшей стандартной библиотеке Дарта. Во втором случае ты обязательно поступишь как ленивый недобросовестный инженер и притянешь в проект зависимости от заведомо невалидного кода.
S> Кстати в том же dart есть о Object и dynamic
Явные, как и в C#.
S>В дарте тоже типизация опциональна.
Э, нет. В Дарте опционально отсутствие типизации.
По-умолчанию всё типизировано.
V>>Ведь не проблема была бы в некоем TS сделать нормальную типизацию. Это, как раз, не сложно. Фишка ведь в том, что имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па. S>Это зависит от программиста.
Именно!
А не хочу зависимости от человеческого фактора.
Я сам себе в первую очередь не доверяю на относительно больших проектах.
А уж кому-то еще... у-у-у-у )))
S>Еще раз TS позволяет писать строго типизированные приложения с автоматическим выводом типа для результата функций и тд.
Что тебе вот до сих пор не понятно:
имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па.
S>>В дарте тоже типизация опциональна.
V>Э, нет. В Дарте опционально отсутствие типизации.
Покажи ка эту опцию.
Читай ниже. Все таки нужно знать предмет о котором ты ведешь речь. V>По-умолчанию всё типизировано.
Так и в TS типизация включена по умолчанию в TsConfig "noImplicitAny": true
https://angular.io/docs/ts/latest/guide/typescript-configuration.html
А вот кто эту опцию убирает, ССЗБ
V>>>Ведь не проблема была бы в некоем TS сделать нормальную типизацию. Это, как раз, не сложно. Фишка ведь в том, что имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па. S>>Это зависит от программиста.
V>Именно! V>А не хочу зависимости от человеческого фактора. V>Я сам себе в первую очередь не доверяю на относительно больших проектах. V>А уж кому-то еще... у-у-у-у )))
Так и Dart позволяет any по умолчанию. Его на свалку!
S>>Еще раз TS позволяет писать строго типизированные приложения с автоматическим выводом типа для результата функций и тд.
V>Что тебе вот до сих пор не понятно: V>
V>имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па.
Он может писать и на Dart писать без типов. Зачем ему тогда вообще TS использовать? ES6 это по сути не типизированный TS.
Ты то кстати на чем пишешь? Или из области не писал, но осуждаю?
Еще раз можно и на C# писать только на динамиках используя питоны и прочие динамические языки.
V>Не пора ли уже включить голову, а?
Во во. Если у меня все типизировано без any, да и any только по делу, а как правило это может быть составной тип string|number
Если же ты используешь JS это твои проблемы.
Использование типов
Как вы используете типы зависит от вас. Если вы ненавидите типы, вам не нужно их вообще использовать. Вы не получите никаких предупреждений типа, и вы можете развиваться в том стиле, в котором вы чувствуете себя комфортно на других динамических языках. Вы по-прежнему можете пользоваться типами, потому что библиотеки Dart имеют сигнатуры типов, которые сообщают вам, что они ожидают и что они возвращают. Если вы запустите проверенный режим и передадите плохие аргументы в библиотеку, проверочный режим обнаружит это в том месте, где вы допустили ошибку.
Если вы любите типы, вы можете использовать их везде, как на статически типизированном языке. Однако даже тогда вы не получите такой же уровень статической проверки. Правила Дарта гораздо менее жесткие. Мы ожидаем предоставления дополнительных инструментов, которые могли бы интерпретировать аннотации типов более строго для тех, кто любит такие вещи.
Мы не рекомендуем ни одну из этих крайностей. Используйте типы, в которых они имеют смысл. Самое ценное, что вы можете сделать, это добавить типы в заголовки публичных членов ваших библиотек. Далее, сделайте то же самое для частных. Даже если никто не должен поддерживать код, вам будет полезно, если вы оставите код и вернетесь через несколько недель или месяцев. В обоих случаях вам необязательно добавлять типы в тела методов или функций. Пользователи библиотеки получают значение из сигнатур типов, даже если они не точны на 100%.
В рамках функций функций он может не всегда оплачивать аннотации объявлений. Иногда код достаточно прост, что на самом деле не имеет значения, и типы могут просто создавать беспорядок.
Как правило, вы должны разрабатывать свой код, не позволяя соображениям типа влиять на ваш дизайн. В некоторых случаях существуют альтернативные проекты, один из которых лучше работает с типами, чем с другим. Например, вместо того, чтобы передавать строки, обозначающие имена функций, которые вызывают, если вы можете передать функцию, ваш код будет более эффективным и более простым для проверки типов. Дарт отговаривает безвозмездное использование отражения другими средствами. Однако вы не должны стесняться использовать отражение, когда оно действительно имеет смысл.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
N>>Вообще то Питон без доступа к DOM-у нафиг никому не нужен. Это как бы основной посыл. I>Питон уже был в браузере. Не взлетел.
A что имеется ввиду под "был"? Двухнедельные поделки типа PythonJS?
Здравствуйте, Ikemefula, Вы писали:
_>>В описание моих тестов была ссылка на работающий прямо на страничке JS тест. Открываешь его исходник и видишь функцию Update — это по сути и есть весь тест, остальное мишура. I>И как я найду ошибку в остальном твоем коде, телепатией или домыслами ?
В каком ещё остальном коде?
_>>Нет, просто на мой вкус термин "убогий тормоз" при сравнение Pyhton и JS неуместен. На мой взгляд эти языки относятся к одному классу по производительности. И весь этот класс является "убогим тормозом" по отношению к скажем C++. Причём данный факт абсолютно нормален для той ниши, которую занимают эти языки. I>Я так и подумал. Но почему то вспомнил, что как только речь про C#, так ты придираешься к каждой доле процента скажем, в сравнении с джавой или питоном. Парадокс! Расскажи, чем тебя шарписты обидели ?
Нет, как раз к C# и Java у меня одинаковое отношение. ) И оно в данном контексте отличается от отношения к Python и JS. Потому что адепты последних обычно достаточно разумны, чтобы не претендовать на какие-то результаты в области производительности (ну в абсолютном смысле, а не внутри своего мирка скриптовых языков) — их языки сильны другим. А вот адепты первых иногда пытаются заявлять что-то вроде того, что могут достигать близких к нативным языкам результатов. И вот таким неадекватным товарищам приходится открывать глаза на реальность, демонстрируя, что на самом деле разница как минимум в разы, а иногда и на порядки.
Здравствуйте, novitk, Вы писали:
_>>...Что же касается интеграции с браузером и его GC, то тут конечно всё сложнее и требуется разработка с нуля (благо этим занимаются не энтузиасты, а специалисты на зарплате, причём из команд разработки ведущих браузеров). N>Я собственно именно это и написал. Два GC в одном процессе = ад.
Так откуда два то, если в wasm сделают нативный интерфейс к DOM? ) Да и первый GC, в случае того же Питона уже давно идеально соотносится с нативным кодом. )
_>>И по некоторым данным возможно там будет использоваться новое нативное API (в котором никакого GC просто не надо). N>Дело не в статическом нативном API, a в модели памяти и взаимодействии.
Модель памяти уже известна: линейный расширяемый кусок памяти, принадлежащий wasm. По сути никаких ограничений, всё как в нативном коде. Интеграция с JS сделана через доступ JS кода к этому куску памяти в виде обычного массива. Но нас же сейчас интересует интеграция не с JS, а с API браузера. И тут может быть много разных вариантов. В принципе при решение тупо в лоб можно всё сделать на банальных глобальных функциях в сочетание с некими дескрипторами (как устроен API в большинстве современных ОС). Такое будет удобнее программировать на C. Или же можно всё же сохранить компонентную модель и сделать некую вариацию на тему COM. С таким будет уже удобнее работать на C++. Ни в одном из этих случаев не видно никаких особых проблем с взаимодействием или же потребности в GC. Просто надо тупо сесть и создать большой объём API. Кстати, я там читал кого-то из разработчиков wasm, что они не хотят ничего такого руками делать и хотят придумать такой механизм, чтобы в него можно было засунуть IDL от w3c и автоматически получить результат. Ну посмотрим как это у них выйдет, в любом случае это у них не приоритетная задача — сейчас в приоритете многопоточность и SIMD.
N>Я знаю. Мои возражение сводятся к тому что ключевой вопрос (GC) платформы до сих пор не проработан, а ее уже интегрируют корявым способом в браузер.
А мне кажется он полностью проработан: его нет и не планируется.
_>>Ну и хочу заметить, что VM у WASM имеется только в том же смысле, что и LLVM, а не как JVM или CLR. ))) N>И это правильно. Я вообще надеюсь, что jvm и .НЕТ языки когда-нибудь можно будет нацелить прямо на wasm.
Ну это возможно разве что только через ветку развития .net native. )
Здравствуйте, novitk, Вы писали:
_>>Ну скажем для какого-нибудь декодера видео из гиппотетического революционного стандарта h.365 скорость может быть вполне критичной. N>Редкая ниша, где wasm скорее всего не при чем. Нужен GPGPU, etc.
В данный момент браузеры используют не GPU, а вот такой https://github.com/cisco/openh264 код. Проблема в том, что если кто-то разработает новый эффективный кодек, то сайты всё равно не смогут им пользоваться, пока его не протолкнут в браузеры (а на это могут уйти годы, не говоря уже о разных "политических" нюансах). Приход wasm полностью решает эту проблему — сайты просто купят прямо бинарную сборку wasm у создателей кодека и всё заработает у каждого пользователя. Ну точнее wasm будет решать эту проблему, когда добавится поддержка SIMD — без неё пока такое не напишешь (код по ссылке выше в значительной части написан на ассемблере с работой через SSE/NEON).
Здравствуйте, Serginio1, Вы писали:
S>Вообще интересно как с DOM будут справляться не динамические языки. S>При этом сама страница может кардинально меняться. Подгружаться и удаляться контейнеры со своими событиями S>Могут динамически добавляться скрипты или ссылки на скрипты.
А в чём проблема то? ) Вообще то браузер тоже написан не на динамическом языке, но он как-то справляется... )))
Здравствуйте, Serginio1, Вы писали:
V>>Э, нет. В Дарте опционально отсутствие типизации. S>Покажи ка эту опцию.
Эта опциональность зашита в язык.
S>Читай ниже. Все таки нужно знать предмет о котором ты ведешь речь.
Нужно еще не врать, чтобы коллегам не приходилось бороться с желанием послать тебя подальше после каждого твоего вранья.
V>>По-умолчанию всё типизировано. S>Так и в TS типизация включена по умолчанию в TsConfig "noImplicitAny": true
Подмена понятий — тоже разновидность вранья.
Если опцию где-то надо явно задавать, то это НЕ по-умолчанию.
S> Так и Dart позволяет any по умолчанию. Его на свалку!
Any = dynamic в C#.
Оба можно банальным поиском в исходнике.
S>>>Еще раз TS позволяет писать строго типизированные приложения с автоматическим выводом типа для результата функций и тд.
V>>Что тебе вот до сих пор не понятно: V>>
V>>имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па.
S>Он может писать и на Dart писать без типов.
Т.е., ты отказываешься отвечать на мои аргументы?
Тогда адью.
Одна из проблем этого подхода (в дополнение к сложности архитектуры) заключается в том, что машинный код JITed может потреблять значительный объем памяти, даже если код выполняется только один раз. Чтобы смягчить эти издержки, команда V8 построила новый интерпретатор JavaScript под названием Ignition, который может заменить базовый компилятор V8, выполнить код с меньшими издержками в памяти и проложить путь для более простого конвейера выполнения сценариев.
С Ignition, V8 компилирует JavaScript-функции в краткий байт-код, который составляет от 50% до 25% от размера эквивалентного базового машинного кода. Этот байт-код затем выполняется высокопроизводительным интерпретатором, который дает скорости выполнения на реальных веб-сайтах, близких к коду, сгенерированному существующим базовым компилятором V8.
В Chrome 53 Ignition будет включен для устройств Android с ограниченной памятью (512 МБ или меньше), где экономия памяти наиболее необходима. Результаты ранних экспериментов в этой области показывают, что Ignition уменьшает память каждой вкладки Chrome примерно на 5%.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Э, нет. В Дарте опционально отсутствие типизации. S>>Покажи ка эту опцию.
V>Эта опциональность зашита в язык.
То есть я могу писать без типов по умолчанию?
Ты сам же себя и опровергаешь. А в TS по умолчанию нужно выставлять тип any
S>>Читай ниже. Все таки нужно знать предмет о котором ты ведешь речь.
V>Нужно еще не врать, чтобы коллегам не приходилось бороться с желанием послать тебя подальше после каждого твоего вранья.
Ну ты посмотри на себя. Самому то не стыдно. Я тебе уже кучу ссылок привел на твои ошибочные суждения.
Ты можешь только хамить.
V>>>По-умолчанию всё типизировано. S>>Так и в TS типизация включена по умолчанию в TsConfig "noImplicitAny": true
V>Подмена понятий — тоже разновидность вранья. V>Если опцию где-то надо явно задавать, то это НЕ по-умолчанию.
Так в дарте по умолчанию ести тип не задан то он any. S>> Так и Dart позволяет any по умолчанию. Его на свалку!
V>Any = dynamic в C#.
Так и TS any это аналог dynamic. Но ты кричал здесь, что раз any можно не указывать то он отстой, я показываю тебе, что в Dart можно не указывать тип ты называешь меня обманщиком? V>Оба можно банальным поиском в исходнике.
S>>>>Еще раз TS позволяет писать строго типизированные приложения с автоматическим выводом типа для результата функций и тд.
V>>>Что тебе вот до сих пор не понятно: V>>>
V>>>имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па.
S>>Он может писать и на Dart писать без типов.
V>Т.е., ты отказываешься отвечать на мои аргументы? V>Тогда адью.
Твои аргументы в том, что в Dart нужно указывать тип явно. Я тебе показал, что ты не прав. В нем тоже не нужно явно указывать тип.
Мало того в TS выставлен флаг по умолчанию, что нужно обязательно указывать тип.
Я тебе советую, все таки для начала освоить тему обсуждения, не хамить, давать ссылки.
Смысл обсуждения на форуме это не кидания какашками, а изучение, того, что не знал и избавления от своих заблуждений.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>А в чём проблема то? ) Вообще то браузер тоже написан не на динамическом языке, но он как-то справляется... ))) S> Как ты в скрипты будешь вставлять C++ код?
Ты вообще о чём спрашиваешь? ) Сформулируй свою мысль подробнее, а то я вообще ничего не понял. И лучше делай это (не только в данном сообщение, а вообще) без лишних ссылок и цитат. Если у кого-то будет сомнение в твоих словах, то тогда у тебя затребуют подтверждение и ты спокойно выложишь свои ссылки. А так, делать это на каждом рядовом шаге дискуссии — это только захламлять разговор.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>А в чём проблема то? ) Вообще то браузер тоже написан не на динамическом языке, но он как-то справляется... ))) S>> Как ты в скрипты будешь вставлять C++ код?
_>Ты вообще о чём спрашиваешь? ) Сформулируй свою мысль подробнее, а то я вообще ничего не понял. И лучше делай это (не только в данном сообщение, а вообще) без лишних ссылок и цитат. Если у кого-то будет сомнение в твоих словах, то тогда у тебя затребуют подтверждение и ты спокойно выложишь свои ссылки. А так, делать это на каждом рядовом шаге дискуссии — это только захламлять разговор.
Здравствуйте, Serginio1, Вы писали:
_>>Ты вообще о чём спрашиваешь? ) Сформулируй свою мысль подробнее, а то я вообще ничего не понял. И лучше делай это (не только в данном сообщение, а вообще) без лишних ссылок и цитат. Если у кого-то будет сомнение в твоих словах, то тогда у тебя затребуют подтверждение и ты спокойно выложишь свои ссылки. А так, делать это на каждом рядовом шаге дискуссии — это только захламлять разговор. S> Как заменять JS в скриптах на странице. Ведь можно например создать секцию script, создать контейнер с вызовом метода из этого скрипта S>http://www.forum.mista.ru/topic.php?id=715894#17 S> При этом нужно учитывать, что затраты на компиляцию могут отжирать много памяти, особенно на мобильных устройствах. S> Управлять DOM можно откуда угодно. Вопрос, чем заменить JS в скриптах?
Т.е. ты спрашиваешь как избавиться от JS с помощью WASM? Когда WASM дадут доступ к API браузера это будет элементарно — просто пишем на любом скриптовом языке нужный на код (кстати html тег script отлично это поддерживает) и дополнительно подгружаем движок этого языка скомпилированный под wasm. Тот при своей инициализации возьмёт данные из этих тегов и запустит их на исполнение. Не вижу вообще никаких сложностей.
Кстати, формально говоря некое подобие можно реализовать и прямо сейчас, реализовав поддержку браузерного API через Emscripten, но это будет очевидно суррогат "избавления от js", т.к. поддержка функций браузера в Emscripten через тот самый JS и реализована (т.е. в дополнение к своим скриптам на неком произвольном языке придётся подключать ещё и набор жирных js библиотек от Emscripten). Так что лучше набраться терпения и подождать пока разработчики wasm доберутся до браузерного API.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Ты вообще о чём спрашиваешь? ) Сформулируй свою мысль подробнее, а то я вообще ничего не понял. И лучше делай это (не только в данном сообщение, а вообще) без лишних ссылок и цитат. Если у кого-то будет сомнение в твоих словах, то тогда у тебя затребуют подтверждение и ты спокойно выложишь свои ссылки. А так, делать это на каждом рядовом шаге дискуссии — это только захламлять разговор. S>> Как заменять JS в скриптах на странице. Ведь можно например создать секцию script, создать контейнер с вызовом метода из этого скрипта S>>http://www.forum.mista.ru/topic.php?id=715894#17 S>> При этом нужно учитывать, что затраты на компиляцию могут отжирать много памяти, особенно на мобильных устройствах. S>> Управлять DOM можно откуда угодно. Вопрос, чем заменить JS в скриптах?
_>Т.е. ты спрашиваешь как избавиться от JS с помощью WASM? Когда WASM дадут доступ к API браузера это будет элементарно — просто пишем на любом скриптовом языке нужный на код (кстати html тег script отлично это поддерживает) и дополнительно подгружаем движок этого языка скомпилированный под wasm. Тот при своей инициализации возьмёт данные из этих тегов и запустит их на исполнение. Не вижу вообще никаких сложностей.
_>Кстати, формально говоря некое подобие можно реализовать и прямо сейчас, реализовав поддержку браузерного API через Emscripten, но это будет очевидно суррогат "избавления от js", т.к. поддержка функций браузера в Emscripten через тот самый JS и реализована (т.е. в дополнение к своим скриптам на неком произвольном языке придётся подключать ещё и набор жирных js библиотек от Emscripten). Так что лучше набраться терпения и подождать пока разработчики wasm доберутся до браузерного API.
Угу давай смотреть. Внедренный код должен кроме всего прочего взаимодействовать с уже внедренным. Это по сути аналог плагинов в .Net.
Мы можем загрузить сборку, но она должна иметь в метаданных ссылки на общие интерфейсы иметь доступ к статическим методам и свойствам к классам уже загруженных сборок и если они не загружены загружать, проблемы с версиями (они правда есть и в JS) итд.
Кроме того в HTML события могут иметь как имя метода так и реализацию. Это рефлексия. А значит движок должен быть аля .Net и Java и сборки с соответствующими метаданными.
Вспоминаем про ограничения рефлексии в .Net Native. И по сути то будем иметь тот же Фреймворк который и сейчас, только созданный заного.
На самом деле вы хотите сделать из браузера десктопное приложение, а он сделан для работы с динамическими страницами.
Вот например код из Angular 2
<tr *ngFor="let rows of RowsRange; let row = index">
<td *ngFor="let col of ColsRange; let i = index">
<input type="text" (keypress)="KeyPress($event,Puzzle[row*9+i].value)" (click)="Click(Puzzle[row*9+i])" [class.IsFocused]="Puzzle[row*9+i].IsFocused"
[(ngModel)]="Puzzle[row*9+i].value" [disabled]="Puzzle[row*9+i].disabled" size="3" maxlength="1">
</td>
</tr>
При этом в С++,C# есть перегрузка методов, дженерики, а значит нужно искать методы по параметрам и дженерик методы с созданием метода по типу параметру, а если его нельзя вывести, то нужно указвать типы дженерик аргументов.
и солнце б утром не вставало, когда бы не было меня
Спасибо. Прошу прощения был не прав. S>> А вот кто эту опцию убирает, ССЗБ Ops>Ее надо явно прописывать.
При создании приложения в TsConfig из множества шаблонов создается и TsConfig c noImplicitAny": true
Или я копирую уже созданный.
В любом случае разговор то шел о Dart, а там и этой опции нет. То есть там можно вообще тип опускать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
V>>Эта опциональность зашита в язык. S>То есть я могу писать без типов по умолчанию?
В Хаскекль тоже аннотация типов опциональна.
Однако, попробуй скажи, что в нём нет типизации.
S>Ты сам же себя и опровергаешь. А в TS по умолчанию нужно выставлять тип any
Дык, динамику тоже надо уметь обслуживать.
Проблема в том, что TS не умеет обслуживать динамику.
Простой пример, возьмём не Дарт, а C#, чтобы окружающим тоже понятно было:
class Object1 {}
class Object2 {}
object obj1 = new Object1();
Object2 obj2 = (Object2)obj1; // ошибка в рантайм
Здесь сработает строгая динамическая типизация, будет ошибка прямо в момент присвоения, а не "когда-нибудь потом", когда мы попытаемся использовать obj2.
А что будет, если этот код скомпиллировать в JS (предположим наличие транскомпайлера C# => JS)?
Вот пример на TS:
class Object1 {}
class Object2 {}
let obj1 : any = new Object1();
let obj2 : Object2 = obj1; // OK... WAT???
Присвоение obj2 произойдёт успешно, ы-ы-ы.
Точно так же и в Dart — в его родной VM будет ошибка, а после компиляции в JS ошибки не будет.
Именно поэтому Google строго рекомендует вести разработку в родной среде Dart.
И тут мега-принципиальнейшее отличие TS от Dart в том, что TS предназначен сугубо и только для JS.
Вопрос — и нафига козе баян?
Вот объясни мне, ЗАЧЕМ тебе на серверной стороне JS, если для Dart есть его версия Angular-2 + мощнейшая стандартная библиотека языка? Выделенное курсивом тебе что-нибудь говорит?
Я уже молчу о таких вещах в TS, как возможность перезаписать мембер или символ из библиотеки.
Опять пример на C#:
class Object1 {
public string M() { return"42"; }
};
Object1 obj1 = new Object1();
obj1.M = 43; // ошибка
Пример на TS:
class Object1 {
M() : string { return"42"; }
}
let obj1 : any = new Object1();
obj1.M = 43; // OK... WAT???
V>>Нужно еще не врать, чтобы коллегам не приходилось бороться с желанием послать тебя подальше после каждого твоего вранья. S> Ну ты посмотри на себя. Самому то не стыдно. Я тебе уже кучу ссылок привел на твои ошибочные суждения.
Опять же вранье.
Ты еще не показал ни одной моей ошибки, бо сам плаваешь в азах буквально в каждом сообщении.
Собсно, по итогам твоих высказываний я вижу, что ты НЕ понимаешь зачем Гугл сделал Dart.
Ты заблудился натурально в 3-х соснах и не можешь найти выход из этой "густой чащи". ))
Dart — это попытка вытянуть индустрию из болота кривой типизации JS.
И, наоборот, TS — это попытка замаскировать дурной запах такого болота, оставив всё как есть, мол "да ничего такого, немного дезодорантом побрызгали, а тут и тут не принюхиваемся!".
Два этих подхода располагаются на противоположных полюсах в плане своих целей и задач.
Ставить м/у ними знак равенства — это чудовищное дилетанство.
S>Ты можешь только хамить.
Ну а кто тут бежит впереди паровоза насчет "надо знать предмет", я что ле?
Прежде чем заявлять "я выиграл спор" его надо действительно выиграть, иначе получается только так:
S>Так в дарте по умолчанию ести тип не задан то он any. S>Так и TS any это аналог dynamic.
В TS любой тип — это и есть dynamic, независимо от аннотации типа.
Вот я выше показал на примерах весь кошмар этого языка.
Защиты от этого кошмара в TS де-факто НЕТ. Иначе бы я даже не участвовал в этом споре, разумеется
В отличие от, в том же C# или Dart аннотация типа имеет значение при работе с dynamic:
Собсно, dynamic в C# — это то, чем изначально должен был быть их Object. Т.е. вместо непосредственного вызова reflection должен был быть такой хелпер.
В Dart эту ошибку учли и сразу сделали как правильно. Точно так же учли ошибку дизайна функциональных типов в дотнете — гребанных их делегатов. В Dart сигнатура функционального типа и определяет его тип, как и должно быть.
Так же в Dart добавили еще несколько удобных, но при этом абсолютно прозрачных вещей (в сравнении с C#/Java):
* compile-time вычисления;
Т.е. любые твои прикладные классы с final-полями и любые твои ф-ии могут быть использованы для вычислений времени компиляции. В точно таких же сценариях в C#/Java вычисления происходят в рантайм.
* ограничения генериков включаются в определения типа;
* идиома nameof в лаконичной форме: memberInfo = #memberIdentifier;
* локальные ф-ии;
* итерация по реактивным коллекциям await for, await for-in (C# foreach-in);
* решена проблема принадлежности оператора break через опциональный break label;
* язык является одновремено компиллируемым и скриптовым, у скрипта в начале файла стоит #! бла-бла-бла
Кароч, лично я вижу в Dart хорошо проделанную работу над детскими ошибками в современных мейнстримовых VM-языках.
Причем, мне хватило когда-то 15 мин побаловаться и всё это увидеть.
Но тебе даже если разжевать и в рот положить — ты проглотить не можешь.
Как так? ))
S>Но ты кричал здесь, что раз any можно не указывать то он отстой, я показываю тебе, что в Dart можно не указывать тип ты называешь меня обманщиком?
Я уже более чем доступно показал тебе, в чем ты обманщик: в выдавании желаемого за действительного и в обвинении оппонента в ошибках при полном неумении (невозможности?) эту ошибку показать сугубо технически.
Итого, ты врёшь тут как дышишь как насчёт якобы "типизации в TS", так и насчёт "в Darte всё точно так же".
А уж в случае "я показал тебе твою ошибку" — это уже за гранью добра и зла.
Ты ничего не показал, от тебя новой инфы для меня — зеро.
Чтобы показать мне мою ошибку ты должен дать мне какуюнить новую инфу, чтобы я такой впечатлился: "ммм... а ведь действительно!".
V>>>>имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па. S>>>Он может писать и на Dart писать без типов. V>>Т.е., ты отказываешься отвечать на мои аргументы? S>Твои аргументы в том, что в Dart нужно указывать тип явно.
Т.е. ты ОПЯТЬ отказываешься отвечать на мои аргументы:
имеющийся убогий JS-код должен быть валидным TS-кодом. Т.е., программист имеет принципиальную возможность продолжать писать убогие JS-конструкции в исходнике TS, это будет ОК с т.з. компилятора. А всё вместе это будет ж-па.
Это у тебя принципиальная позиция, что ле — непременно переводить стрелки, отвечать невпопад, цитировать не то, на что ты реально отвечаешь?
Слабо сосредоточиться и ответить на мой аргумент?
S>Я тебе показал, что ты не прав.
Ты пока показал своё невладение азами, больше ничего.
S>Мало того в TS выставлен флаг по умолчанию, что нужно обязательно указывать тип.
А толку, если типизация не работает?
В TS ты выставляешь типы сугубо для intillesence.
S>Я тебе советую, все таки для начала освоить тему обсуждения, не хамить, давать ссылки.
Ну тогда я тебе советую начать с основ IT.
S>Смысл обсуждения на форуме это не кидания какашками, а изучение, того, что не знал и избавления от своих заблуждений.
Смысл обсуждения — это делиться информацией с коллегами и, в свою очередь, уметь воспринимать от коллег новую для себя информацию.
Пока что демонстрируешь отсутствие навыков в обеих дисциплинах, сорри.
А для чего ты тогда здесь?
Чиста для демагогии, для возможности поиздеваться над психикой коллег, вот так смело переходя границы простого обмена аргументами?
Ты же тупо игноришь аргументы оппонента, и сам в свою очередь приводишь те аргумнты, на которые уже отвечали и которые были разбиты в пух и прах.
Сорри, но к таким замашкам я тут обычно беспощаден. ))
Спорить уметь надо по-правилам, знаешь ли, или лучше даже не начинать...
