Я пытаюсь создать дату Carbon из существующей даты Laravel, которая использует свойства динамического объекта:
private static function createEvent($booking, $service) {
dd(Carbon::createFromFormat('Y-m-d H:i:s', "$booking->service_{$service}_date_end $booking->service_1_time_end"));
}
Это продолжает возвращаться:
Unexpected data found. Unexpected data found. Unexpected data found. Data missing
Есть идеи, как я могу заставить это работать? Кажется, я не могу передать переменные напрямую в Carbon, поскольку он ожидает строку в качестве второго параметра. Двойные кавычки немного усложняют задачу.
dd ("$ booking-> service _ {$ service} _date_end $ booking-> service_1 _time_end") и опубликовать результат
@ArtisticPhoenix, который возвращает Parse error: syntax error, unexpected '_date_end' (T_STRING), expecting ',' or ')'
@DaveCarruthers Это также возвращает Parse error: syntax error, unexpected '_date_end' (T_STRING), expecting ',' or ')'
Сложно сделать в одной строке, ИМО. Не стоит проблем с читабельностью.






Давайте немного разберемся с этим, у вас есть 2 свойства, одно из которых является динамическим.
Итак, чтобы получить доступ к динамическому свойству, вы можете сделать это
$prop = "service_{$service}_date_end";
$booking->{$prop}
Тогда у нас есть просто стандартное свойство в виде пробела, так что затем собираем это вместе
dd(Carbon::createFromFormat('Y-m-d H:i:s', $booking->{$prop}.' '.$booking->service_1_time_end"));
Теперь вы можете объединить их в одну строку, но в основном вы представляете собой переменные с двойной интерполяцией. Так что легче читать и делать, если вы позаботитесь о первом, а не о другом.
Для меня удобочитаемость - это все, пусть будет проще, и все будет работать.
Тем не менее, я думаю, что этот подход в корне ошибочен, поскольку у вас нет реального способа узнать, существует ли это свойство на самом деле. Таким образом, вы оставляете себя уязвимым для таких ошибок, как неопределенное свойство объекта.
Вы можете сделать это более надежно, используя простой оператор switch.
Но, не зная всего, как вы его используете или откуда взялся $service, я не могу этого сказать, это может быть хорошо в вашем случае использования. Я просто хотел вас предупредить.
Да, я собирался спросить, можно ли все это включить в одну строку ... но, наверное, лучше не делать этого. Это отлично работает, спасибо.
Да, но он ломается. Для меня это недостаточно надежно, чтобы использовать в коде производственного уровня. Это всего лишь мое мнение, и у вас может быть допустимый вариант использования, где это имеет смысл. Однако у меня нет возможности узнать это ... лол
Вы имеете в виду однострочный подход или весь этот подход в целом?
PS Я фактически изменил свой комментарий до того, как вы ответили, поэтому я не знаю, какой из них вы использовали. В первый раз я понял, что это не сработает.
Нет, только тот факт, что свойство класса может не существовать, и на это нет никаких проверок. Так что, если бы $service был равен foo, это дало бы вам фатальную ошибку, и у вас нет возможности проверить это в настоящее время. Но, как я уже сказал, не зная в полной мере, как вы его используете, я тоже не могу сказать вам этого. В некоторых случаях использования это может быть нормально, если есть ограничения на то, что может быть переменная. IE, возможно, он никогда не ошибается из-за этих других "проверок", таких как цикл foreach на жестко закодированном массиве и т.
Да, я понял. Я проверяю переменную $ service и выполняю всю обработку ошибок, прежде чем она достигнет этой точки.
вы можете попробовать правильную интерполяцию переменной ...
$booking->{"service_$service_date_end"}.' '.$booking->service_1_time_end