Цены завышены, это рынок. Вот пример создания камеры для home kit на основе Raspberry pi. Не знаю, поставляются ли в Россию продукты, но в мире много других стран.
У apple нет косяков? Есть, конечно. Может быть не встречается брак? Встречается. Или может компания не замечена в намеренном устаревании своих устройств? Так что же тогда за гарантия?
Покупая в сторе любой продукт можно быть уверенным что блютуз в телефоне будет работать как положено, приложение для умного дома и через год, и через два будет обновлено.
Приведу пример: год назад я купил кондиционер от lg с wifi. Для него есть приложение thinq через которое им можно удаленно управлять. Приложение открывается около 20 секунд на iphone 8+. После следует загрузка продуктов (еще 5 секунд). Потом подключение к кондиционеру от 5 до 10 секунд. Все это при подключении и домашнему wifi, т.е. скорость интернета не влияет. Для кондиционера можно выставлять время включения. Догадались уже? Оно не работает. Все в приложении работает через загрузку после каждого действия. Сказать что кондиционер или приложение не работают я не могу. Другое дело как они работают. К сожалению, у apple нет аксессуаров-кондиционеров и сравнить не с чем, зато есть другие аксессуары.
С виду очень ничего даже, хотя все равно есть подозрения. По моему, лучше покупать что-то типа Control Lutron Serena Shades and lights. Потому что есть уверенность что apple гарантирует хотя бы среднее качество продаваемых товаров.
На надо во времена 5.6-7.0, уверен что на 7.5 вообще все перейдут на di и в каждом проекте будет вот это вот объявление параметра, занесение в конструктор, назначение в конструкторе, генерация docblock. В наследнике хочешь написать что-то в construct? Будь добр, тащи все зависимости в предок.
Запрещать подход я не предлагаю. Я за расширение: в простых случаях по-старинке, а с десятком зависимостей по-другому.
Мне кажется что если бы разработчики применили полноценное ddd то m2 если бы и вышла, то к концу десятилетия. Это если не смотреть сколько лет ушло на фиксы багов с 2.0…
А еще при работе с системой проходят проверку на прочность все компоненты: php, mysql, phpstorm, composer. Я вот не уверен что разработчики composer планировали что обычный проект будет грузить сотни мегабайт кода. Или в jetbrains разрабатывали phpstorm только для тех у кого ssd… Куда еще увеличивать кодовую базу.
Мне в js наоборот странно когда возле переменной ничего нет, а набирание постоянных let вообще напрягает.
И вообще, если $ все не замечают и никого не напрягает — значит знак выбран удачно. Конечно, кому-то может и не зайти. Я все жду когда для php появятся свой babel и тогда заживем. И вы сможете не писать $)
Как и все в мадженте, они как бы есть, но использовать можно только где-то в 20% случаях.
Добавить метод через плагин? Нельзя.
Сделать замену метода где используются приватные методы? Можно, но бессмысленно (нельзя).
Плагины не отменяют проблему с наследниками. Точно так же нужно работать с каждым по-отдельности.
Раз такое обсуждение пошло, то внесу и я свои пожелания.
Конструкторы и di
После работы с magento 2 стало очевидно что нужно что-то делать с конструкторами когда внедряется di. Пример класса. Возможно, использование выражений на месте, как сказано в статье, спасет ситуацию.
Наследование классов
Знаю что проблема не php, а многих языков. Так и не пришел к хорошему решению проблемы с наследниками.
1 случай: имеется класс для выборки данных который нужно закэшировать. Можно сделать наследование и заменить все методы на кэширующие. Если класс под интерфейсом, то реализацию интерфейса. В обоих случаях придется дублировать все методы. Как это решить — не понятно.
2 случай: в magento 2 есть возможность переопределять классы (preference), но переопределить класс от которого кто-то наследуются напрямую (extends /Class) — нельзя. А класс еще может быть абстрактным. В итоге получаем кучу наследников которые нужно переопределять чтобы добавить общий метод. И простого решения нет. Трейт лишь облегчит ситуацию.
Вообще, на айфоне в некоторых случаях нажатие на экран сопровождается небольшой вибрацией. Так что сделать некоторую отдачу для тач-скринов вполне можно.
Покупая в сторе любой продукт можно быть уверенным что блютуз в телефоне будет работать как положено, приложение для умного дома и через год, и через два будет обновлено.
Приведу пример: год назад я купил кондиционер от lg с wifi. Для него есть приложение thinq через которое им можно удаленно управлять. Приложение открывается около 20 секунд на iphone 8+. После следует загрузка продуктов (еще 5 секунд). Потом подключение к кондиционеру от 5 до 10 секунд. Все это при подключении и домашнему wifi, т.е. скорость интернета не влияет. Для кондиционера можно выставлять время включения. Догадались уже? Оно не работает. Все в приложении работает через загрузку после каждого действия. Сказать что кондиционер или приложение не работают я не могу. Другое дело как они работают. К сожалению, у apple нет аксессуаров-кондиционеров и сравнить не с чем, зато есть другие аксессуары.
Комнатный измеритель температуры и влажности.
Все выше — мое мнение. Apple не является лучшей компанией на свете, они просто не продают вещи с плохим качеством.
Запрещать подход я не предлагаю. Я за расширение: в простых случаях по-старинке, а с десятком зависимостей по-другому.
А еще при работе с системой проходят проверку на прочность все компоненты: php, mysql, phpstorm, composer. Я вот не уверен что разработчики composer планировали что обычный проект будет грузить сотни мегабайт кода. Или в jetbrains разрабатывали phpstorm только для тех у кого ssd… Куда еще увеличивать кодовую базу.
И вообще, если $ все не замечают и никого не напрягает — значит знак выбран удачно. Конечно, кому-то может и не зайти. Я все жду когда для php появятся свой babel и тогда заживем. И вы сможете не писать $)
Добавить метод через плагин? Нельзя.
Сделать замену метода где используются приватные методы? Можно, но бессмысленно (нельзя).
Плагины не отменяют проблему с наследниками. Точно так же нужно работать с каждым по-отдельности.
После работы с magento 2 стало очевидно что нужно что-то делать с конструкторами когда внедряется di. Пример класса. Возможно, использование выражений на месте, как сказано в статье, спасет ситуацию.
Знаю что проблема не php, а многих языков. Так и не пришел к хорошему решению проблемы с наследниками.
1 случай: имеется класс для выборки данных который нужно закэшировать. Можно сделать наследование и заменить все методы на кэширующие. Если класс под интерфейсом, то реализацию интерфейса. В обоих случаях придется дублировать все методы. Как это решить — не понятно.
2 случай: в magento 2 есть возможность переопределять классы (preference), но переопределить класс от которого кто-то наследуются напрямую (extends /Class) — нельзя. А класс еще может быть абстрактным. В итоге получаем кучу наследников которые нужно переопределять чтобы добавить общий метод. И простого решения нет. Трейт лишь облегчит ситуацию.
Скорее всего потому, что недавно меняли домены.