или в php 7.0

не помню в каком точно

кстати специально для таких случаев в php7.1 появилось в трейте возможность имплементить интерфейс

можно пруф?

https://wiki.php.net/rfc/traits-with-interfaces

так трейты не для этого, чем тебе интерфейс не угадил?)

хм.

кстати специально для таких случаев в php7.1 появилось в трейте возможность имплементить интерфейс

+ гуд

но если ты хочешь подобное то у тебя или что то очень извращенное

хзхз rust на этом построен

https://wiki.php.net/rfc/traits-with-interfaces

Женя, его не приняли)

но если в пхп интерфейсы норм работают и есть мулти-implements, то даже норм

хзхз rust на этом построен

то что в расте трейт зовется это не тоже самое что и в пхп

там нормальная система типов

и там тоже есть отличия в том что там зовется и чем обычно являтеся

то что в расте трейт зовется это не тоже самое что и в пхп

ну вот да

PHP traits == JS mixins

и там тоже есть отличия в том что там зовется и чем обычно являтеся

но там трейты ближе к концепции трейтов ))

да мне там они больше нравятся

и язык rust в целом мне очень нравится

но реальность такова что мне платят за работу в пхп

вот например взять java (SE) и php (5 или 7) и попоробывать сравнить объективно, по всем параметрам выигрывает java

и язык rust в целом мне очень нравится

мне тоже

но нахуярить портотип на php намного быстрей

но реальность такова что мне платят за работу в пхп

а мне за работу в мире жс))

мне тоже

я был бы очень рад если бы раст стал популярней

но реальность такова что гугл двигает go

если сюда добавить ruby (on rails), то все остальные по скорости прототипирования сосут

хз мне руби не нравится чисто субьетивно и по синтаксису

я уж лучше боль и страдания в виде многословности java приму

но это имхо, каждому нравится что то свое

ну субъективное, спорить не буду Но рельсы это самое мощное что есть

но реальность такова что гугл двигает go

на самом деле он круче

сам писал Руби знаю плохо, рельсы тоже Но прототип проекта сделал за месяц И зараза он работал

ну субъективное, спорить не буду Но рельсы это самое мощное что есть

самое лучшее что было в 2013 году

где то так

и сейчас)

действительно мощных альтернатив нет

на всё нужно много человекочасов, чтобы ускорить дальнейшую разработку

а мне за работу в мире жс))

именно js пишешь, или таки какой-нибудь truescript?

именно js пишешь, или таки какой-нибудь truescript?

много разного пишу Прямо сейчас на typescript Есть соседний проект, в который коммичу, он на flow Все личные пишу на чистом жс (es6-7)

ой, да, typescript имел ввиду. Ну es6-7 тоже ок, да.

много разного пишу Прямо сейчас на typescript Есть соседний проект, в который коммичу, он на flow Все личные пишу на чистом жс (es6-7)

Так пишешь, как будто flow - это не чистый js)

Так пишешь, как будто flow - это не чистый js)

неа Тоже куча абстракций сверху) хоть и сильно меньше чем в ts

Так пишешь, как будто flow - это не чистый js)

Это смотря как посмотреть.

Это смотря как посмотреть.

Как угодно.

Flow не добавляет в язык новых рантайм конструкций. По сути, код без Flow и код с Flow — это одно и то же с точки зрения рантайма. В то же время, Flow добавляет абстрактные языковые конструкции, что позволяет нам утверждать, что это другой язык.

у меня был кейс, где трейты были оправданы, т.к. этот ваш по ха пе не поддерживает множетсвенное наследование. Но последнее еще большее зло. Поэтому и были созданы трейты

интересно на кой черт тебе множественное наследование понадобилось)

неа Тоже куча абстракций сверху) хоть и сильно меньше чем в ts

каких абстракций, извини? где ты их нашел?

каких абстракций, извини? где ты их нашел?

которые нужны для нормальной типизации

Flow не добавляет в язык новых рантайм конструкций. По сути, код без Flow и код с Flow — это одно и то же с точки зрения рантайма. В то же время, Flow добавляет абстрактные языковые конструкции, что позволяет нам утверждать, что это другой язык.

