Зависит от требований. Пользователь платит один раз или за промежуток времени?

Покупает один раз. Я пока сделал int и проверяю 0 не оплачено 1 оплачено. Может есть решение получше

Покупает один раз. Я пока сделал int и проверяю 0 не оплачено 1 оплачено. Может есть решение получше

Можно записывать оплаты, и просто проверять есть ли у пользователя оплата

если для 1 - 0, то int на enum можно заменить

Покупает один раз. Я пока сделал int и проверяю 0 не оплачено 1 оплачено. Может есть решение получше

я бы сделал дата оплаты payed_at nullable

Покупает один раз. Я пока сделал int и проверяю 0 не оплачено 1 оплачено. Может есть решение получше

А boolean чем не подошел?

А boolean чем не подошел?

Может это как раз то что нужно. Спасибо

Может кто в курсе, существует ли Ali по Whatsapp?

Api

Просто находил миллион сервисов предлагающих платную интеграцию, соответственно должна быть апи для месенджера

Может кто в курсе, существует ли Ali по Whatsapp?

http://lmgtfy.com/?q=whatsapp+api первая ссылка в гугле

еще есть пятая ссылка в гугле, в которой все хорошо рассказали

в чем проблема сначала поискать, а потом спрашивать?

Сори, недоразумение вышло

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

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

Покупает один раз. Я пока сделал int и проверяю 0 не оплачено 1 оплачено. Может есть решение получше

я бы стрим ивентов хранил)

я бы стрим ивентов хранил)

Можно поподробнее? Я с деревни)

это значит что есть таблица хранящая все оплаты всех пользователей

типо транзакции

ну транзакции хорошо но у него же бесплатно

это значит что есть таблица хранящая все оплаты всех пользователей

Такая формулировка более понятна. Стрим в наше время имеет множество значений) Я уж испугался, подумал какой-то rocket science подъехал незаметно для решения такого кейса

с точки зрения бд надо хранить каждую оплату с датой суммой

а у обонента при оплате записывается id транзакции

а по нему уже данные о сумме, способе начисления (например если возврат по требует)

и прочей фигне, но это все от деталей зависит

В 2017 году на конфе по Yii был прикольный доклад, где рассказывали про биллинг на основе двойной записи: https://yiiconf.ru/data/yiiconf2017/ppt/272.pdf

я бы стрим ивентов хранил)

ты мне на днях говорил, что нельзя давать людям оружие)

ты мне на днях говорил, что нельзя давать людям оружие)

может быть мне скучно)

юи, биллинг, прикольный... блин, если скучно можно доклад посмотреть)

юи, биллинг, прикольный... блин, если скучно можно доклад посмотреть)

Ну там про юи чуть меньше чем ничего упоминается)

юи, биллинг, прикольный... блин, если скучно можно доклад посмотреть)

ну там обычный double entry ledger

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

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

Ну мы же помогаем друг другу в этом чате) Для кого-то и boolean неочевиден.

В общем, написал компрессор кода php, он кривой , но работает, если кому надо могу в гит выложить

компрессор кода на пхп... хоспаде

В общем, написал компрессор кода php, он кривой , но работает, если кому надо могу в гит выложить

главный вопрос - зачем?

типа аглификация/обфускация или пробелы удаляешь?)

типа аглификация/обфускация или пробелы удаляешь?)

Нет, переименоваю переменные и методы , зачем спорный вопрос, но для функционала в одном файле супер

супер тупо и бесполезно)

зочем)

ну для обфускации реально прикольно

а в виде компрессора оно не надо

Делал для себя и для уменьшения размера файла

гнаться за уменьшением файла в 2018)

гнаться за уменьшением файла в 2018)

Для заливки веб Шелла есть смысл гнаться

Для заливки веб Шелла есть смысл гнаться

фу таким быть

но вообще нет смысла гнаться)

мб он заливает веб шеллы по фтп в далёком прошлом. Диалап с перманентными обрывами, все дела

в любом случае, от большого ума такие вещи не делают)

Как правильно заставить имплементить методы в классе, которые необходимы для подключаемого трейта? 1 Делать абстрактные методы в трейте? 2 Делать методы в самом трейте которые вернут дефолтные значения. А в классе переопределять. Например , есть класс Class A, к нему подключается трейт Trait T. В трейте мне нужно получить что-то из класса А - $this->getPrice() В классе А я реализовываю метод getPrice() Есть другие варианты? И какой предпочтительней?

В общем, написал компрессор кода php, он кривой , но работает, если кому надо могу в гит выложить

Ну если он склеивает проект в один файл то очень даже интересная штука, чисто выпускаешь какую то утилиту и пакуешь её в такой файлик который можно и распространять, чувак скачал один файл - и может сразу запускать и выполнять что ему там надо

Ну если он склеивает проект в один файл то очень даже интересная штука, чисто выпускаешь какую то утилиту и пакуешь её в такой файлик который можно и распространять, чувак скачал один файл - и может сразу запускать и выполнять что ему там надо

прямо как .phar

Ну принципе да)

