возможно, ну епта

это лишь пример динамического инстанцирования чего либо

ты путаешь "динамическое инстанцирование" и "динамическую типизацию" походу)

ну ок :) я ретируюсь :)

да, это пересекается, ибо ты не знаешь тип переменной в которую ты инстанцируешь что-то

буря в стакане)

но тайп хинтинг тебе тут не поможет никак вообще

и потому тебе надо проверить "а то ли мы получили"

assert($foo instanceof Type);

а ассерты можно будет в продакшене отключить, но ты получишь информацию о типах и все проверки которые надо

именно в пхп тайпхинтинг предотвратит вызов чего-то с аргументом неправильного типа. что позволит избежать какого-то сайдэффекта который мог бы быть без него. но если есть тайпхинты которые уже выполняют проверку - нахрена избавляться от них и навешивать что-то сверху?

именно в пхп тайпхинтинг предотвратит вызов чего-то с аргументом неправильного типа. что позволит избежать какого-то сайдэффекта который мог бы быть без него. но если есть тайпхинты которые уже выполняют проверку - нахрена избавляться от них и навешивать что-то сверху?

как в приведенном тобой примере поможет тайпхинтинг? продемонстрируй

либо ты напишешь if (!$foo instanceof Type) throw new Exception(...) либо ты навесишь глобальный обработчик ошибок, который будет все превращать в исключения и будешь просто писать bar($foo) и отлавливать исключение без обвешиваня вызова каждого метода с тайпхинтом дополнительной проверкой типа

ну опять же

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

ты же можешь отключить ассерты например)

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

вы практикуете такое на проде?

в смысле?

ну, лично я считаю это очень рискованным, т.к. нельзя протестировать 146% кода со всеми возможными и невозможными параметрами.

у меня на проде врядли будет такая ошибка

лучше исключение чем сайдэффект

исключение и есть сайд эффект

а вы серьезно try-catch делаете по ошибкам тайпхинта?)

нет, исключение - это исключение. а сайдэффект - это сайдэффект. в исключении у тебя код свалится в место обработки исключений, а в ином случае у тебя к 1 прибавится 1.2, когда требуется int, но он внезапно отключен

исключение - это не сайд эффект

отключена проверка типов, я имею ввиду

исключение - это не сайд эффект

он самый

http://stackoverflow.com/questions/10703232/why-is-the-raising-of-an-exception-a-side-effect

мне лень писать потому ссылочка

ок

простите, я в этот чат писал что WP это норма?

нет, исключение - это исключение. а сайдэффект - это сайдэффект. в исключении у тебя код свалится в место обработки исключений, а в ином случае у тебя к 1 прибавится 1.2, когда требуется int, но он внезапно отключен

если у тебя пришел double вместо int значит сверху кто-то проиграл. Ты уже потерял контроль над ситуацией, чего париться то?

почитал. всегда думал, что сайд эффект (из фп) - это когда изменяешь состояние - пишешь в бд, на экран и т.д.

то что всё должно быть покрыто (и покрыто уже) тестами - это понятно. но к примеру есть какойнить метод вида getRandomInt(int $from, int $to), который должен возвращать int. вы его протестили, всё отлично, но... в рантайме туда может прилететь какойнить float или boolean :)

не думаю что все возможные кейсы покрыты тестами :)

если у тебя пришел double вместо int значит сверху кто-то проиграл. Ты уже потерял контроль над ситуацией, чего париться то?

тогда должно быть исключение

почитал. всегда думал, что сайд эффект (из фп) - это когда изменяешь состояние - пишешь в бд, на экран и т.д.

сайд эффект это ЛЮБОЕ влияние внешнего мира (а вызываемый код - это внешний мир по отношению к коду, который вызывает функцию) на ход работы кода

тогда должно быть исключение

оно просто скажет тебе что все плохо. Ты и так и так узнал бы что все плохо

причем когда у тебя отработает тайп хинт - не факт что оно проигралось радяшком

скорее всего контроль за типами был потерян где-то далеко в цепочке вызовов

оно просто скажет тебе что все плохо. Ты и так и так узнал бы что все плохо

