@Alexufo и тоже нет. Суть в том что эти две пары преобразований делают urldecode и urlencode, каждая свою пару. Откуда у автора вопроса вообще появилась такая необходимость я могу только догадываться.
@lihtenshtein вы не должны обращаться к статическим свойствам. Вообще при работе с другими объектами вы должны завязываться только на его интерфейс и взаимодействовать только посредствам вызова методов. Это наиболее правильное решение. А проверять что переданный объект имплементит нужный интерфейс можно просто указав оный в тайпхинтинге.
Ух, что-то пальцы начали заплетаться. Словом...
валидация параметров для инициализации - задача пользователя вашего класса. Для облегчения этой задачи существуют готовые компоненты, которые исходя из описания сами будут проводить проверку. Если пользователь вашего класса решил не использовать подобный компонет, вся ответственность переходит на него.
Но это касается только инициализации, так как по хорошему пользователь должен использовать Depencency Injection Container. А вот в публичных методах API валидацию данных стоит делать что бы не допускать ошибок в работе компонента. В противном случае кидать InvalidArgumentException.
@lihtenshtein, я обновил свой ответ. Ответственность действительно лежит на программисте, но для понижения возможной ошибки можно применять отдельные компоненты, которые будут подготавливать все необходимые настройки необходимые для инициализации компонентов. В этом случае вам нужно описать только что вы хотите получить, а компонент все сам провалидирует. Причем это будет вне компонента и код будет оставаться чистым. Если же пользователь решил использовать ваш класс отдельно, это его задача валидировать параметры. Либо можно сделать отдельный объект конфигураций который будет валидировать параметры и передавать уже его.
@svistiboshka просвятите, что же такое фронтэнд. Если вы о том что JS занимает не 100% от фронтэнда а всего-то 80% то ок, но фронтэнд по большей части это JS, DOM и API предоставляемое браузерами. Верстка сама по себе слабо относится к фронтэнду.
@Alexufo основное преимущество - уменьшение дублирования кода (селекторов, стилей отдельных и т.д.). Вообще пока не попробуете на паре проектов, сложно будет понять.
@RadiationX просто меня раздражает длительность действия этой казалось бы простой операции на мобильниках. Да и просто поразбираться. Вообще с блендинг модами и режимами композиции можно много чего интересного делать и причем в реалтаймме.
@machno скорее всего какие-то багфиксы и секьюрити фичи. CI был норм лет так 6 назад (собственно это последний раз когда я его видел вблизи). Сейчас писать на нем смешно.
@machno если вам для обучения, то стоит брать что-то посложнее. В CI нету ничего что бы заставляло вас делать что-то правильно. В Yii ситуация чуть получше но все же лучше взять для начала Laravel и разобраться как вообще все должно быть. Laravel/Symfony намного более жестки по требованиям к разработки и усложняют возмжности сделать что-то неправильно. Хотя в документации к обоим фреймворкам лучшие практики сложно найти.
