Это подход Ruby и JS, но не Python. В последнем переменные (функции и классы — это тоже переменные) становятся атрибутами объекта модуля, в котором они декларированы, что не совсем то же самое.
Оборачивать можно сильно по-разному. Одно дело, если оно оборачивает непосредственно нативные виджеты. Другое — если оно свои собственные виджеты рисует через стандартное графическое API.
А так, в конечном счете, любой фреймворк — это всегда обертка над системными библиотеками.
Для всего этого не нужен свой класс строки. Просто добавьте нужный функционал как глобальные функции, принимающие std::string/wstring (а еще лучше — basic_string). Вообще, пихание всей подряд функциональности непосредственно в класс, даже если ей не нужен доступ к private состоянию — это не C++ way.
Зато со всеми этими классами строк постоянно проблемы, когда нужно подружить два фреймворка. Понятно, что можно преобразовать типы, где надо. Но это 1) геморрой, и 2) дорогое и ненужное копирование данных.
В плюсах очень убогие макросы. Верхней планкой для макросов был и остается Common Lisp, разумеется (в котором reader macros позволяют менять поведение вплоть до уровня лексера, т.е. работать с исходником напрямую как с потоком символов). Но в качестве разумной планки можно посмотреть на Scheme, Nemerle, D.
А в чем неприятность Dispose в foreach? foreach явно создает новый экземпляр энумератора в начале работы, он же его и подчищает в конце, если необходимо. Если бы он этого не делал, как бы вы реализовывали подчистку после foreach? Ведь сам энумератор не доступен, это внутренняя переменная, видимая только компилятору.
Собственно, именно так оно и реализуется в стандартных коллекциях — поле version в самой коллекции, которое инкрементируется при каждом изменении, и сохраняется в энумераторе в момент его создания — а потом сравнивается в Current/MoveNext. Коллекция о своих энумераторах не знает.
Dispose же нужен для коллекций и прочих перечислений, у которых энумераторы реально владеют какими-то требующими явного высвобождения ресурсами — например, курсором БД, или файловым хэндлом. А также для вызова блоков finally в методах-итераторах.
В английском это имеет значение, аналогичное русскому «и тэ дэ и тэ пэ». Только пишется это чаще не yada-yada, а yadda-yadda (хотя оба варианта допустимы и популярны). К японскому не имеет никакого отношения.
Японский к русскому тоже не имеет никакого отношения, его вообще большинство лингвистов полагает изолированным языком — а кто не полагает, прослеживают связь с алтайскими, которые с русским (индоевропейским языком) тоже никак не связаны.
Как владелец Adam могу сказать из личного опыта, что в планшете такой экран отвратителен. На практике в режиме без подсветки все очень темно (контрастность ниже, чем у первых поколений eInk читалок), и им реально пользоваться только под открытым небом, желательно в солнечный день. С подсветкой же все так же грустно, но уже по сравнению с активными матрицами.
У IronPython есть еще одна интересная особенность. Поскольку он использует DLR, который по сути является стандартным способом реализации динамически типизированных языков на CLR, то он совместим с другими языками, тоже использующими DLR. Т.е., например, с IronRuby — можно создать объект в руби, передать его в питон, и подергать на нем методы.
PyPy, как и все прочие альтернативные реализации, намного (не в разы даже, а на порядки) менее популярен, чем CPython. И несовместимость со многими нативными расширениями — основная причина.
Cython не обязательно статически типизирован. Он может взять произвольный питоновский код, и выдать семантически эквивалентный ему сишный (в теории — на практике у них не стопроцентное покрытие языка).
Но это принципиально не отличается от запуска CPython VM под asm.js.
Я понимаю. Проблема в том, что низлежащая VM в данном случае имеет GC, семантика которого не соответствует тому, что ожидает увидеть типичный код на питоне — поэтому использовать его в любом случае неудобно.
Кстати, если исходить из того, что asm.js по производительности реально близок к нативному коду — почему свой собственный сборщик мусора будет сильно медленнее стандартного?
А так, в конечном счете, любой фреймворк — это всегда обертка над системными библиотеками.
Т.е. оно даже и заголовки у окон само рисует вырвиглазным образом, вместо того, чтобы использовать нативный look & feel?
Зато со всеми этими классами строк постоянно проблемы, когда нужно подружить два фреймворка. Понятно, что можно преобразовать типы, где надо. Но это 1) геморрой, и 2) дорогое и ненужное копирование данных.
Не пишите свой класс строки на C++. Пожалуйста.
Dispose же нужен для коллекций и прочих перечислений, у которых энумераторы реально владеют какими-то требующими явного высвобождения ресурсами — например, курсором БД, или файловым хэндлом. А также для вызова блоков finally в методах-итераторах.
Японский к русскому тоже не имеет никакого отношения, его вообще большинство лингвистов полагает изолированным языком — а кто не полагает, прослеживают связь с алтайскими, которые с русским (индоевропейским языком) тоже никак не связаны.
Впрочем, в конечном счете, слишком много или не слишком — решит рынок.
Но это принципиально не отличается от запуска CPython VM под asm.js.
Кстати, если исходить из того, что asm.js по производительности реально близок к нативному коду — почему свой собственный сборщик мусора будет сильно медленнее стандартного?