Кстати говоря, PDO (а у меня он) вообще не работает с типами, кроме как string, int и bool. Всё, что не указано, как PDO::PARAM_INT или PDO:: PARAM_BOOL, будет обработано, как PDO:: PARAM_STR.

Так что получается это все напрасно. Или есть другая причина.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Опять вопрос возник. Касательно преславутого PSR.

Обычно принято в таблицах СУБД поля называть в змеиной нотации (user_id, published_date, view_count и т.д) А когда я только начинал лепить этот фреймворк, меня убедили, что переменные и свойства лучше писать в верблюжьей нотации ($userId, $publishedDate и пр). Оно и верно, проще ассоциировать с методами.

Однако теперь получается, что в AR моделях произойдет разброд. Половина свойств в одной нотации, половина в другой. А это противоречит PSR-1, который рекомендует единый стиль. И хотя эта рекомендация обозначена, как SHOULD (крайне желательно, но необязательно), все равно будет не ахти.

Мне интересно вот что. Не знаю, как в Yii, но в Laravel есть возможность конвертации имен в обе стороны. Но почему то они этого не делают. Почему? И стоит ли сделать это мне?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Я как то давно думал что бы имена таблиц и полей называть в верблюжьей нотации, по аналогии с методами и свойствами. Если уж единый стиль, то во всём.
$row['userName'] ничем не хуже $row['user_name']

Единственное что меня не устраивает, прям минус 80 лвла, это когда нужно как то искать по шаблону.
Везде используются те или иные разделители, в таблице подчёркивание, в файлых точки и подчёркивания, в ключах точки и двоеточия и точки с запятой и запятые, а тут нет разделителя, и очистить все таблицы начинающиеся на cache не получится, потому что допустим есть cacheNews (кэш новостей) а есть cachevar (люди, которые варят кашу).
В итоге кажется что верблюжья нотация это ущербный стиль.

Но если думать о DB как о многомерном массиве данных, тогда всё встаёт на свои места.
Таблица это ключ и поле это ключ $bd['user'][0]['name'].
Ключи есть смысл искать по шаблону, а имена искать особо нет смысла.

Ключ это просто метка данных, которая может состоять из нескольких значений.
Значения можно объеденять через запятую, если используется перечисление

$news['2017,2018']

Можно через двоеточие если используется несколько разных типов значений

$news['16:00']

Можно через точку с запятой объединять

$news['2017,2018;16:00']

А можно использовать составные имена

$config['site.title']
$config['site.description']

Было бы логично таблицы и имена полей называть через точку. Таблица cache.news, поле date.create.
Но синтаксис SQL использует точки в запросах

SELECT u.`id` FROM `user` as u WHERE u.`name` = 'Вася'

Наверное получится не очень читабельно.

SELECT c.`date.create` FROM `cache.news` as c WHERE c.`date.update` < :date

Хотя норм.

В общем я к чему. Если сделать всё по науке в одном стиле, тогда имена полей будут через точку.
Это значит что имена свойств тоже должны быть через точку? Нет. Имена свойств это имена, а не составные значения как ключи. Так что преобразуй поля user_name или user.name (хз как будет модно завтра) в $this->userName.
При этом в массиве это будет по прежнему $row['user.name'].

ИМХО





_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Все эти двоеточия, запятые и прочая лабуда в ключах массива - жуткий моветон. Как с таким массивом работать скажем функцией extract()? :) Допускается в редких, специфических случаях.

    public function getFirstNameAttribute($value)
    {

Я понял почему! Блин, все просто. Не все же юзают верблюжью нотацию в переменных. Они оставили так, чтобы было право выбора.

Я сделаю это настройкой. Однообразие стиля все же приятная штука.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

twin

Почему кстати snake_case так называется?
Я понимаю camelCase горбатый, можно быть много как его назвать, но и так тоже логично.
Понимаю kebak-case, слова как будто на шампур насажены.
А в snake_case змею в упор не вижу, может надо накуриться посильней?)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Не, все это фигня. Как только начинаю изменять своим привычкам, так и вылазит всякая хрень. В данном случае хрень - PSR-1 в части свойств. Ваще бесполезная, и даже вредная штука. Хорошо хоть обозначили, как SHOULD.

Причина тут немного глубже. А именно в самом паттерне. Свойства должны называться так же, как поля в таблице. Точка. И плевать на PSR и смешение стилей. Так даже полезнее, ибо видно, где аттрибуты, а где служебные свойства.

Так что не стану я конвертировать.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

twin

twin

$User = new User();
$user = $User->get(1);
echo $user['id']; // 1

$myFunc = function () {
    return myFunc();
};