если отключить проверку типов - хер он че тебе скажет. пхп скастует в подходящий тип входящий параметр и скажет что всё ок :)

если отключить проверку типов - хер он че тебе скажет. пхп скастует в подходящий тип входящий параметр и скажет что всё ок :)

ну ты получишь флоат на выходе, ну ок

и?

потеря данных произошла - нет

и в итоге у нас остается три варианта: 1) не трогать тайпхинт и пусть пшп сам проверяет параметры 2) оборачивать все в instancof/is_integer/is_object/is_something 3) забить хер на всё и надеяться на авось первый вариант отличный, второй добавит кучу лишнего кода, третий вообще говно

блин

ну ты получишь флоат на выходе, ну ок

а у тебя метод говорит что он вернет int :)

ты не понял видимо мотивацию "отключения"

тайп хинтинг всего и вся существенно влияет на рантайм

и его производительность

я понял мотивацию

причем если у тебя все покрыто информацией о типах

то тебе в целом не нужен этот самый тайп хинтинг в рантайме

но пшп - это пшп! там в рантайме может случиться любое говно

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

о

идея

для кода который под strict_types

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

и тогда все вроде счастливы, нет?

в переменной инт а ты пытаешься к нему строку приложений - касты запрещены - все проигрывает

неа, т.к. оно все равно в рантайме проверяет соответствие типов

а вот код который с weak type

там оставить как есть

неа, т.к. оно все равно в рантайме проверяет соответствие типов

это делают реализации отдельных опкодов

ладно, пойду спать, а то уже внезапно глубокая ночь... а вот был бы тайпхинт на это - было бы исключение)))

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

ERROR: S client not available

Кто что использует в качестве поискового движка? На проекте использовали solr старой версии, и в связи с рефакторингом встал вопрос переехать на Еластику. Будет ли профит? Из ключевых моментов: текстовый поиск и маштабирование.

эластик юзается, полет нормальный. индексируем монгу

после сфинкса эластика кажется медленной (индексация)

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

т.е. можно даже не знать что такое дельта индексы

поиск шустрый, а это главное

ну и индексация ж не нужна полная постоянно

Индексация не полная, а при импорте данных. Из-за чего распределение нагрузки не равномерное.

Читал что сорл плох в во время конкурентного обновления индексов.

http://blog.socialcast.com/realtime-search-solr-vs-elasticsearch/

solr ведь поверх lucene, как и эластик

И статейка то 5-ти летней давности...

а вот код который с weak type

не все обсуждение выше читал, но интересен личный опыт. вы не испоользуете тайп хинтинг и все чекаете через assert и отключаете это в проде?

не, все пользуются тайпхинтами)

ок, а то выглядит как 80lvl оптимизации)

не все обсуждение выше читал, но интересен личный опыт. вы не испоользуете тайп хинтинг и все чекаете через assert и отключаете это в проде?

погоди погоди, я не предлагал перестать использовать тайп хинтинг

я предлагал дать возможность выключать его влияние на рантайм

опциональную

с кучей красных предупржденией "сначала 10 раз подумай сынок"

что бы можно было написать

class Foo { public string $email; public string $password; public string $name; public \DateTime $birthDay; public ?string $aboutMe; }

и статический анализатор бы проверил что мэппинги эти правила осблюдают

и те оверхэды которые налагает реализация тайпхинтинга для пропертей невилировались на продакшене

статический анализатор - это что-то вроде phan'а?

да

ок! спасибо за подробное объяснение ?

$items = $this->repository->findAll(); foreach ($items as $item) { $item->setFoo('foo'); } $items = $this->repository->findAll(); foreach ($items as $item) { $item->setBar('bar'); } $this->objectManager->flush();

А подскажите, в доктрине отработают оба цикла? Или второй перезапишет значения первого?

странный вопрос) они оба отработают

после того как они попали в доктрину, они становятся managed by UoW

в плане, второй findAll() вернет объекты, у которых значение foo будет изменено первым циклом?

и даже если заново запросишь с базы, все равно будет юзаться версия из UoW

ага, спасибо