[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-internals
Subject:    [PHP-DEV] Bug #60873: DateTime properties
From:       Jakub Zelenka <bukka () php ! net>
Date:       2013-07-25 17:19:06
Message-ID: CAEKnhAHFMheyS6WCswpfd8HCQ-rj-eGjzX=KTWjtUZJ09qKcgQ () mail ! gmail ! com
[Download RAW message or body]


Hi,

This is not only about https://bugs.php.net/bug.php?id=60873 :)

First of all, I don't think that this bug is a bug. :)

It's about accessing undocumented properties that are created as a side
effect of calling get_properties DateTime object handler. The properties
are probably created to allow debugging and mainly serialization of the
object.

The problem is that these properties (date, timezone, timezone_type) are
publicly available only after calling print_r or serialize or other
function that internally uses get_properties handler. This is not exactly a
consistent behavior of the object...

There are few possible solution to the problem:

1. Making these properties always available. This was my initial idea that
is BC and actually fix the "bug". The properties would be retrieved using
read_property handler. This is implemented in the PR:
https://github.com/php/php-src/pull/393 . It would make sense to also add
write_property handler and add warning if the user try to write to the
property as this should be done by set* method. The properties would have
to be documented of course. It would be sort of similar as xml_dom object
read-only props.

2. Making these properties always hidden. There are two solutions for this:
2.1 Retrieving a copy of properties hash table in get_properties:
https://github.com/bukka/php-src/compare/date_props . There was actually a
props HashTable in php_date_obj that wasn't used so I used it here...
2.2  Using a new serialize handler that I have just requested for addition
and get_debug_info. Then return a copy of HashTable (the same as
properties). The patch:
https://github.com/bukka/php-src/compare/date_serialize

I was talking only about DateTime but exactly the same problem is in other
objects (DateTimeZone...). I will be happy to write patches for other
objects as well after we make a decision which solution is the best!

What do you think?

Jakub


[prev in list] [next in list] [prev in thread] [next in thread]