1. Lua / Говнокод #9627

    −87

    1. 1
    2. 2
    3. 3
    4. 4
    Splash = playGrayscaleSplashFx
    
    playGrayscaleSplashFx = function()
    end

    Хороший, годный аналог #define true false.
    Обнаружен в Lua-скрипте, автоматически включающемся во все скриптовые контексты (примерный аналог precompiled header).

    playGrayscaleSplashFx - функция, экспортируемая в Lua из C++ кода.

    Внёс в неё изменения, попытался протестировать результат... долго думал.

    Запостил: Kirinyale, 07 Марта 2012

    Комментарии (30) RSS

    • Чего тут думать? 8-е марта же, женская логика...
      Ответить
      • Если бы... Автор, кстати, уже пару месяцев как на другом проекте. Но наследие осталось.

        Дальнейшее расследование показало, что в некоторых скриптах вполне себе остались вызовы "отключённого" имени функции. Затем память подсказала, что в какой-то момент кем-то из дизайнеров была поставлена задача: убрать нафиг расплодившиеся спецэффекты-вспышки отовсюду, кроме мест A, B, C.

        Судя по элегантности решения, мы зря не рассказывали человеку про функцию поиска.
        Ответить
        • Эх, а вот в лиспе можно делать вот так:
          (defn my-function [] (println "Hello, World!"))
          (defn calling-my-function [] (my-function))
          
          (binding [user/my-function (fn [] (println "FUCK OFF"))]
            (calling-my-function)) ; will print "FUCK OFF"
          
          (calling-my-function) ; will print "Hello, World!"
          Ответить
          • Моя твой Лисп не понимай.
            Ответить
          • / - просто символ в имени, или в Кложуре так отделяется пакет от имени? Если второе, то почему нельзя было import + shadows (если использовать в текущем пакете) или просто setf - если навсегда?
            Ответить
            • / отделяет namespace от символа, для биндинга символов требуется указание именно полного имени (даже если символ определён в том же пространстве имён), для безопасности. Точнее, можно, но только в том случае, если функция помечена как dynamic http://ideone.com/iDVcO. Переопределить символ тоже можно (просто новый defn, как в REPL), но этот вариант неинтересен, ибо
              > убрать ... отовсюду, кроме мест A, B, C.
              Ответить
              • Это чем-то отличается от:
                (defpackage my-package 
                  (:use 'other-package) (:shadow #'some-function) ...)
                (defun some-function () ...)
                (some-function)
                (other-package::some-function)
                ?
                Хз, я когда вижу код на Кложуре, то у меня это вызывает примерно ощущение: "Пришел, наследил, испортил хорошую вещь!" - надеялся найти видео, но как-то нет его нигде...
                Ответить
                • Идея совсем в другом. Дело в том, что мы делаем my-function динамической: код, ссылающийся на эту функцию, будет использовать реализацию, предоставленную в binding, а не ту, которая цепляется из лексического контекста (даже в том случае, если вызов функции происходит в другом пространстве имён). Так можно и аналог АОП забабахать :)
                  Ответить
                  • Зачем? Я не понимаю, какая конечная цель / ожидаемый результат. Чем эта функция будет более "динамичной" чем любая другая?
                    Ответить
                    • Конечная цель - заменить реализацию функции, используемую в другом модуле. К примеру, есть функция, выполняющая некие полезные действия и на всякий случай ведущая лог аудита. Когда мы захотим написать юнит тест для этой функции, мы можем заменить вызов аудит-логгера пустышкой (так называемым стабом). Собственно, тестирование функций с побочными эффектами - основная причина, по которой делают binding функций. Это выглядит не очень здорово, и код почти всегда можно реорганизовать, сделав его более функциональным, но вещь всё же полезная.

                      Относительно примера: меняем реализацию функции со спец-эффектами на пустышку, а в тех местах, где спец-эффекты нужны - биндим к имени функции нормальную реализацию. Ход не айс, уж лучше сделать так, чтобы можно было передавать "спец-эффекты" в качестве параметра, но сама возможность впечатляет.
                      Ответить
                  • АОП это CLOS изобретенный двумя недоучками 30 лет спустя после того, как его уже один раз изобрели... Только, как обычно, не полностью.
                    Ответить
                    • АОП - это скорее идея, родившаяся в Lisp-сообществе. Современные её реализации (для жабы, к примеру) довольно сильно отличаются от оригинальных исследований. Вещь хорошая и полезная.
                      Ответить
                      • Все равно, зачем это так делать? Это не безопасно, т.как неизвестно каким образом чужой код использует эту функцию. Кроме того, есть для таких целей intern / unintern, которые, по крайней мере, какие-то тривиальные ошибки таких махинаций отловят. Но ситуация, когда нужно unintern в чужом пакете - уже плохая, если это какая-нибудь программа, которую нельзя останавливать по каким-то стратегическим соображениям - тогда еще можно понять, но если нет - лучше просто переписать так, чтобы это не было нужно.

                        Ну, в Лисп сообществе это не называют АОП. Бумагу, которую написали про АОП писали два Ява программиста, которые про Лисп не упомянули ни разу.
                        Ответить
    • http://safe.cnews.ru/news/top/index.shtml?2012/03/07/480558
      Почему этой рубрики нет на ГК?
      Ответить
      • И этот неизвестный язык наверное написан под неизвестную процессорную архитекруру. Лаборатория Касперского разыскивает государство производящее неизивестные миру процессоры и атакующее их самодельными вирусами. Как то странно, обычно такие статьи пишут про НЛО или неизвестных хищников-вампиров живущих в больших городах...
        Ответить
      • Наркоманы во все поля.
        Картинка с подписью "Создание червя Duqu потребовало разработки специального языка программирования" заставила улыбнуться.
        Ответить
        • После того как журнализды поработают над информацией там зачастую остается всего несколько процентов истины.

          >проверено около трех десятков языков программирования, «включая Brainfuck и Haskell».
          >включая Brainfuck
          Сетевой червь на Брейфаке. Пиздец-то какой.

          По поводу этого StuxNet говорили что он содержит очень много кода на чистом асме.
          Но в любом случае подобные статьи - это всего-лишь подборка слухов, испорченных телефонов, всяких домыслов и прочих откровений нихера не знающих вопроса "икспертов".
          Повторюсь - публикации в подобных желтых изданиях если и содержат истинные сведения, то в совсем ничтожных количествах.
          Ответить
          • Я и не сомневался никогда. Медийное не умеет доставлять достоверную картину мира, да ему и не требуется. Пипл схавает.
            Червь на Брейнфаке - отличная идея сама по себе.
            Ответить
      • Вот нормальная статься, вроде первоисточник.
        http://www.securelist.com/ru/blog/41063/Zagadka_freymvorka_Duqu
        Ответить
        • Эта быдла употребляет дворовое словечко «функционал».
          Ответить
        • Спасибо. Доставило. Особенно комменты...
          Ответить
        • Вспоминается ursus.
          Ответить
        • а ларчик просто открывался:
          "скорее всего, Фреймворк Duqu был скомпилирован MSVC 2008 с опциями /O1 /Ob1 из исходного текста на языке С."
          Ответить
        • http://www.securelist.com/ru/blog/207763871/Freymvork_Duqu_zadacha_reshena

          С теперь уже у нас стал неизвестным языком программирования
          Ответить

    Добавить комментарий