« Return to Thread: Debugging/deciphering library methods
Re: Re: Debugging/deciphering library methods
by Ryan Boyd-3
::
Rate this Message:
On 9/29/07, Trevor Johns <trevor@...> wrote:
As of 5.2.0, with echo and print methods, yep. Prior to 5.2.0, only echo/print statements which used only the value (and no concatenation) would work.
From the magic methods doc:
" It is worth noting that before PHP 5.2.0 the __toString method was only called when it was directly combined with echo() or print(). Since PHP 5.2.0, it is called in any string context (e.g. in printf() with %s modifier) but not in other types contexts (e.g. with %d modifier). Since PHP 5.2.0, converting objects without __toString method to string would cause E_RECOVERABLE_ERROR."
I still don't know what the result of the following would be (need to test):
$foo = $stringBar . $objectWithToStringMethod;
Also, perhaps more importantly, would be equality checking and things like that.
Basically, it just seems weird to me that someone would call a setter using one type, but would get back another type when calling the getter. Is there any precedence for this that you're aware of?
Thanks,
-Ryan
On Sep 27, 2007, at 4:02 PM, Ryan Boyd wrote:
>> In order not to break backwards compatibility, we could use
>> introspection to choose the correct behavior. If an instance of
>> Zend_Gdata_App_Extension is detected, we'd use the current behavior
>> (just set the property to point to the provided object). For all
>> other types, we'd use the new behavior (create a new instance of the
>> property's model and initialize it with the provided data).
>
> This is the reason I recommended appending the attribute name with
> Value when an option like this is available. I don't think we can
> change the normal setters, because people will have no idea what's
> going to come out of the getter.
>
> so, I call $entry->title = 'foo'
> and then I get $entry->title... should that be an
> Zend_Gdata_App_Extension_Title, or just the string 'title'.
It would be an instance of Zend_Gdata_App_Extension_Title.
However, for most operations the user can pretend it's the string
'title'. When it gets passed to something that is expecting a string,
__toString() should get called assuming they're using PHP 5 (which is
supposed to be a requirement for ZF).
As of 5.2.0, with echo and print methods, yep. Prior to 5.2.0, only echo/print statements which used only the value (and no concatenation) would work.
From the magic methods doc:
" It is worth noting that before PHP 5.2.0 the __toString method was only called when it was directly combined with echo() or print(). Since PHP 5.2.0, it is called in any string context (e.g. in printf() with %s modifier) but not in other types contexts (e.g. with %d modifier). Since PHP 5.2.0, converting objects without __toString method to string would cause E_RECOVERABLE_ERROR."
I still don't know what the result of the following would be (need to test):
$foo = $stringBar . $objectWithToStringMethod;
Also, perhaps more importantly, would be equality checking and things like that.
Basically, it just seems weird to me that someone would call a setter using one type, but would get back another type when calling the getter. Is there any precedence for this that you're aware of?
Thanks,
-Ryan
> I think appending the attribute names with 'Value' will allow you
> to use either option.
It would. However, it feels like we'd be duplicating code. Wouldn't
'$entry->titleValue' be identical to calling '$entry->title-
>__toString()', or '(string) $entry->title' on PHP 5?
>> Extensions which take several parameters, such as
>> Zend_Gdata_Extension_When does, will be tricky. Unfortunately PHP
>> doesn't allow method overloading. I can think of a way to hack this
>> in using optional parameters ($data, $startTime = null, $endTime =
>> null, ... -- where $data could be either an Extension object or
>> $valueString), but I'd really like to avoid doing that. Any better
>> thoughts? Or should we just not implement a shortcut to instantiate
>> these objects?
>
> I think my first step would only be to allow these Value
> attributes for things that either have only 1 value to deal with,
> or things that have multiple values, but only 1 is used 95% of time.
>
> Then we could follow up with optional ones if we want, but the goal
> for this was to cover the largest use cases.
Sounds good to me.
--
Trevor Johns
http://tjohns.net
« Return to Thread: Debugging/deciphering library methods
| Free embeddable forum powered by Nabble | Forum Help |
