С IE все не так просто, там все зависит от платформы. На десктопной винде можно скачать и поставить WebM-кодек, и он будет работать в HTML5 video, т.к. в IE он прописан в whitelist разрешенных кодеков (собственно, прописан только он и коробочный H.264).
Требование HTML5 противоречит здравому смыслу — на нем просто невозможно в рамках существующего гугловского API написать полноценное приложение-плеер. По каковой причине, собственно, сам гугл на нем их и не пишет, ни под iOS, ни под андроид. Т.е. это требование — это классическое «а ты, негр, назови их всех поименно».
кажется под HTML5 гугл имел в виду, просто сделайте интеграцию HTML5 плеера. У гугла же он есть и он же с рекламой.
Собственно, именно так работало самое первое приложение YouTube от MS, а также и пара десятков сторонних поделий в магазине приложений. Только вот функциональность этого решения, по сравнению с полноценным приложением, очень низкая — что и отражалось в рейтингах и отзывах к этим приложениям.
Чтобы ощутить на себе, попробуйте на недельку забыть про существование на вашем мобильном устройсте YouTube app, и пользоваться для просмотра только браузером.
Статьи реально отличные, когда писал смешанный отладчик для питона в PTVS — они очень помогли разобраться в исходниках интерпретатора.
Кстати, если кто хочет не просто читать статьи, а на самом деле подебажить ceval.c на живом питоновском коде, у нас есть для этого забавная недокументированная фича — включается вот этим .reg, и в контекстном меню у окон отладчика появляются пункты «Show Native Python Frames» и «Use Python Stepping».
Первая опция включает показ фреймов из python*.dll, параллельно с соответствующими им питоновскими фреймами (они мапятся на нативные фреймы в PyEval_EvalFrameEx) — в результате получается что-то такое:
Хорошо видно, как работает вызов функции, например. Ну и отображение сишных PyObject* в виде питоновских объектов помогает быстрее разобраться, что там происходит.
Вторая опция позволяет выключать специальную обработку пошаговой отладки внутри python*.dll, чтобы команды Step In / Step Out / Step Over работали не на уровне питоновского кода, а на уровне C. Т.е. чтобы можно было пошагово ходить внутри главного цикла интерпретатора.
А чем принципиально комментарии вида «match foo, then bar or baz» будут отличаться от приведенной записи — кроме того, что со временем регулярка и комментарий могут «разъехаться»?
Хотя на самом деле проблема с регулярками не столько в читаемости нотации, сколько в её компактности — последняя позволяет запихнуть очень много логики в очень малый объем кода, причем без каких-либо логических границ, все в кучу. В этом смысле бывает удобно включить игнорирование whitespace и попытаться выделить структуру отступами.
Еще иногда помогает побить строку регулярки на именованные части — т.е. каждый отдельный логический кусок присваивается отдельной именованной переменной, которые потом комбинируются — что-то вроде функций. Например, если парсим абсолютный URI, то можно разбивать прямо по RFC:
Видимо, вам никогда не доводилось разбирать пятистрочную регулярку без комментариев…
Да, разумеется, магии там никакой нет, и всегда можно поэтапно разобраться — особенно если добавлять комментарии по мере разбора. Но вам не кажется, что если для понимания нескольких строчек кода кода нужно несколько минут внимательно разбирать их, то это намекает на некоторые проблемы в нотации?
Очевидный вопрос — если регэкспы по сравнению с данной библиотекой предоставляют дополнительные «3 спецсимвола да пару квантификаторов», то что мешает их в нее добавить?
Ведь очевидно же, что можно сделать легко читаемый DSL для регэкспов произвольной сложности. И при этом он будет короче, чем ваш пример с комментариями, потому что большая часть этих комментариев будет не нужна.
Единственный момент — для подобных библиотек желательно строго привязывать семантику к обычным регуляркам, чтобы можно было легко переводить код туда-обратно, даже чисто механически. Т.е. пусть это будет такой многословный syntactic sugar.
Я не вижу разницы в том, является ли это объявлением, или нет. Где-то там есть и объявление list тоже, и в нем явно указан тип элементов. Зачем его постоянно повторять при действиях над этим объектом? И неужели при чтении кода неочевидно, что в list.filter(f -> ...) тип f — это тип элемента?
На самом деле Project Lambda начал с намного более амбициозного дизайна — например, там были полноценные function types и throws-параметры у дженериков (для строго типизированного прозрачного проброса исключений high-order functions). Но в процессе дизайна практически все плюшки выпилили.
А в Java 7 лямбды не попали просто потому, что тогда дизайн был еще очень далек от завершения.
VC++ проекты уже давно суть MSBuild-мейкфайлы, с зависимостями, параллелизацией и прочим. Причем solutions для разруливания зависимостей не нужны, это чисто VS-артефакт, а так можно просто запустить MSBuild на файл проекта, который выдает конечный результат, и все зависимости построятся автоматом.
Чтобы выпустить устройство на рынок, хватит и CM и прочих рутованых прошивок. А при должном пиаре (который они уже имеют, кстати), тот же Самсунг сам бросится их поддерживать, ибо усилий там надо приложить совсем немного, а wow-эффект будет отменный.
Кстати, автоматически генерируемый Equals и GetHashCode для анонимных типов очень удобно использовать, определяя свои, если нужен value equality по всем или нескольким полям. Например:
struct Point {
public int X { get; private set; }
public int Y { get; private set; }
...
public override int GetHashCode() {
return new { X, Y }.GetHashCode();
}
}
Поскольку MutableStruct — это value-тип, то при использовании его в качестве ключа таблица получит свою отдельную копию. И изменение оригинальной структуры, как в вашем примере, на этой копии никаким образом не отразится.
Собственно, об этом и речь — изменить поля у value typed ключа в хеш-таблице можно только в том случае, если он явно предоставит API для такого изменения.
Собственно, именно так работало самое первое приложение YouTube от MS, а также и пара десятков сторонних поделий в магазине приложений. Только вот функциональность этого решения, по сравнению с полноценным приложением, очень низкая — что и отражалось в рейтингах и отзывах к этим приложениям.
Чтобы ощутить на себе, попробуйте на недельку забыть про существование на вашем мобильном устройсте YouTube app, и пользоваться для просмотра только браузером.
Кстати, если кто хочет не просто читать статьи, а на самом деле подебажить ceval.c на живом питоновском коде, у нас есть для этого забавная недокументированная фича — включается вот этим .reg, и в контекстном меню у окон отладчика появляются пункты «Show Native Python Frames» и «Use Python Stepping».
Первая опция включает показ фреймов из python*.dll, параллельно с соответствующими им питоновскими фреймами (они мапятся на нативные фреймы в PyEval_EvalFrameEx) — в результате получается что-то такое:
Хорошо видно, как работает вызов функции, например. Ну и отображение сишных PyObject* в виде питоновских объектов помогает быстрее разобраться, что там происходит.
Вторая опция позволяет выключать специальную обработку пошаговой отладки внутри python*.dll, чтобы команды Step In / Step Out / Step Over работали не на уровне питоновского кода, а на уровне C. Т.е. чтобы можно было пошагово ходить внутри главного цикла интерпретатора.
Хотя на самом деле проблема с регулярками не столько в читаемости нотации, сколько в её компактности — последняя позволяет запихнуть очень много логики в очень малый объем кода, причем без каких-либо логических границ, все в кучу. В этом смысле бывает удобно включить игнорирование whitespace и попытаться выделить структуру отступами.
Еще иногда помогает побить строку регулярки на именованные части — т.е. каждый отдельный логический кусок присваивается отдельной именованной переменной, которые потом комбинируются — что-то вроде функций. Например, если парсим абсолютный URI, то можно разбивать прямо по RFC:
Только автозахват у скобок надо отключать при таком подходе. Хотя он вообще зло.
Да, разумеется, магии там никакой нет, и всегда можно поэтапно разобраться — особенно если добавлять комментарии по мере разбора. Но вам не кажется, что если для понимания нескольких строчек кода кода нужно несколько минут внимательно разбирать их, то это намекает на некоторые проблемы в нотации?
Ведь очевидно же, что можно сделать легко читаемый DSL для регэкспов произвольной сложности. И при этом он будет короче, чем ваш пример с комментариями, потому что большая часть этих комментариев будет не нужна.
Единственный момент — для подобных библиотек желательно строго привязывать семантику к обычным регуляркам, чтобы можно было легко переводить код туда-обратно, даже чисто механически. Т.е. пусть это будет такой многословный syntactic sugar.
Для сравнения, немецкий пистолет-пулемет MP 40 — 500 выстрелов в минуту, АКМ — 600. Не такая большая разница.
list.filter(f -> ...)тип f — это тип элемента?А в Java 7 лямбды не попали просто потому, что тогда дизайн был еще очень далек от завершения.
list.add(f), вас не смущает отсутствие явного указания типа элементов list? Если нет, то в чем именно разница?Собственно, об этом и речь — изменить поля у value typed ключа в хеш-таблице можно только в том случае, если он явно предоставит API для такого изменения.