- 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);
}
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+156
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);
}
}
https://github.com/nuovo/vCard-parser
Ну за каким хуем обрабатывать один элемент как отдельный случай?!
bormand 23.06.2014 14:03 # 0
defecate-plusplus 23.06.2014 14:08 # +3
bormand 23.06.2014 14:54 # +1
Lure Of Chaos 23.06.2014 15:29 # +1
это чтобы не городить такие штуки как element->values->value
bormand 23.06.2014 16:07 # +1
Дурость это неюзабельная, а не пример динамики. По крайней мере в том виде, в котором мы это видим в данной либе.
> это чтобы не городить такие штуки как element->values->value
Это прекрасно, но разве так сложно было сделать, чтобы этот сраный один элемент возвращал итератор, возвращающий самого себя? Чтобы людям, которые хотят просто спарсить карточки в цикле не приходилось писать говно из топика... Иначе получается, что штуки типа element->values->value городить не надо, зато надо проверять count на единицу, и обрабатывать этот случай ОТДЕЛЬНО, ну либо юзать весьма неприятный хак с оборачиванием в массив, про который я написал ниже.
3.14159265 23.06.2014 16:21 # +1
Я писал такое как опять-таки оптимизацию.
Экономия на обжекте-обертке.
Например есть MultiMap с миллионами данных в котором у ключа может быть несколько значений.
Но такое бывает редко.
http://code.google.com/p/memory-measurer/wiki/ElementCostInDataStructures
LinkedList :: Bytes: 24.00
Оверхед LinkedLista большой и занимает много памяти (95% одиночных элементов обёрнуты в него), потому проверял instanceofом тип, ну и немного говнологики.
Правда от конечного пользователя все подобные хаки сокрыты.
bormand 23.06.2014 16:23 # 0
> Правда от конечного пользователя все подобные хаки сокрыты.
Во-во.
3.14159265 23.06.2014 16:25 # +1
bormand 23.06.2014 16:17 # +1
Lure Of Chaos 23.06.2014 17:16 # 0
bormand 23.06.2014 17:28 # +1
Lure Of Chaos 23.06.2014 19:07 # +1
brutushafens 23.06.2014 19:31 # +4
Vasiliy 23.06.2014 19:35 # +1
Есть такие блядские либы которые когда результат 1 возвращают объект а когда больше массив объектов, самое хуёвое, что когда нет результата воpвращают null.
bormand 23.06.2014 20:01 # +1
Это одна из них :)
> самое хуёвое, что когда нет результата воpвращают null.
Не, эта либа, слава богу, кидает экцепшн. За это автору респект.
kegdan 23.06.2014 20:14 # 0
bormand 23.06.2014 20:19 # 0
А что не так с экцепшеном из конструктора?
kegdan 23.06.2014 20:44 # 0
bormand 23.06.2014 20:54 # 0
Ты не забывай, в каком разделе ты находишься... Тут с чистой совестью могли захерачить die, или тупо не обрабатывать ошибку вообще...
1024-- 23.06.2014 20:53 # +1
На днях пописал немного на C# и сжёг стул. Порыться в мешке значений грозит смертью - это какой-то мини-ад.
Порадовался "сишному" Dictionary<TKey, TValue>.TryGetValue. Взял переменную, проверил результат - и никаких богомерзких try, catch, скобочек, сломанной структуры кода.
kegdan 23.06.2014 21:02 # 0
1024-- 23.06.2014 21:08 # 0
kegdan 23.06.2014 21:10 # +1
wvxvw 23.06.2014 23:29 # +2
Т.е. ж.скрипт вариант тут лажает, т.как
А чтобы узнать а был ли ключ, нужно сделать:
Я думаю, что соображения выше вместе с типичным поведением массивов при доступе по несуществующему индексу и мотивировали ошибки при обращении к хеш таблице.
По личным наблюдениям ошибка при попытке получить значение по несуществующему ключу - как правило бесполезная, попытка записать по невозможному ключу - хоть и не очень приятная, но оправдана, по крайней мере соображениями типа выделения памяти под массивы. Как правило код все равно сломается, если мы ничего не нашли по нужному ключу, ну а если мы эту ситуацию уже предусмотрели, то вообще замечательно.
bormand 23.06.2014 21:09 # 0
Дык есть же джве ситуации:
1) Отсутствие значения - баг в коде (из поля в базе прочиталась херня, которую мы не знаем как обрабатывать). Тут лучше кинуть исключение и обработать его тупо отбоем запроса, закрытием сессии или даже остановкой сервера. Прокидывать коды возврата в таких случаях - противно.
2) Отстутствие значения - нормальная ситуация. Тут как раз поможет TryGetValue. Исключения здесь не особо удобны.
1024-- 23.06.2014 21:15 # 0
[] для нормальных ситуаций, TryGetValue - для багов в коде (по аналогии с гармоничными привычным [...] и длинным at(...)). TryGetValue для меня означает "ну я сейчас попытаюсь взять значение, а если не получится - ловите исключение".
kegdan 23.06.2014 21:22 # 0
Говоряят стетор уходит. Как Ельцин
1024-- 23.06.2014 21:37 # 0
Хм, жаль, что уходит. Как человек, способный сказать что-то не про программирование, он полезен для сайта. Можно читать только комментарии wvxvw и товарищей на ГК и расширять кругозор.
kegdan 23.06.2014 21:48 # +4
Хорей
Дактиль
Амфибрахий
Анапест
Просвещайтесь с Кегданом.
А вообще ГК превратился в форум. Порой интереснее просто болтать о всяком, чем обсуждать код. И это хорошо.
eth0 24.06.2014 19:46 # +1
eandr67 23.06.2014 20:01 # −1
foreach((array)$cards as $card)
bormand 23.06.2014 20:08 # +1
$cards - объект с итератором. Х.з., что там получится после такого каста... Лень тестить, но, имхо, не взлетит.
> if (!is_array($cards)) $cards=array($cards);
> foreach(is_array($cards)?$cards : array($cards) as $card)
Туда же.
3.14159265 23.06.2014 14:54 # +4
Оптимизация же.
Для малого количества итераций рынарешники вручную анроллят циклы.
bormand 23.06.2014 15:01 # +1
Не, я поступил совсем по-читерски:
gost 13.07.2014 08:29 # +2
Оптимизировано
wvxvw 23.06.2014 16:27 # +2
foreach (ensure_array($whaterver) as $x) { ... }
и все счастливы.
bormand 23.06.2014 16:33 # +1
Т.е. вместо лечения болезни нужно задавить ее симптомы? PHP way, хуле.
wvxvw 23.06.2014 16:40 # 0
Александрия - это очень уважаемая библиотека, без нее практически ни в одном проекте не обходится.
Fike 23.06.2014 16:28 # +2
охуенный тест!
bormand 23.06.2014 16:33 # 0
P.S. Да не, к либе в целом претензий нет, свою задачу она решает.
Fike 23.06.2014 18:40 # 0
а почему не эта либа?
https://github.com/fruux/sabre-vobject
bormand 23.06.2014 18:45 # +1
Да там по задаче надо 2-3 поля из vcard'а выцепить... Поэтому выбирали либу попроще, чтобы можно было прочесть и понять. И либы на 30+ файлов сразу оказались в пролете по этому критерию...
bormand 23.06.2014 20:28 # 0
Vasiliy 24.06.2014 12:31 # +4
bormand 24.06.2014 13:05 # 0
Нет, просто интересна причина.
kegdan 24.06.2014 13:52 # 0
bormand 24.06.2014 14:52 # +2
brutushafens 24.06.2014 15:00 # +1
kegdan 24.06.2014 15:19 # +1
eth0 24.06.2014 19:48 # 0