Используем $_COOKIE как $_SESSION

[trueneutral]

С одной стороны — хорошо, с другой — накладывает излишние ограничения (вроде невозможности переопределить время выставления кук). На мой взгляд, лучше использовать собственные врапперы вроде setcookie($name, $value), getcookie($name), не менее удобные, но дающие возможность указывать значения отличные от дефолтовых.

[Skull]

А помоему можно допилить этот класс, сделав _setCookie() доступной вне класса. Тогда и дефолтное expire можно изменить, и path.

[mr_avi]

И получится функция set_cookie:)

[Nc_Soft]

+1

[Skull]

Да :)
Нужно в нее еще добавить сохранение в массив storage[] и будет действительно setcookie с без стандартного потери функционала.

[resurection]

Можно добавить публичный метод:
simpleSetCooke($name, $value, $expire=0x7FFFFFFF)

Остальные параметры (domain, secure, httponly) практически никогда не используются и идут в лес.

Потом можно допилить эту функцию, что бы третьим аргументом она могла принимать строку и прогонять её через strtotime(). Например:

$COOKIE->simpleSetCooke('foo', 'bar', '+2 week'); // разве не клёво?

В любом случае, топикстартер создал фундамент, а построить на нём можно очень много.

[resurection]

P.S. Переопределять глобальные переменные, это конечно же очень плохо.

[mr_avi]

Ну автор как раз хотел избавиться от функций (методов), а тема оберток стандартных функций (глобальных переменных) это уже другая тема. А так да, действительно классно, но слишком длинно ($COOKIE->simpleSetCookie...), лучше уж Cookie::set(...) какой-то.

[romy4]

«Эс как доллар», прастите)

[zim32]

У меня без всяких SPL и ArrayAccess die(print_r($_COOKIE)); выводит массив кук. Я что-то делаю не так?

[zim32]

Простите. Вы имеете ввиду установку кук. Я подумал что получение.

[zim32]

Вообще ArrayAccess очень удобная порой штука. Я на ней делал поиск переводов в шаблонах. Просто переопределяя обычный массив переводов объектом с ArrayAccess

[MpaK999]

Сто лет не работал с $_COOKIE напрямую, всё через класс, свой или от CodeIgniter.

[alagar]

trigger_error('Cookie value was not set', E_USER_WARNING); может лучше Exception кидать?

[the_ghost]

Да ладно. Всегда ли приложение не может работать без куки?

[alagar]

не понял вас

[Riateche]

Exception нужно еще отлавливать, по умолчанию скрипт просто завершит работу при возникновении исключения. Обычный warning просто будет проигнорирован.

[alagar]

что мешает добавить try{} catch(e)?

[KeepYourMind]

Все еще игнорируете варнинги? Тогда мы идем к вам!

[IgorMats]

А я наоборот предпочитаю обертки, даже для $_SESSION или там $_POST.

[Disturbed]

Боюсь, что unset реализован неправильно — следуя этому интерфейсу, клиент будет ожидать, что кука удалится на клиенте после вызова unset.
Да, и кстати, — переписывать супеглобальные массивы — это плохо :)

[STEVER]

да, вы правы, unset стоит дополнить.

[shagguboy]

trigger_error('Cookie value was not set', E_USER_WARNING);
не делайте так… кидайте исключение. их придумали гораздо раньше SPL

[ainu]

Идея на пятёрку. Велосипед — это здорово.
Вообще, ИМХО велосипед = новый код, которого раньше не было, который реализует существующую идею или её часть.

[mr_avi]

А как задать домен, время жизни и другие параметры?

[nick4fake]

Забавно. Вас не смущает, что работа с cookies на php потому и происходит через setcookie, что иначе выплывает ряд проблем? Идея интересна в реализации, но абсолютно бесполезна

[AstonMartin]

Каких? Расскажите, если не затруднит.

[nick4fake]

Во-первых, самая очевидная проблема — заголовки могут быть уже отправлены. Сегодня это не так актуально, но сама функция setcookie добавляет наглядности.
Во-вторых, наличие отдельно read-only массива и функции установки символизирует саму схему работы с ними. Только после отправки заголовка и обновления страницы мы можем удостовериться, что cookie установлен. У вас же все в перемешку
Это то, что сходу в голову пришло. Может еще что-то придумаю (не считая сложности реализации, неустойчивости и т.д.: не будем консерваторами и вообще унылыми личностями, эти проблемы несущественны)

[mr_avi]

В куках, в отличии от сессии, не только ключ значение, а еще и ряд дополнительных параметров хранения.

[VolCh]

ООПничать так ООПничать — саму куку нужно сделать объектом. Обязательный параметр в конструкторе -значение куки, необязательные — домен, время и т. д. Плюс метод __toString(), возвращающий строковое значение. А методы ArrayAccess возвращают/принимают объект. Как-то так :)

[winbackgo]

Решение абсолютно бесполезно, хотя бы по следующим причинам:
1. Любой опытный программист знает что $_COOKIE['name'] = 'val' никуда ничего не сохраняет. И подсознательно это использовать не будет.
2. В любом месте программы можно допустить ошибку if ($_COOKIE['name'] = 'myval') и весь механизм летит к черту. Это как вариант). Проблема глобальных переменных.
3. Куки ставятся на заранее заданное кол-во времени и управлять этим никак нельзя, возвращаемся к setckookie. А если мне надо их поставить на год? А если на сессию?
Навскидку что пришло в голову, возможно есть еще нюансы.

Рискну предложить свою обертку которую я использую. Подрихтовал немного и выложил на гитхаб: github.com/behigh/Cookie

[mr_avi]

2. Во избежание всегда делаю в йода-стиле if ( 'val' == $var )

Обёртка хорошая, а для сессии подобный враппер не используете?

[winbackgo]

>> для сессии подобный враппер не используете?
Да, конечно использую. Но сам объект управления сессиями в моем случае делает намного больше чем просто управлением параметрами. Это аутентификация, а также предоставление данных о текущем пользователе. Иными словами, класс заточен под фрэймворк.

[namespace]

Спасибо. Это правда очень полезно.

[wartur]

у меня есть замечание по части кода.

> $domain = false, $secure = false, $httponly = false
лучше в таком случае пользоваться null типом.
а проверять if(isset($variable)){...}

в таком случае просто быстрее будет.

[Big_Shark]

Можно ещё добавить сохранения массивов

$_COOKIE['lang'] = array('ru', 'en');