Hi Guido Am 14.05.15 um 01:03 schrieb Guido Contreras Woda: > @francois I understand your point, but I have a different view of the > userland situation. Let me give some examples: > > In the array case, Iterator / Traversable doesn't solve casting, it solves > iteration. > Given a Traversable object from a third party library, if a method from > another (or the same) third party library requires an array as an argument, > the developer would have to iterate the object and build an array herself > in a Mediator or Adapter class. If she could cast it, then all she would > need to do is orchestrate the messaging, without fiddling in the middle. > > As for the other cases, there are plenty of examples that could prove that > a userland object may want to have a different representation as a string > than as other scalar types. Money is the first that comes to mind: > > $money = new Money(12.5, Money::DOLLARS); > var_dump((string) $money); // string(5) "$12.5" > var_dump((float) $money); // float(12.5) > > While there is information loss in the conversion, it is just a userland > example that could well benefit from different representations in the > various scalar types. For example, if an interest were to be calculated > from a Money object, the currency wouldn't matter, and the interest > calculator may as well expect just a float as argument. > > Also, there's a huge cognitive gap. For example, if a developer wants an > object to be evaluated as a boolean, she would have to force an empty > string as the __toString() method return. That by itself does not represent > her intention. Without proper documentation, it's just a matter of time for > another developer to find this behavior and remove it or replace it with > something more representative of a string representation of the object. > > > Cheers! > > For Arrays there are already the ArrayAccess-Interface as well as the ArrayObject-Class which "allows objects to work as arrays" (http://php.net/arrayobject). That ArrayObjects are not covered by the typehint "array" is something that I'm sure can be changed. And whether the typehint "array" covers arrays, ArrayObjects and some special interface that can be implemented by any arbitrary class is open for discussion.
But for me the main question is whehter we are just talking about
*casting* an object to a certain type or letting an object *behave* like
a certain type.
Let me rephrase your example:
function getprice(int $price) {}
$money = new Money(12.5, Money::DOLLARS);
Will get_price($money) work as the object is cast to int and therefore
we have an int in the method getprice? Or will getprice actually use the
Money-object but all operations are done against the int-representation?
That would also allow something like this
function getprice(int $money) {
$money = $money * CURRENT_VAT;
return $money;
}
which would alter the object in question!
Or are we talking about two completely different things?
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
smime.p7s
Description: S/MIME Cryptographic Signature
