Ну что является основным продуктом программирования под iOS, например? Небольшая модель, и много ViewController'ов. Методы, которые скрывают и показывают элементы интерфейса, дергают другие функции (уже на моделях) и т.д… Как mock'ать объекты, как разобраться с тем, что структура view такая, как мне нужна, и т.д.? Как покрыть этот код хотя бы на 90%.
Class variable и Instance variable — это две разные сущности (имеют разную семантику и синтаксис, var и @var соответственно). А такой сущности, как class instance variable, не существует. Мне кажется не стоит людям для мнимой простоты объяснения (которая выльется в непонимание системы на более сложных уровнях) придумывать лишние сущности, система и без них очень лаконичная и красивая :)
Не стоит придумывать отдельное такое понятие, как «Class-level instance variable» :) Есть просто Instance variable, привязанная к объекту. В каждом конкретном контексте Instance-переменная привяжется к объекту, на который указывает self. Self меняется не очень часто, есть весьма небольшой набор т.н. «Scope Gates», при прохождении через которые может измениться(и скорее всего изменится) self. Это ключевые слова class, module, def, а так же методы instance_eval и class_eval
И заявленное равенство «self.class.attr_accessor :a» и «class << self; attr_accessor :a; end;» неверно
Обойти private можно легко, для этого достаточно воспользоваться публичным методом send. Но вариант с «self.class» добавит attr_accesor :a ДЛЯ ВСЕХ объектов, которые являются инстансами класса Class. А вариант с eigenclass'ом — только для нашего класса, что нам и нужно.
class A;
end;
A.a # => NoMethodError: undefined method `a' for A:Class
class B
self.class.send(:attr_accessor, :a)
end
B.a = 2 # => 2
B.a # => 2
A.a # => nil
Вы явно пытаетесь решать или не ту задачу, или не теми средствами.
Если вы хотите, что бы приложение было standalone и требовало минимум усилий по установке в порыве заботы о «рядовых пользователях» — пишите на Obj-C. Иначе это скоро кончится тем, что вы и сам macRuby прилинкуете жестко и положите в пэкэдж, а то вдруг выйдет новая версия, и ваш код окажется работать без какого-нибудь небольшого фикса. Такие случаи медицине известны.
Отказ от велосипедов и массированное использование гемов — один из столпов руби, сама идея жестко их линковать выглядит противоестественной, о чем тут и намекнули. Установка гемов проста как никогда, для этого люди приложили много усилий. Если беспокоят какие-то сложности — напишите установочный шелл-скрипт, он может все разруливать очень умным образом. И если вы пойдете этим путем, то образовательный эффект будет гораздо больше.
Внимание, вопрос. А зачем вы вообще тогда взялись на MacRuby писать?! Не лучше ли на нативном Obj-C? По времени вышло бы столько же, задача тривиальная благо. И никаких бы проблем не было.
Никак паковать не надо в app, зачем? Или все библиотеки линкуемые вы тоже всегда к приложению прикладываете? :) Надо это написать в prerequisites или в самом скрипте сделать проверку, что б ежели что отсутствует — выдавал полный список требуемых гемов и инструкции по установке.
Прям уж так и полироль.
Напомню цикл рефакторинга. Зафиксировали состояние — изменили — убедились, что не сломалось.
И да, изменения атомарны. Но если каждое изменение маленькое — совсем не значит, что таким образом мало что можно изменить. Постепенным движением можно перелопатить пол-проекта, включая даже какие-то архитектурные основания.
И да, таким методом можно победить синдром «все переписать».
Нет, я не высмеиваю AS, напротив. Просто большая часть пунктов в том или ином виде применима ко всем язык, даже стоит над языками, являясь необходимыми навыками для любого человека, называющего себя программистом. Поэтому я несколько удивлен, что для кого-то эти пункты могут стать откровением. :)
Это как если бы кто-то сказал «Serion Flash Dev должен чистить зубы по утрам!»
Официально он появился вообще только в 1.9 в стандарте. До этого жил в рельсах(или даже конкретно ActiveRecord?), а вообще код сам простой очень, уверен что сам метод начали использовать много раньше — неоднократно встречал просто объявленным в коде без подключения сторонних либ
:key — это просто базовый тип Symbol, представляющий из себя интернализированную строку (а не полноценный объект String)
Для хэша в качестве ключа может использоваться совершенно любой объект.
Т.е. допустимым является:
hash = {}
hash[:key] = «value»
hash[2] = «value 2»
hash[«22»] = :key
hash[hash.class] = 2
ну и т.д. :)
Потому когда используется hash.each_pair{ |key,value|… } в качестве key может быть переменная совершенно любого вида.
Ох-ох, простите, в первую-то линку не заглянул. В прочем, тема реализации в топики не раскрыта, потому не так страшно :)
От себя порекомендую книгу Metaprogramming Ruby, мне на первом этапе она донесла вполне четкое понимание того, как вся классовая кухня работает, так что больше на этом я ни разу не спотылся.
P.S. Напомним, что Class < Module, хоть это и сокрыто в дебрях, но почти все, что сказано про классы, касается и модулей. Обычно даже наоборот пишут про модули, а потому говорят, что класс — тот же самый модуль, но умеющий инстанцировать объекты.
Class.new.methods — Module.new.methods #=> [«superclass», «allocate», «new»]
Концепт хороший. Но у вас пример довольно легкий, и больше похож на функциональное тестирование. Т.е. те подсистемы, которые лежат внутри словаря (хранилище данных, какие-то другие самостоятельные объекты) не экранированы. Точно хорошо подойдет для тех мест, где получаются какие-то данные извне.
А что насчет сложности проверки самой целостности? Есть подозрения, что это может быть весьма и весьма нетривиальной задачей в более сложных случаях.
Вообще любопытно, хоть chaos-mockup делай :)
varи@varсоответственно). А такой сущности, как class instance variable, не существует. Мне кажется не стоит людям для мнимой простоты объяснения (которая выльется в непонимание системы на более сложных уровнях) придумывать лишние сущности, система и без них очень лаконичная и красивая :)И заявленное равенство «self.class.attr_accessor :a» и «class << self; attr_accessor :a; end;» неверно
Обойти private можно легко, для этого достаточно воспользоваться публичным методом send. Но вариант с «self.class» добавит attr_accesor :a ДЛЯ ВСЕХ объектов, которые являются инстансами класса Class. А вариант с eigenclass'ом — только для нашего класса, что нам и нужно.
Если вы хотите, что бы приложение было standalone и требовало минимум усилий по установке в порыве заботы о «рядовых пользователях» — пишите на Obj-C. Иначе это скоро кончится тем, что вы и сам macRuby прилинкуете жестко и положите в пэкэдж, а то вдруг выйдет новая версия, и ваш код окажется работать без какого-нибудь небольшого фикса. Такие случаи медицине известны.
Отказ от велосипедов и массированное использование гемов — один из столпов руби, сама идея жестко их линковать выглядит противоестественной, о чем тут и намекнули. Установка гемов проста как никогда, для этого люди приложили много усилий. Если беспокоят какие-то сложности — напишите установочный шелл-скрипт, он может все разруливать очень умным образом. И если вы пойдете этим путем, то образовательный эффект будет гораздо больше.
Никак паковать не надо в app, зачем? Или все библиотеки линкуемые вы тоже всегда к приложению прикладываете? :) Надо это написать в prerequisites или в самом скрипте сделать проверку, что б ежели что отсутствует — выдавал полный список требуемых гемов и инструкции по установке.
Напомню цикл рефакторинга. Зафиксировали состояние — изменили — убедились, что не сломалось.
И да, изменения атомарны. Но если каждое изменение маленькое — совсем не значит, что таким образом мало что можно изменить. Постепенным движением можно перелопатить пол-проекта, включая даже какие-то архитектурные основания.
И да, таким методом можно победить синдром «все переписать».
Это как если бы кто-то сказал «Serion Flash Dev должен чистить зубы по утрам!»
Для хэша в качестве ключа может использоваться совершенно любой объект.
Т.е. допустимым является:
hash = {}
hash[:key] = «value»
hash[2] = «value 2»
hash[«22»] = :key
hash[hash.class] = 2
ну и т.д. :)
Потому когда используется hash.each_pair{ |key,value|… } в качестве key может быть переменная совершенно любого вида.
От себя порекомендую книгу Metaprogramming Ruby, мне на первом этапе она донесла вполне четкое понимание того, как вся классовая кухня работает, так что больше на этом я ни разу не спотылся.
P.S. Напомним, что Class < Module, хоть это и сокрыто в дебрях, но почти все, что сказано про классы, касается и модулей. Обычно даже наоборот пишут про модули, а потому говорят, что класс — тот же самый модуль, но умеющий инстанцировать объекты.
Class.new.methods — Module.new.methods #=> [«superclass», «allocate», «new»]
А что насчет сложности проверки самой целостности? Есть подозрения, что это может быть весьма и весьма нетривиальной задачей в более сложных случаях.
Вообще любопытно, хоть chaos-mockup делай :)