Вложенные классы для этого неэффективны. Лямбды дают много возможностей, и их легковесность поощряет их частое использование, особенно совместно с такими вещами как библиотека стримов или какие-нибудь новые фреймворки, сделанные с учётом лямбд. Количество вложенных классов будет возрастать стремительно. Например, в скале, где анонимные функции используются буквально везде, переход на бэкенд, генерирующий лямбды аналогично javac восьмой версии, позволил уменьшить количество классов в несколько раз.
Кроме того, у лямбд другая семантика, они не просто синтаксический сахар. Это видно, в частности, из данной статьи. У них другая семантика в отношении вывода типов и в отношении захвата this. Вот здесь есть небольшое описание в первом ответе. Сделать аналогично поверх классов сложно.
Да, всё так. Lock-файл (эта идея пришла, кажется, из Bundler'а и с огромным успехом сейчас используется в Rust'овом Cargo) фиксирует версии всех зависимостей, транзитивных в том числе. Кажется, ещё yarn решает проблему с недетерминированным порядком установки пакетов и их расположению в файловой системе, которая есть у npm.
При использовании UTF-8 и UTF-16BE (здесь, кажется, Bozaro немного ошибся) последовательности code unit'ов, если их представить в виде чисел, возрастают согласно unicode scalar value'ам, которые они представляют. В UTF-16LE же это не так.
К примеру, возьмём символ U+10FF. В UTF-16BE он будет представлен как число 10FF, или как два байта со значениями 16 и 255. В UTF-16LE он будет представлен как FF10, или два байта со значениями 255 и 16. А теперь возьмём символ U+1100, следующий по номеру за U+10FF. В UTF-16BE он будет представлен как 1100, или 17 и 0. А в UTF-16LE он будет представлен как 0011, или 0 и 17. Получается такое:
Если сравнивать эти последовательности побайтно, то получается, что в UTF16-LE символ с кодом U+1100 будет "меньше" символа с кодом U+10FF, что противоречит порядку возрастания номеров символов в юникоде. Из-за этого наивная побайтовая, и даже пословная (по 2 байтам) сортировка будет давать весьма странные результаты при использовании UTF-16LE. Представления символов в UTF-8 я писать выше не стал, но там ситуация аналогична UTF-16BE — десятичные представления code point'ов возрастают согласно таблице юникода.
Строго говоря, в Java и в винде используется UCS-2, а не UTF-16. В частности, в Java char — это 16-битное число, которого, очевидно, недостаточно для представления всех символов юникода. В UTF-16, чтобы обойти эту проблему с недостаточным размером code unit'а, вводятся так называемые суррогатные пары, к которым в общем случае в Java/WinAPI доступ предоставляется раздельно. Ну то есть, нет ограничителей, которые не позволяли бы работать с отдельными code unit'ами. Из-за этого, если писать программы неаккуратно, можно получить проблемы с символами вне BMP.
Вот ещё очень хороший и правильный сайт, который объясняет почему UTF-8 это лучшее из представлений юникода: http://utf8everywhere.org/
Быстрая зарядка у самсунгов — это не только ток два ампера, но ещё и напряжение в 9 вольт, кажется. Оно на самом деле заряжает телефон даже с аккумулятором большой ёмкости довольно быстро. Но действительно вряд ли оно в данном случае виновато, иначе бы телефоны действительно бы взрывались на зарядке.
Нет, там настройки AHCI/RAID сбрасываются, даже если их принудительно переписать через EFI-переменные. Проблему смогли решить, только перепрошив встроенную прошивку через припаяанный программатор, что весьма нетривиально.
В конец предыдущей строки курсор попадает, только если он находится на текущем или меньшем уровне вложенности. Если на большем, то редактор просто убирает один уровень вложенности.
Только что проверил — да, правда, так и есть. Удаляет до того уровня вложенности, который положен на этом месте согласно форматированию. К таким вещам привыкаешь и перестаёшь в итоге их замечать)
Более того, в новых версиях идеи (c 14-й, если не ошибаюсь) бэкспейс в начале строки, когда ничего кроме отступов нет, не только удалит все отступы, но и вернёт курсор на предыдущую строку, что весьма удобно.
неправильно расположенные { } вываливаются в ошибку компиляции
Это не из-за того что это стилевая ошибка, просто лексер языка устроен так чтобы автоматически "вставлять" точки с запятой в нужных местах. Механизм этой автоматической расстановки точек с запятой описан в спецификации, и из него следует, что ifы и прочие стейтменты должны содержать открывающую скобку на той же строке, иначе точка с запятой вставится не туда, куда нужно. То, что это принуждает использовать конкретный стиль, является следствием, а не причиной и не основной мотивацией.
Библиотека кстати называется Typesafe Config; это язык называется HOCON. И кстати, Typesafe Config — это go-to библиотека для конфигурации проектов на Scala, потому что многие популярные фреймворки и библиотеки, в частности, Play Framework и Akka, используют именно её.
Мне кажется, что на Swift сейчас написано гораздо меньше кода, чем на Python 2 в то время, когда появился Python 3. Скорее всего, переход на новую версию Swift будет гораздо менее болезненным, даже без "инъекции бабла".
extends — это верхняя граница, а super — нижняя, у вас же наоборот. Легко представить, почему так: ? extends Something означает какой-то тип, наследующий Something, т.е. находящийся ниже по дереву наследования классов, следовательно, Something — это его верхняя граница. Аналогично с super: ? super Something это какой-то тип, являющийся супертипом Something, т.е. находящийся выше по дереву наследования классов, следовательно, Something — это его нижняя граница.
Вложенные классы для этого неэффективны. Лямбды дают много возможностей, и их легковесность поощряет их частое использование, особенно совместно с такими вещами как библиотека стримов или какие-нибудь новые фреймворки, сделанные с учётом лямбд. Количество вложенных классов будет возрастать стремительно. Например, в скале, где анонимные функции используются буквально везде, переход на бэкенд, генерирующий лямбды аналогично javac восьмой версии, позволил уменьшить количество классов в несколько раз.
Кроме того, у лямбд другая семантика, они не просто синтаксический сахар. Это видно, в частности, из данной статьи. У них другая семантика в отношении вывода типов и в отношении захвата this. Вот здесь есть небольшое описание в первом ответе. Сделать аналогично поверх классов сложно.
Да, всё так. Lock-файл (эта идея пришла, кажется, из Bundler'а и с огромным успехом сейчас используется в Rust'овом Cargo) фиксирует версии всех зависимостей, транзитивных в том числе. Кажется, ещё yarn решает проблему с недетерминированным порядком установки пакетов и их расположению в файловой системе, которая есть у npm.
При использовании UTF-8 и UTF-16BE (здесь, кажется, Bozaro немного ошибся) последовательности code unit'ов, если их представить в виде чисел, возрастают согласно unicode scalar value'ам, которые они представляют. В UTF-16LE же это не так.
К примеру, возьмём символ U+10FF. В UTF-16BE он будет представлен как число 10FF, или как два байта со значениями 16 и 255. В UTF-16LE он будет представлен как FF10, или два байта со значениями 255 и 16. А теперь возьмём символ U+1100, следующий по номеру за U+10FF. В UTF-16BE он будет представлен как 1100, или 17 и 0. А в UTF-16LE он будет представлен как 0011, или 0 и 17. Получается такое:
Если сравнивать эти последовательности побайтно, то получается, что в UTF16-LE символ с кодом U+1100 будет "меньше" символа с кодом U+10FF, что противоречит порядку возрастания номеров символов в юникоде. Из-за этого наивная побайтовая, и даже пословная (по 2 байтам) сортировка будет давать весьма странные результаты при использовании UTF-16LE. Представления символов в UTF-8 я писать выше не стал, но там ситуация аналогична UTF-16BE — десятичные представления code point'ов возрастают согласно таблице юникода.
Строго говоря, в Java и в винде используется UCS-2, а не UTF-16. В частности, в Java
char— это 16-битное число, которого, очевидно, недостаточно для представления всех символов юникода. В UTF-16, чтобы обойти эту проблему с недостаточным размером code unit'а, вводятся так называемые суррогатные пары, к которым в общем случае в Java/WinAPI доступ предоставляется раздельно. Ну то есть, нет ограничителей, которые не позволяли бы работать с отдельными code unit'ами. Из-за этого, если писать программы неаккуратно, можно получить проблемы с символами вне BMP.Вот ещё очень хороший и правильный сайт, который объясняет почему UTF-8 это лучшее из представлений юникода: http://utf8everywhere.org/
del
В первую очередь здесь, вероятно, имеется в виду object slicing. Но вроде бы там были и другие подводные камни.
Только что проверил — да, правда, так и есть. Удаляет до того уровня вложенности, который положен на этом месте согласно форматированию. К таким вещам привыкаешь и перестаёшь в итоге их замечать)
Да, здесь я полностью согласен)
Более того, в новых версиях идеи (c 14-й, если не ошибаюсь) бэкспейс в начале строки, когда ничего кроме отступов нет, не только удалит все отступы, но и вернёт курсор на предыдущую строку, что весьма удобно.
Это не из-за того что это стилевая ошибка, просто лексер языка устроен так чтобы автоматически "вставлять" точки с запятой в нужных местах. Механизм этой автоматической расстановки точек с запятой описан в спецификации, и из него следует, что
ifы и прочие стейтменты должны содержать открывающую скобку на той же строке, иначе точка с запятой вставится не туда, куда нужно. То, что это принуждает использовать конкретный стиль, является следствием, а не причиной и не основной мотивацией.Вообще конечно компилируются, просто подавляющее большинство разработчиков запускает gofmt после сохранения/перед коммитом.
Здесь я оставлю ссылку на проект SIPа который делает именно это и даже круче. Есть шанс, что в каком-то виде в новых версиях скалы это появится.
Библиотека кстати называется Typesafe Config; это язык называется HOCON. И кстати, Typesafe Config — это go-to библиотека для конфигурации проектов на Scala, потому что многие популярные фреймворки и библиотеки, в частности, Play Framework и Akka, используют именно её.
Мне кажется, что на Swift сейчас написано гораздо меньше кода, чем на Python 2 в то время, когда появился Python 3. Скорее всего, переход на новую версию Swift будет гораздо менее болезненным, даже без "инъекции бабла".
extends— это верхняя граница, аsuper— нижняя, у вас же наоборот. Легко представить, почему так:? extends Somethingозначает какой-то тип, наследующийSomething, т.е. находящийся ниже по дереву наследования классов, следовательно,Something— это его верхняя граница. Аналогично сsuper:? super Somethingэто какой-то тип, являющийся супертипом Something, т.е. находящийся выше по дереву наследования классов, следовательно,Something— это его нижняя граница.