все рантайм штуки добаляет в твоем случае babel.

Flow тут выигрывает только за счет того что кое где больше чего умеет. Ну и в целом дальше начинается чистая вкусовщина и религия

которые нужны для нормальной типизации

еще раз. Что ты подразумеваешь под словом "абстракция" и че они там сверху делают

для нормальной типизации нужна нормальная информация о типах в компайл тайм

никаких "абстракций"

ну субъективное, спорить не буду Но рельсы это самое мощное что есть

в определенном классе задач - да

никаких "абстракций"

+1

ребята, подскажите, использование в юнит тестах shouldBeCalled/shouldNotBeCalled, это где-то хорошо, а где-то плохо

плохо, когда мы проверяем, как работают детали реализации?

а хорошо, когда мы проверяем, правильно ли объект работает с другим?

стоит ли тут разделять понятия "зависимостей" и каких-нибудь "субъектов" действия?

как пример, кэширующий декоратор, зависимость - драйвер кэша, субъект - декорируемый объект

как эти понятия правильно называются?

вопрос тонкий, где кончается реализация и начинается взаимодействие с другими объектами это хороший вопрос

не в тему тестов: http://wiki.c2.com/?EncapsulationIsHierarchical

а как композиция может заменить наследование? есть маленький просто пример?

и агрегация этож похоже на dependency inject

так и есть

а вообще, это две разные вещи

иногда разумно юзать наследование, иногда композицию

а разница банальна вообще

вместо class Test { } class Some extends Test { } юзаешь class Test { } class Some { // тут через DI добавляешь Test }

ну или как то так

а как композиция может заменить наследование? есть маленький просто пример?

лучше покажи пример, где ты не знаешь, как заменить наследование

Существует два подвида этого отношения: если один объект создает другой объект и время жизни "части" зависит от времени жизни целого, то это называется "композиция", если же один объект получает ссылку (указатель) на другой объект в процессе конструирования, то это уже агрегация.

вместо class Test { } class Some extends Test { } юзаешь class Test { } class Some { // тут через DI добавляешь Test }

и как тут могут быть доступны родительские методы?в случае расширения(extends) нам доступны родительские методы в классе дочернем, а в случае композиции нэт

Вызываешь методы через объект класса.

и как тут могут быть доступны родительские методы?в случае расширения(extends) нам доступны родительские методы в классе дочернем, а в случае композиции нэт

с чего бы они не доступны, если мы имеем инстанс

class Some { constructor(test: Test) { this.test = test } doSmth() { this.test.doSmth() } }

через DI

https://repl.it/JUrG/8

не совсем пока понимаю в чем суть

я не понимаю пока вопроса

не то что бы вопрос был непонятен, просто он не имеет смысла

ты либо понимаешь, где юзать композицию, а где наследование, либо тебе это пока не нужно

ты либо понимаешь, где юзать композицию, а где наследование, либо тебе это пока не нужно

так не говорят что нужно предпочитать композицию наследованию https://repl.it/JUrG/11

как в первом где композиция вызвать родительский метод?

дочернему объекту вызвать родительский метод

так не говорят что нужно предпочитать композицию наследованию https://repl.it/JUrG/11

только сверху класс Some “расширяет” SomeOne, а снизу SomOne расширяет Som

только сверху класс Some “расширяет” SomeOne, а снизу SomOne расширяет Som

это чтобы конфликтов не бьыло в проге

как в первом где композиция вызвать родительский метод?

делегатом, например

это чтобы конфликтов не бьыло в проге

стрелки в разные стороны там, в одном случае от some к someone, в другом от somone к som

стрелки в разные стороны там, в одном случае от some к someone, в другом от somone к som

понял. не понял как мне объектом SomeOne вызвать parent_method? говорят не используйте наследование, используйте композицию, значит по логике функциональность должна отсаваться таже

у тебя есть два объекта, ты не знаешь как один может вызывать методы другого объекта?

SomeOne.some.parent_method();

А, у тебя классы наоборот

у тебя есть два объекта, ты не знаешь как один может вызывать методы другого объекта?

как я могу вызвать объектом метод чужого класса?

опять ты неправильно вопрос задаешь

забудь про классы, думай про объекты