- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
if (count($vCard) == 1) {
print_r($vCard -> n);
print_r($vCard -> tel);
} else {
foreach ($vCard as $vCardPart)
{
print_r($vCardPart -> n);
print_r($vCardPart -> tel);
}
}-
PHP / Говнокод #16208
+156
https://github.com/nuovo/vCard-parser
Ну за каким хуем обрабатывать один элемент как отдельный случай?!Запостил:
bormand,
23 Июня 2014
Follow us!
это чтобы не городить такие штуки как element->values->value
Дурость это неюзабельная, а не пример динамики. По крайней мере в том виде, в котором мы это видим в данной либе.
> это чтобы не городить такие штуки как element->values->value
Это прекрасно, но разве так сложно было сделать, чтобы этот сраный один элемент возвращал итератор, возвращающий самого себя? Чтобы людям, которые хотят просто спарсить карточки в цикле не приходилось писать говно из топика... Иначе получается, что штуки типа element->values->value городить не надо, зато надо проверять count на единицу, и обрабатывать этот случай ОТДЕЛЬНО, ну либо юзать весьма неприятный хак с оборачиванием в массив, про который я написал ниже.
Я писал такое как опять-таки оптимизацию.
Экономия на обжекте-обертке.
Например есть MultiMap с миллионами данных в котором у ключа может быть несколько значений.
Но такое бывает редко.
http://code.google.com/p/memory-measurer/wiki/ElementCostInDataStructures
LinkedList :: Bytes: 24.00
Оверхед LinkedLista большой и занимает много памяти (95% одиночных элементов обёрнуты в него), потому проверял instanceofом тип, ну и немного говнологики.
Правда от конечного пользователя все подобные хаки сокрыты.
> Правда от конечного пользователя все подобные хаки сокрыты.
Во-во.
Есть такие блядские либы которые когда результат 1 возвращают объект а когда больше массив объектов, самое хуёвое, что когда нет результата воpвращают null.
Это одна из них :)
> самое хуёвое, что когда нет результата воpвращают null.
Не, эта либа, слава богу, кидает экцепшн. За это автору респект.
А что не так с экцепшеном из конструктора?
Ты не забывай, в каком разделе ты находишься... Тут с чистой совестью могли захерачить die, или тупо не обрабатывать ошибку вообще...
На днях пописал немного на C# и сжёг стул. Порыться в мешке значений грозит смертью - это какой-то мини-ад.
Порадовался "сишному" Dictionary<TKey, TValue>.TryGetValue. Взял переменную, проверил результат - и никаких богомерзких try, catch, скобочек, сломанной структуры кода.
Т.е. ж.скрипт вариант тут лажает, т.как
А чтобы узнать а был ли ключ, нужно сделать:
Я думаю, что соображения выше вместе с типичным поведением массивов при доступе по несуществующему индексу и мотивировали ошибки при обращении к хеш таблице.
По личным наблюдениям ошибка при попытке получить значение по несуществующему ключу - как правило бесполезная, попытка записать по невозможному ключу - хоть и не очень приятная, но оправдана, по крайней мере соображениями типа выделения памяти под массивы. Как правило код все равно сломается, если мы ничего не нашли по нужному ключу, ну а если мы эту ситуацию уже предусмотрели, то вообще замечательно.
Дык есть же джве ситуации:
1) Отсутствие значения - баг в коде (из поля в базе прочиталась херня, которую мы не знаем как обрабатывать). Тут лучше кинуть исключение и обработать его тупо отбоем запроса, закрытием сессии или даже остановкой сервера. Прокидывать коды возврата в таких случаях - противно.
2) Отстутствие значения - нормальная ситуация. Тут как раз поможет TryGetValue. Исключения здесь не особо удобны.
[] для нормальных ситуаций, TryGetValue - для багов в коде (по аналогии с гармоничными привычным [...] и длинным at(...)). TryGetValue для меня означает "ну я сейчас попытаюсь взять значение, а если не получится - ловите исключение".
Говоряят стетор уходит. Как Ельцин
Хм, жаль, что уходит. Как человек, способный сказать что-то не про программирование, он полезен для сайта. Можно читать только комментарии wvxvw и товарищей на ГК и расширять кругозор.
Хорей
Дактиль
Амфибрахий
Анапест
Просвещайтесь с Кегданом.
А вообще ГК превратился в форум. Порой интереснее просто болтать о всяком, чем обсуждать код. И это хорошо.
foreach((array)$cards as $card)
$cards - объект с итератором. Х.з., что там получится после такого каста... Лень тестить, но, имхо, не взлетит.
> if (!is_array($cards)) $cards=array($cards);
> foreach(is_array($cards)?$cards : array($cards) as $card)
Туда же.
Оптимизация же.
Для малого количества итераций рынарешники вручную анроллят циклы.
Не, я поступил совсем по-читерски:
Оптимизировано
foreach (ensure_array($whaterver) as $x) { ... }
и все счастливы.
Т.е. вместо лечения болезни нужно задавить ее симптомы? PHP way, хуле.
Александрия - это очень уважаемая библиотека, без нее практически ни в одном проекте не обходится.
охуенный тест!
P.S. Да не, к либе в целом претензий нет, свою задачу она решает.
а почему не эта либа?
https://github.com/fruux/sabre-vobject
Да там по задаче надо 2-3 поля из vcard'а выцепить... Поэтому выбирали либу попроще, чтобы можно было прочесть и понять. И либы на 30+ файлов сразу оказались в пролете по этому критерию...
Нет, просто интересна причина.