… а можно не использовать сдвиг и не иметь таких проблем. Альтернативных решений много, нужно выбрать только не съедающие быстродействие вашего сервиса.
Но у нас же ещё есть гравитация, гироскопический эффект и ещё много чего. Так же сами написали, что мы не можем получить локального минимума, не добавив заряд в точку. Но заряд-то добавить мы можем, при этом сместив точку равновесия гравитацией, освободив тем самым току равновесия от материального объекта.
К тому же в сети есть видео стабильной левитации магнита с использоватием магнитных свойств висмута:
https://www.youtube.com/watch?v=A5pZZJ23rDM
В многих лицензиях МС к бесплатным продуктам есть пункт о том, что запускать эти продукты вы можете только на системе с лицензионной Windows. В либах msvb такого условия нет?
Ну, как уже выяснилось в соседней метке — IB видит в том числе и свойства, объявленные в категориях.
По поводу UIButton: я работаю с платформой начиная с iPhone OS 3.1.3, и не разу не замечал у UIButton признаков кластера, в отличии от того же NSArray. Возможно — я был недостаточно внимателен. Возможно — вы что-то путаете.
По поводу наследования: не вижу ни одного повода от него отказываться — это основная концепция ООП.
К тому же нужно всего лишь следить за отсутствием конфликтов имён и не использовать приватные методы. Для того, чтобы при таком подходе что-то сломалось — Эппл должен переписать половину SDK, по пути сломав половину приложений из AppStore. Этого не случится никогда.
Отличить кластер можно по возвращаему типу, не совпадающему с оригинальным. Для [NSArray array], например, это __NSArray0.
Конструкторы UIButton возвращает всегда UIButton. Так что даже если там внутри происходит какая-то «магия» — на наследование она не влияет.
> Но сабклассить его всё равно не стоит
В эппловской документации для таких классов содержится отдельное предупреждение (как, например, у UIWebView: «Subclassing Notes: The UIWebView class should not be subclassed.»)
В случае же кнопки — некоторые вещи просто невозможно реализовать без наследования (модификация intrinsicContentSize, например)
Вашу идею, кстати, я тоже реализовывал, до того как нашёл способ добавить свойство в Interface Builder.
Там есть некоторые трудности с тем, что для некоторых контролов текст может быть выставлен для любых состояний (всех сочетаний получается 16 штук), причём непонятно, какие из них действительно выставлены.
С другой стороны, если у вас для разных состояний тексты действительно отличаются — возможно лучше использовать именно этот путь.
Вообще, я так запихиваю через Interface Builder многие вещи: шрифт из пресета, цвет placeholder'а у UITextField (который по умолчанию серый и не меняется в визуальном дизайнере), угол скругления, кастомный стиль кнопки и т.д. Практически всё, что обычно вручную делается в awakeFromNib можно реализовать таким образом.
Точно не скажу с какой версии, но сейчас в языке есть дерективы nullable и nonnull для аргументов и возвращаемых значений функций. На Swift я ещё не писал, но по описанию — похоже.
Вообще, сейчас в язык добавили много операторов-подсказок для компилятора, вроде NS_REQUIRES_NIL_TERMINATION.
Это плохо для понимания кода программистами. После такой тулзы наверняка будут проблемы с «узнаванием» своего собственного кода, особенно в старых модулях.
А, кстати, чем закончилась история с этим доказательством? Судя по отсутствию сенсаций с участием NP-полноты за последние года — в доказательстве ошибка?
К тому же в сети есть видео стабильной левитации магнита с использоватием магнитных свойств висмута:
https://www.youtube.com/watch?v=A5pZZJ23rDM
По поводу UIButton: я работаю с платформой начиная с iPhone OS 3.1.3, и не разу не замечал у UIButton признаков кластера, в отличии от того же NSArray. Возможно — я был недостаточно внимателен. Возможно — вы что-то путаете.
По поводу наследования: не вижу ни одного повода от него отказываться — это основная концепция ООП.
К тому же нужно всего лишь следить за отсутствием конфликтов имён и не использовать приватные методы. Для того, чтобы при таком подходе что-то сломалось — Эппл должен переписать половину SDK, по пути сломав половину приложений из AppStore. Этого не случится никогда.
Конструкторы UIButton возвращает всегда UIButton. Так что даже если там внутри происходит какая-то «магия» — на наследование она не влияет.
> Но сабклассить его всё равно не стоит
В эппловской документации для таких классов содержится отдельное предупреждение (как, например, у UIWebView: «Subclassing Notes: The UIWebView class should not be subclassed.»)
В случае же кнопки — некоторые вещи просто невозможно реализовать без наследования (модификация intrinsicContentSize, например)
Там есть некоторые трудности с тем, что для некоторых контролов текст может быть выставлен для любых состояний (всех сочетаний получается 16 штук), причём непонятно, какие из них действительно выставлены.
С другой стороны, если у вас для разных состояний тексты действительно отличаются — возможно лучше использовать именно этот путь.
При локализация ксибов я использую такой подход:
Для интерфейстых элементов создаю собственные сабклассы со свойством
В сеттере которого присваиваю текст, полученный из NSLocalizedString по присвоенному по свойству ключу.
Это свойство видно в Interface Builder, в него и нужно прописать ключ локализации.
Вообще, сейчас в язык добавили много операторов-подсказок для компилятора, вроде NS_REQUIRES_NIL_TERMINATION.