среда, 22 июля 2009 г.

Новости из Франкфурта

Пришли новости из Франкфурта – Concept’ы убрали из черновика стандарта, при том, что идея Concept’ов была, так сказать, блокбастером этого стандарта. Зато должны теперь успеть в срок со стандартом.

Зато мелких изменений очень много; и судя по тому как легко эти изменения будет использовать, – влияние на C++ они окажут как бы не большее чем Concept’ы.

Официально о Concept’ах – “этой особенности языка надо ещё выстоятся”… Похоже не совсем знают, как адаптировать к другим “плюшкам” в срок. Это было видно ещё раньше – стандартная библиотека в версии на сентябрь не включала в себя шаблоны с применёнными к ним Concept’ами.

В большинстве применений Concept’ы позволяют просто получать более читаемые ошибки для template’ов на соответствие некоторому интерфейсу, но насколько же с ними было бы удобно это делать:

Для меня введение Concept’ов (в виде automatic "concepts", на котором настаивал
Страуструп) позволяло перейти к питонообразному подходу при работе с шаблонными
функциями и классами. – Получать такие же значащие сообщения об ошибках можно и
другим способом – хоть через попытки приведения к некоторому интерфейсу или
родительскому классу. Но всё таки отношения вида “работая с этим шаблоном вы
обязуетесь, что ваш объект соответствует некоторому интерфейсу и
обладает некоторыми свойствами”, удобней чем “работая с этим шаблоном вы
обязуетесь, что ваш объект реализует некоторый интерфейс”. Т.к. в 1-м
случае набор функций в интерфейсе можно получить от различных источников
наследования, а во втором случае надо наследоваться от обязательного интерфейса,
что порождает ненужную связь в архитектуре, да и усложняет работу вцелом.

Так что, ждём этого стандарта и готовимся к следующему, в котором Concept’ы уже надеюсь будут.

Ссылки по теме:

Саттер: http://herbsutter.wordpress.com/2009/07/21/trip-report/

Страуструп: http://www.ddj.com/architect/218600111?pgno=1

среда, 15 июля 2009 г.

4 уровня компетентности

The "Kirkpatrick Model" by Donald L. Kirkpatrick gives four levels of (increasing) competence:

  • Unconscious Incompetence = you don't know that you can't do it well.
  • Conscious Incompetence = you know you can't do it well.
  • Conscious Competence = you do it well, and you think about the work as you do it.
  • Unconscious Competence = you're so successful it's "automatic" -- you do it well, without thinking about it.

    Красиво сказано… На текущих задачах скорее на 3-м уровне со значительным сдвигом в сторону 4-го. Хотя управленческая часть работы - это скорее 2-й уровень и может изредка 3-й.

  • четверг, 9 июля 2009 г.

    Python декораторы

    Казалось бы всё просто: декораторы – это просто статические фукции.

    Но ведь это функции, а в функции вполне можно передавать различные параметры… Причём не обязательно это должны быть константные значение либо имена типов (как пользуются декораторами почти везде). В декоратор можно передать значения считаные из файла настроек; главное, чтобы значение было определено до того как объявляется применение самого декоратора к функции. Для примера декоратор @measures получает на вход 3 разных значения, а значит функции linerFib, linerFib1 и stubFib будут “обрамляться” разными строками.

      1: teststring = 'test1'
     2: teststring1 = 'test2'
     3:  
     4: ...
     5:  
     6: @measures(teststring)
     7: def linerFib( n ):
     8:     fn = f1 = f2 = 1
     9:     for counter in xrange(2, n):
     10:        fn = f1 + f2
     11:         f2, f1 = f1, fn
     12: return fn
     13:  
     14: @measures(teststring1)
     15: def linerFib1( n ):
     16:     fn = f1 = f2 = 1
     17:     for counter in xrange(2, n):
     18:         fn = f1 + f2
     19:         f2, f1 = f1, fn
     20: return fn
     21:  
     22: teststring1 = 'test xxx'
     23: @measures(teststring1)
     24: def stubFib( n ):
     25:     return 5

    Но если бы всё только этим и ограничивалось… Самое интресное наступает, когда понимаешь, что декораторы могут возвращать и лямбда-функции. А ещё интересней становится, когда доходит что через лямбда-функцию можно вернуть не результат самой декорируемой функции, а экземпляр объекта, в котором есть метод __call__() , который и будет возвращать результат декорируемой функции. Да - это кажется перебором с вложеностью матрёшек, но вот с логической точки зрения провести разделение подготовки к вызову декорируемой функции и пост-обратотку её результата кажется довольно аппетитным… Т.е. можно провернуть следующее:

     1: class Drawer(object):
     2: def __init__(self, func, test):
    # подготовка и инициализация для вызова декорируемой функции
     3:     self.func = func
     4:     self.test = test
     5:  
     6: def __call__(self, *args):
    # сам вызов
     7:     print self.test
     8:     return self.func( *args )
     9:  
     10: def measures(test):
     11:     return lambda func: Drawer(func, test)

    Да, в большинстве случаев это будет довольно избыточно, но когда хочешь выводить график декорируемой функции в pygame, при этом не смешивая вывод результата на экран и расчёты и обработку результатов функции, то такие матрёшки становятся вполне удобными.