Как правильно заставить имплементить методы в классе, которые необходимы для подключаемого трейта? 1 Делать абстрактные методы в трейте? 2 Делать методы в самом трейте которые вернут дефолтные значения. А в классе переопределять. Например , есть класс Class A, к нему подключается трейт Trait T. В трейте мне нужно получить что-то из класса А - $this->getPrice() В классе А я реализовываю метод getPrice() Есть другие варианты? И какой предпочтительней?

подумай, можешь ли ты иметь дефолтную имплементацию или нет. А вообще задумайся "нахера вообще тебе трейты"

Как правильно заставить имплементить методы в классе, которые необходимы для подключаемого трейта? 1 Делать абстрактные методы в трейте? 2 Делать методы в самом трейте которые вернут дефолтные значения. А в классе переопределять. Например , есть класс Class A, к нему подключается трейт Trait T. В трейте мне нужно получить что-то из класса А - $this->getPrice() В классе А я реализовываю метод getPrice() Есть другие варианты? И какой предпочтительней?

трейт, который описается на стейт клиентского класса - такое себе решение

или который рассчитывает, что клиентский класс что-то там имплементит

трейт, который описается на стейт клиентского класса - такое себе решение

ну оно через методы это делает, а потому в целом норм

или который рассчитывает, что клиентский класс что-то там имплементит

это абсолютно нормально

но сам факт наличия трейта уже вопросы порождает

Вижу как решение - вынести функционал в сервис класс и инжектить его в конструкторе. Верно?

это абсолютно нормально

именно поэтому у человека возник вопрос "как заставить имплементить методы"?)

Вижу как решение - вынести функционал в сервис класс и инжектить его в конструкторе. Верно?

Тип того

именно поэтому у человека возник вопрос "как заставить имплементить методы"?)

Ну у меня были такие потребности и в целом есть кейсы когда это оправдано. Особенно при рефакторинге

именно поэтому у человека возник вопрос "как заставить имплементить методы"?)

Смысл в том, что бы IDE при подключении трейта явно говорило что нужны вот эти методы заимплементить. Сейчас все реализовано на дефолтных методах в трейте. Ищу варианты как отрефаткорить

Смысл в том, что бы IDE при подключении трейта явно говорило что нужны вот эти методы заимплементить. Сейчас все реализовано на дефолтных методах в трейте. Ищу варианты как отрефаткорить

можешь делать, чтоб трейт вызывался внутри метода не как $this->methodFromTrait(); а как-то так $this->methodFromTrait($this); а methodFromTrait описывай как принимающий как-то интерфейс

путанно немного, да?)

ERROR: S client not available

А если под трейт сделать интерфейс и имплементировать его вместе с трейтом?

А если под трейт сделать интерфейс и имплементировать его вместе с трейтом?

Шурик выше описал более надежный вариант

но при этом менее красивый

путанно немного, да?)

Я понял что ты имеешь ввиду. Но передавать сам клас в себя это точно норм? )

т.к. интерфейс для трейта можно забыть заимплементить

Я понял что ты имеешь ввиду. Но передавать сам клас в себя это точно норм? )

в питоне вон вообще self всегда идет первым аргументом методов класса)

т.к. интерфейс для трейта можно забыть заимплементить

Если только в этом проблема, то чёт не тянет на аргумент, мне кажется)

Если внутри компании все придерживаются такого трейт + интерфейс, то это не забудется. Плюс наверное ещё можно внутри трейта проверять имплементирует ли класс интерфейс

Хотя я не знаю, есть ли доступ к контексту внутри трейта, не использую их

Если внутри компании все придерживаются такого трейт + интерфейс, то это не забудется. Плюс наверное ещё можно внутри трейта проверять имплементирует ли класс интерфейс

а снаружи проверять использует ли класс трейт)))

ехал трейт через трейт

больше проверок богу проверок

а снаружи проверять использует ли класс трейт)))

Комбо))

Хотя я не знаю, есть ли доступ к контексту внутри трейта, не использую их

есть

и часто из-за этого очень грустно)

видал в трейтах и что-то такое: trait Foo { pubilc function bar() { return parent::fooBar(); } }

ад, одним словом

Спасибо камрады. Дали пищу подумать. ?

или даже так

trait Foo { pubilc function bar() { $this->someMethod(); return parent::fooBar(); } }

вместо трейтов завёл файлик functions.php и жизнь прекрасна)

и думаешь такой - а что, блять, должно быть $this-ом, чтоб оно работало?)

В 2017 году на конфе по Yii был прикольный доклад, где рассказывали про биллинг на основе двойной записи: https://yiiconf.ru/data/yiiconf2017/ppt/272.pdf

https://www.youtube.com/watch?v=CXjaa7hsUmU

скажите ка, а может ли фабричный метод генерить VO? И если да, то может ли он устанавливать для него параметры?

А почему бы он не смог?

хз

на всякий случай спросил

А почему бы он не смог?

засранец)

Кто вчера меня в РО добавил?

?

вычисли его по айпи

ты ж developer