Раньше переписывали, судя по вики. Теперь же «Recent versions of Qt use the native style APIs of the different platforms to query the platform for the desired appearance of the Qt controls, and so do not suffer from such issues as much». Как я понимаю, и сейчас они используют не нативные контролы целевой платформы, но теперь их внешний вид запрашивается у системы. Надо исходники посмотреть.
> Представьте себе форму, на которой есть три кнопки, причем одна из них используется крайне редко, либо вообще не нужна, но тем не менее предусмотрена. Как предлагаете её скрыть?
Выносить во что-то подобное «More details/Fewer details» :-) Я, кстати, часто промахиваюсь, когда в диалоге, требующем ответа «Да» или «Нет», ещё и кнопку «Справка» добавляют)
Я считал, что речь идёт об элементе, который никогда на данной форме не становится активным, но посмотрел ещё раз скриншот… Если в одном из этих Confirm'ов, нажать «Yes», то вместо него будет выведена информация об удалении файлов, и тогда Fewer будет активным? Если так, то мой изначальный посыл был неверным, прошу прощения, вы правы.
Гм, а как вы себе это представляете? После выделения группы файлов система должна фризиться, превращаться в однозадачную и не реагировать на действия пользователя? Не думаю что это удачное решение.
Я не говорил, что система не должна давать возможности их выделить, фризится или делать что-либо ещё из описанного вами ужастика.
Я сказал, что система не должна выводить двадцать окон, если пользователь двадцать раз нажимает Del. Система должна адекватно реагировать на действия пользователя. Когда вы двадцать раз пытаетесь удалить одни и те же файлы, система должна предупредить, что в данной момент вы их уже пытаетесь удалить/удаляете в другом процессе, а не выдавать двадцать окон с просьбой подтверждения.
> Или вы так часто сталкиваетесь с интерфейсами, где если некий контрол не нужен он сразу скрывается (ставится на него атрибут Hide)?
В большинстве адекватных интерфейсов ненужные контролы скрыты, если они не относятся к текущему контексту. Первое, что приходит в голову в качестве примера, окно браузера. В большинстве из них (исключение — Safari), меня скрыто, так как большую часть времени пользователю (ок, большей части пользователей) оно не требуется.
Сюда же можно отнести принцип скрытия продвинутых функций. Обычно это происходит в текстовых процессорах, где существует миллион функций, но они скрыты до тех пор, пока не понадобятся. Также можно вспомнить банальный Wizard или DropDown. Вы действительно хотите видеть все шаги визарда сразу или все элементы дропдауна? Думаю, что нет, потому что «если некий контрол не нужен он сразу скрывается».
Так и здесь. Fewer Details относится именно к процессу копирования/удаления. В контексте подтверждения удаления этот элемент управления не имеет смысла.
Я считаю, что по-хорошему система:
1) не должна давать возможности выделить 10 файлов и нажать 20 раз Shift+Delete;
2) не должна показывать элементы, которые в данном контексте не имеют смысла. Т.е. раз Fewer нельзя сделать, то и зачем его выводить?
Ну да, только «как может», поэтому я и написал «частично». Мне кажется вариант с опциональными методами и возможностью проверки того, реализует класс метод, или нет, был бы чище с точки зрения ООП. Пусть даже без возможности проверки, а с выбрасыванием исключения, как это приведено в примере в посте, но только с выбросом исключения, без какой-либо логики.
Методы-расширения в шарпе — это чистейший синтаксический сахар, на интерфейс и класс они не влияют, они вообще не изменяют контракт. Даже лежат чаще всего в отдельном пространстве имён.
Как я понимаю да, в этом и суть «расширения», которое не ломает «существующий API». Т.е. если куча людей по всему миру используют вашу библиотеку, а вам позарез нужно добавить новый метод в интерфейс, то вы определяете такой вот дефолтный метод.
Это, увы, не extension. Это абстрактный класс с поддержкой множественного наследования. Т.е. интерфейс теперь определяет не только «что» должна делать реализация, но теперь ещё и частично «как». В общем, зря они это затеяли. Какой-то костыль для поддержания обратной совместимости.
И да, по поводу исключений. Код, на который вы делегируете ответственность за вызов работы, ничего не должен знать о том, что исключения внутри DoWorkInternal обрабатываются. Иначе настанет день, когда кто-то решит, что глотать исключения — это bad practice, и уберёт там try/catch, не зная о том, что где-то есть лямбда с Task.Factory, тем самым нечаянно создав опасную ситуации.
А почему пошли путём внедрения поддержки стратегии внутрь класса, а не сделали многопоточный декоратор поверх класса?
И почему бы тогда не сделать классическую реализацию стратегии? С конечным множеством допустимых стратегий. Лямбда — это, конечно, изящно, но:
1) теоретически приводит к дублированию, ведь при каждом асинхронном использовании воркера нам нужно устанавливать одну и ту же лямбду стратегии.
2) Поймёт ли разработчик, который придёт через год, что вы имели в виду под этим Action?
3) Не возникнут ли подводные камни при определенных лямбдах? Ведь при таком подходе множество лямбд бесконечно, и вы не сможете проверить работу этого класса со всеми лямбдами.
4) Не внесет ли эта дополнительная свобода хаос, когда в одном месте Task.Factory, а в двух других ThreadPool?
5) Нужна ли эта свобода, вы планируете, что количество стратегий будет расти?
> Получается, что ООП в JS для меня как инструмент с узким кругом задач под него.
Да, обычно это имеет смысл лишь при написании крупных фреймворков, например при создании GUI фреймворка вроде ExtJS.
А есть для Hibernate какой-то аналог FluentNHibernate? Мне всегда больше нравилось прописывать маппинг не в xml, и не в аннотациях (чтобы сохранить классы доменной модели POJO), а с помощью fluent интерфейса.
Ну и у самого Observable.Generate есть перегрузка с пятым параметром — ISheduler. Если уж писать об Observable.Generate можно было бы написать и о нём.
Вообще, обычно enumerator на русский язык транслитируют как энумератор.
Ну и да, пост объединил две не сильно связанные темы, при этом подробно не было рассказано ни об одной из них. Зачем нужны эти observable последовательности? Каково их применение?
Например, в конце поста Introduction to the Reactive Framework Part IV рассказано не только об Observable.Generate, и методах ToObservable и ToEnumerable, но и приведен пример практического использования push подхода — считывание строк файла в observable-way с тремя подписчиками, которые одновременно считают буквы, слова и гласные буквы по мере считывания файла.
Выносить во что-то подобное «More details/Fewer details» :-) Я, кстати, часто промахиваюсь, когда в диалоге, требующем ответа «Да» или «Нет», ещё и кнопку «Справка» добавляют)
Я считал, что речь идёт об элементе, который никогда на данной форме не становится активным, но посмотрел ещё раз скриншот… Если в одном из этих Confirm'ов, нажать «Yes», то вместо него будет выведена информация об удалении файлов, и тогда Fewer будет активным? Если так, то мой изначальный посыл был неверным, прошу прощения, вы правы.
Я не говорил, что система не должна давать возможности их выделить, фризится или делать что-либо ещё из описанного вами ужастика.
Я сказал, что система не должна выводить двадцать окон, если пользователь двадцать раз нажимает Del. Система должна адекватно реагировать на действия пользователя. Когда вы двадцать раз пытаетесь удалить одни и те же файлы, система должна предупредить, что в данной момент вы их уже пытаетесь удалить/удаляете в другом процессе, а не выдавать двадцать окон с просьбой подтверждения.
> Или вы так часто сталкиваетесь с интерфейсами, где если некий контрол не нужен он сразу скрывается (ставится на него атрибут Hide)?
В большинстве адекватных интерфейсов ненужные контролы скрыты, если они не относятся к текущему контексту. Первое, что приходит в голову в качестве примера, окно браузера. В большинстве из них (исключение — Safari), меня скрыто, так как большую часть времени пользователю (ок, большей части пользователей) оно не требуется.
Сюда же можно отнести принцип скрытия продвинутых функций. Обычно это происходит в текстовых процессорах, где существует миллион функций, но они скрыты до тех пор, пока не понадобятся. Также можно вспомнить банальный Wizard или DropDown. Вы действительно хотите видеть все шаги визарда сразу или все элементы дропдауна? Думаю, что нет, потому что «если некий контрол не нужен он сразу скрывается».
Так и здесь. Fewer Details относится именно к процессу копирования/удаления. В контексте подтверждения удаления этот элемент управления не имеет смысла.
1) не должна давать возможности выделить 10 файлов и нажать 20 раз Shift+Delete;
2) не должна показывать элементы, которые в данном контексте не имеют смысла. Т.е. раз Fewer нельзя сделать, то и зачем его выводить?
Методы-расширения в шарпе — это чистейший синтаксический сахар, на интерфейс и класс они не влияют, они вообще не изменяют контракт. Даже лежат чаще всего в отдельном пространстве имён.
И почему бы тогда не сделать классическую реализацию стратегии? С конечным множеством допустимых стратегий. Лямбда — это, конечно, изящно, но:
1) теоретически приводит к дублированию, ведь при каждом асинхронном использовании воркера нам нужно устанавливать одну и ту же лямбду стратегии.
2) Поймёт ли разработчик, который придёт через год, что вы имели в виду под этим Action?
3) Не возникнут ли подводные камни при определенных лямбдах? Ведь при таком подходе множество лямбд бесконечно, и вы не сможете проверить работу этого класса со всеми лямбдами.
4) Не внесет ли эта дополнительная свобода хаос, когда в одном месте Task.Factory, а в двух других ThreadPool?
5) Нужна ли эта свобода, вы планируете, что количество стратегий будет расти?
Да, обычно это имеет смысл лишь при написании крупных фреймворков, например при создании GUI фреймворка вроде ExtJS.
Ну и да, пост объединил две не сильно связанные темы, при этом подробно не было рассказано ни об одной из них. Зачем нужны эти observable последовательности? Каково их применение?
Например, в конце поста Introduction to the Reactive Framework Part IV рассказано не только об Observable.Generate, и методах ToObservable и ToEnumerable, но и приведен пример практического использования push подхода — считывание строк файла в observable-way с тремя подписчиками, которые одновременно считают буквы, слова и гласные буквы по мере считывания файла.