PHP 5.5.0 beta1 (diskuse)

[Marv-CZ]

To jsem zvědav, kolik tam zase bude „vylepšení“, která způsobí, že stávající webové aplikace přestanou fungovat.

[Foo Bar]

Nepomohlo by místo trollování se podívat do UPGRADING dokumentu?

========================================
3. Deprecated Functionality
========================================

- The original MySQL extension is now deprecated, and will generate deprecation
  warnings when connecting to a database through mysql_connect(),
  mysql_pconnect() or by establishing an implicit connection. Use MySQLi or PDO
  instead.
- The preg_replace /e modifier is now deprecated.  Use
  preg_replace_callback instead.
  (https://wiki.php.net/rfc/remove_preg_replace_eval_modifier)
- IntlDateFormatter::setTimeZoneID() and datefmt_set_timezone_id() are
  deprecated. Use IntlDateFormatter::setTimeZone() or datefmt_set_timezone()
  instead.
- mcrypt_ecb(), mcrypt_cbc(), mcrypt_cfb() and mcrypt_ofb() now throw
  E_DEPRECATED. Their use was already previously discouraged in the docs,
  but that predated the existence of E_DEPRECATED.

a

========================================
4. Changed Functions
========================================

- pack()/unpack() had the following changes, which bring it more in line
  with Perl's behavior:
  - Implemented format character "Z": NULL padded string, with trailing NULL
    bytes removed.
  - Changed format character "a": this no longer removes trailing NULL bytes.
  - Changed format character "A": all trailing ASCII whitespace is now removed
    (defined as spaces, tabs, \r, \n and NULL).
- MessageFormatter::format() and related functions now accepted named arguments
  and mixed numeric/named arguments in ICU 4.8+.
- MessageFormatter::format() and related functions now don't error out when
  an insufficient argument count is provided. Instead, the placeholders will
  remain unsubstituted.
- MessageFormatter::parse() and MessageFormat::format() (and their static
  equivalents) now don't throw away better than second precision in the
  arguments.
- IntlDateFormatter::__construct and datefmt_create() now accept for the
  $timezone argument time zone identifiers, IntlTimeZone objects, DateTimeZone
  objects and NULL. It used to accept only time zone identifiers and NULL.
  Invalid time zone identifiers are no longer accepted. Emptry strings are
  no longer accepted.
- The default time zone used in IntlDateFormatter::__construct and
  datefmt_create() (when the corresponding argument is not passed or NULL is
  passed) is now the one given by date_default_timezone_get(), not the
  default ICU time zone.
- The time zone passed to the IntlDateFormatter is ignored if it is NULL and if
  the calendar passed is an IntlCalendar object -- in this case, the
  IntlCalendar's time zone will be used instead. Otherwise, the time zone
  specified in the $timezone argument is used instead. This does not affect
  old code, as IntlCalendar was introduced in this version.
- IntlDateFormatter::__construct and datefmt_create() now accept for the
  $calendar argument also IntlCalendar objects.
- IntlDateFormatter::getCalendar() and datefmt_get_calendar() return false
  if the IntlDateFormatter was set up with an IntlCalendar instead of the
  constants IntlDateFormatter::GREGORIAN/TRADITIONAL. IntlCalendar did not
  exist before this version.
- IntlDateFormatter::setCalendar() and datefmt_set_calendar() now also accept
  an IntlCalendar object, in which case its time zone is taken. Passing a
  constant is still allowed, and still keeps the time zone.
- IntlDateFormatter::format() and datefmt_format() now also accept an
  IntlCalendar object for formatting.
- php_logo_guid(), php_egg_logo_guid(), php_real_logo_guid() and 
  zend_logo_guid() have been removed
- set_error_handler(NULL) can now be used to reset the error handler.
  Furthermore both set_error_handler(NULL) and set_exception_handler(NULL) will
  now return the previously defined error/exception handler. Previously
  bool(true) was returned.
- setcookie(), setrawcookie() and ext/session now send Max-Age headers alongside
  Expires headers. (see https://wiki.php.net/rfc/cookie_max-age)
- curl_setopt now accepts new option CURLOPT_SAFE_UPLOAD and CURLFile object for
  safer file uploads (see https://wiki.php.net/rfc/curl-file-upload)
- Functions in the socket extension now do not emit warnings when the errno is
  EAGAIN, EWOULDBLOCK or EINPROGRESS.

[Marv-CZ]

To měl být povzdech nad tím, že po upgradu PHP toho přestane vždy hromada fungovat. To je sice hezké, že to někde sepíší, ale neřeší to tu hromadu práce všech vývojářů s opravami. Chápu, že se snaží dát do kupy bordel, který v PHP je z dob jeho počátků, ale někdy je to opravdu úmorné.

[Failer]

Tak warning mysql_connect() se setká se spoustou "nadšených" ohlasů, hlavně v komerční sféře. mysqli_connect() stále není všude a PDO je (u mě) samo o sobě bordel.
PDO
1. nechápu, jak někdo v softu, kde má výtečná pole, používá na parametry připojení 1 řetězec, obzvlášť, když hlásá, že má spojit dotazovaní do více typů databází.
2. mi uchází, proč používá 2-fázové sestavení příkazu jako třeba u LIKE.
3. o nutnosti ve finále sáhnout do kódu prakticky 70% aplikací nemluvě.

[Foo Bar]

DEPRECATION warning se dá vypnout, ale pak nikdo nemůže říct, že nebyli varováni, až přejdou na PHP 5.6, kde to pravděpodobně bude pryč.

Jinak změny v PHP jsou už nějakou dobu řízeny komunitně, takže i ta "komerční" sféra má a měla možnost se k tomu vyjádřit.

Změny se dějou i v jiných jazycích (jen si vemte takový přechod z Python 2.x na Python 3.x) a mám takový pocit, že se to v PHP zlepšuje, například už si nepamatuju, kdy se naposledy změnilo API mezi patch verzemi, což je pozitivní, a kam například Ruby/Rails komunita ještě ani zdaleka nedospěla :-P.

[pavlix]

1. nechápu, jak někdo v softu, kde má výtečná pole

To nemluvíš o PHP, že ne?

používá na parametry připojení 1 řetězec,

Řetězec je podle mě nejlepší a neuniverzálnější metoda, bez ohledu na programovací jazyk.

[radix]

Řetězec je podle mě nejlepší a neuniverzálnější metoda, bez ohledu na programovací jazyk.

Ne ne, to je samozrejme jen bitove pole.

[pavlix]

Ha ha ha.

[radix]

Zajimave, presne toto jsem chtel napsat puvodne.

[kralyk z abclinuxu]

Tak warning mysql_connect() se setká se spoustou "nadšených" ohlasů, hlavně v komerční sféře.

Počítám, že nikdo neaktualizuje na svém produkčním serveru PHP (nebo obecně prakticky jakýkoli balík) jen tak hala bala bez nějakého zjišťování, co se změnilo. Takže každý ví dobředu do čeho jde a vzhledem k tomu, že afaik nejde o bezpečnostní aktualizaci, tak má každý času na upgrade aplikací habaděj... Vždyť je to teprv beta

[Failer]

Díky všem za reakce. Naházím to na hromadu.
Surý
Error se vypnout dá taky, že. Lov chyb v ostrém je ale o to zajímavější.
Dělo jménem Py2xPy3 zásadním změnám v části vnitřní logiky, včetně projevu jako změna základního api (onen "jeden přepis").
Pavlix:
Víš o nějakém jiném jazyku, kde můžeš takto elegantně pole znásilňovat? Třeba se takto dá vtipně využít pro adresářové struktury. O různých nastaveních lecčehos ani nepíšu.
Řetězec je hezký, dokud nenese vůči systému více informací, než je 1.
kralyk:
Vím o pár podnikatelích, co mají systémy, co pamatují ještě první PHP4. A minimálně jeden na tom má i docela klíčové prvky své práce.
Na druhou stranu klidně zkritizuji některé jeho "programátory", protože by mě nikdy nenapadlo použít serialize() jako úložiště pro nastavení, které je pak řádkem nacpáno do databáze. A to nejde o nic klíčového.

[pavlix]

Víš o nějakém jiném jazyku, kde můžeš takto elegantně pole znásilňovat?

Jazyk, který má takto řešená pole je mi podezřelý už z principu. PHP ten obrázek dotváří tím, že má špatně řešených věcí mnohem víc. Ale na druhou stranu ano, znám ještě další oblíbený jazyk, který míchá slovníky/hashtable a indexovaná pole. Jmenuje se Lua.

Třeba se takto dá vtipně využít pro adresářové struktury.

Nejsem si vědom toho, že by to v PHP šlo lépe než v jakémkoli jiném dynamickém jazyku.

O různých nastaveních lecčehos ani nepíšu.

Nejsem si vědom toho, že by to v PHP šlo lépe než v jakémkoli jiném dynamickém jazyku.

Řetězec je hezký, dokud nenese vůči systému více informací, než je 1.

Plácání prázdné slámy.

Vím o pár podnikatelích, co mají systémy, co pamatují ještě první PHP4. A minimálně jeden na tom má i docela klíčové prvky své práce.

A?

[kralyk z abclinuxu]

Vím o pár podnikatelích, co mají systémy, co pamatují ještě první PHP4. A minimálně jeden na tom má i docela klíčové prvky své práce. Na druhou stranu klidně zkritizuji některé jeho "programátory", protože by mě nikdy nenapadlo použít serialize() jako úložiště pro nastavení, které je pak řádkem nacpáno do databáze. A to nejde o nic klíčového.

Nic takového jsem nenapsal, ani jsem tím nic takového nemyslel. (Jinak ale pokud někomu stačí PHP4 a nejedná se o verzi s bezpečnostními problémy, tak proč ne...)

Jinak když už máš tak v oblibě sarkastické parafrázování, tak taky přispěju svou troškou:

Failer: Říká se, že kdo chce psat bít, hůl si vždy najde. Mně se podařilo najít samopal a dvě katany.

[Foo Bar]

Kde jste přišel na to, že chci vypínat celý error_reporting? Buď PHP neznáte, nebo úmyslně manipulujete fakty. Skoro nevím, co je v téhle debatě horší.

Já mluvím o pouhém vypnutí DEPRECATION warningů na produkci, což je ostatně standardní nastavení:

$ grep ^error_reporting php.ini-*
php.ini-development:error_reporting = E_ALL
php.ini-production:error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

[Foo Bar]

A Zend OpCache zjevně zase psal někdo, kdo v životě neviděl jinou Unixovou platformu než Linux. Build failuje na kFreeBSD a na Hurdu :(.

[Acci]

Na Macu jede v pohodě.

[Václav HFechs Švirga]

Ty máš na Hurdu webový server? Drsné!

[Pev]

Ondřej Surý je jeden z uploaderů PHP balíku na Debianu (dle gitu a changelogu dlouhodobě nejaktivnější) a Debian kompiluje balíky i pro Hurd a kFreeBSD. Takže jeho povzdechy jsou celkem pochopitelné .