> I have to say, it doesn't get work, thinking this:
>
> $mixed1 = new Interger(2);
> $mixed2 = new Interge(3);
> $guess_what_type_is = $mixed1 + $mixed2;
>
> thanks
That one is actually pretty straight forward. Since + is a numeric
operation (with the one exception of array + array), it would call
castTo('numeric') on both. Then, the normal type rules would take
over. So if it returned an int, the result would be int(5). If it
returned a float, it would be float(5)...
The case where it would not be trivial to determine would be:
$mixed1 = new Integer(2);
$guess_what_type_it_is = $mixed1 ^ 1;
$guess_what_type_it_is2 = $mixed1 ^ '1';
Since xor operates on both strings and integers, which it should be
casted to would be non-trivial to predict.
However, we can solve this in the same way that normal type juggling
is solved. By being predictable. It doesn't always have to do it
correctly (as you want it to do) for each operation, as long as it
does it predictably. That way, we can know that xor will default to
an integer operation, so you'd have to make sure both are strings to
have it be a string operation (which incidentally is what happens
now):
$string = ((string) $mixed1) ^ '1';
And to be clear, I didn't write a patch for this, because I wanted to
discuss this first (rather than go through all the work just to be
shot down at first sight). If it's something that's worth
investigating, I'd be happy to work on a patch. But I'm not going to
go through all that work unless there's buy in from at least some of
the core developers. I'm not saying I'm looking for a "you do it, and
it'll be in", but more of a "this is interesting, let's see an
implementation before we decide, but the concept sounds
interesting/good"...
Anthony
On Sun, Feb 26, 2012 at 10:39 AM, Laruence <[email protected]> wrote:
> On Sun, Feb 26, 2012 at 10:57 PM, Anthony Ferrara <[email protected]> wrote:
>> I've gone back and re-read a bunch of the old posts on Type Hinting,
>> and have come to the conclusion that it won't be done any time soon.
>> Not because it doesn't have merit, but because there are at least a
>> few fundamental difficulties that are non-trivial to figure out while
>> still keeping the usefulness.
>>
>> So, I started thinking of a way that we can work around it. One
>> technique that has been passed around is to use object wrappers and
>> pass objects instead of scalars. Such as was suggested in:
>> http://marc.info/?l=php-internals&m=119543188808737&w=2
>>
>> One of the problems associated with this, is that before you work with
>> these types, you need to manually cast them back to the native type
>> they represent. We can try to deal with this problem using
>> __toString, but I don't think that's granular enough to really be of
>> much use in solving this problem...
>>
>> Another method we could use, is if we supported operator overloading
>> in objects. That way, we could overload the addition operator to
>> handle the operation. However, this becomes quite problematic, since
>> ordering of operations and interaction with disparate class trees is
>> going to get rather messy (and extremely fragile) quite quick.
>>
>> Let me throw out another possible solution. What if we added two new
>> magic methods to objects:
>>
>> public function __castTo($type);
>> public static function __castFrom($value);
>>
>> With these two methods, we could enable type-hinting by using
>> something very similar to auto-boxing. Let me start with a sample
>> implementation:
>>
>> class Integer {
>> protected $value = 0;
>> public function __construct($value) {
>> $this->value = $value;
>> }
>> public function __castTo($type) {
>> switch ($type) {
>> case 'int':
>> case 'numeric':
>> return $this->value;
>> case 'float':
>> return (float) $this->value;
>> }
>> throw new LogicException('Illegal Cast Operation Performed');
>> }
>> public static function __castFrom($value) {
>> if (!is_scalar($value)) {
>> throw new LogicException('Illegal Cast Operation Performed');
>> }
>> return new static((int) $value);
>> }
>> }
>>
>> Now, that enables us to do something like:
>>
>> $int = new Integer(2);
>> echo $int + 2; // 4, since __castTo was called with "numeric"
>> echo substr("foobar", 0, $int); // "fo" since __castTo was called with
>> "int"
>>
>
> I have to say, it doesn't get work, thinking this:
>
> $mixed1 = new Interger(2);
> $mixed2 = new Interge(3);
> $guess_what_type_is = $mixed1 + $mixed2;
>
> thanks
>> That demonstrates the __castTo usages. Now for the __castFrom...
>>
>> function foo(Integer $int) {
>> echo $int + 1;
>> }
>>
>> Now, under current rules, calling foo(1) would result in a fatal
>> error. However, we could change that to check if the class being
>> type-hinted for has a __castFrom method on it. If it does, it would
>> attempt to cast the value into that class. So calling foo(1) would
>> actually internally call Integer::__castFrom(1). And since that
>> returns an object of instance Integer, the hint would pass.
>>
>> These two additions would solve a few issues with type-hinting. First
>> off, it solves the "cast to" vs "error if" debate on passing a string
>> in the place of an integer. In this case, it would be up to the
>> __castFrom() method to determine that (thereby enabling both worlds
>> possible). Second, it solves the problem of having to wrap clumsy
>> APIs around scalars for hinting purposes ($foo->getInteger() + 1).
>> Third, it is still completely optional... Fourth, it keeps and tries
>> to embrace the dynamic type-cohersion nature of PHP...
>>
>> Now, that's not to say it's not without problems. Here are a few that
>> I can think of:
>>
>> 1. How should it deal with references? If I do `function foo(Integer
>> &$int)`, what should happen?
>> - I would argue that if you're trying to reference, the casting
>> functionality should not be expected to work at all. But that
>> introduces some inconsistency there. Not sure how to solve that...
>>
>> 2. Should it support casting from one object to another? Meaning if I
>> pass an SPLInt to something expecting Integer (from two different
>> trees), should __castFrom be called?
>> - I would argue that yes, it should. That would open the door for
>> compatibility layers to be built for cross-framework interaction that
>> happens seamlessly regardless of what was passed in. But it could get
>> a bit interesting, since that also could wind up having really
>> non-obvious side-effects, mainly because of object references...
>>
>> 3. Should "class casting" then be supported? We can currently do
>> (int) $foo. Should we then be able to specify a class in the cast
>> instead? (Integer) $foo?
>> - I like the concept, but that could be a nightmare to implement
>> as it's hard to tell if it's a class reference or a constant enclosed
>> in () for the parser. And seeing as you can have a constant with the
>> same name as a class, which should take precedence?
>>
>> 4. Should __toString still be called for string contexts? Or would
>> the presence of __castTo then negate the existance of __toString. So
>> if you don't implement __castTo(), __toString() would still be called
>> for a string cast. But if you do, __castTo would be called instead...
>> It would then work for backwards compatibility, while enabling
>> __toString to be eventually deprecated in favor of __castTo (not for a
>> long time mind you, but eventually, possibly 6 or 7)...
>>
>> What do you think?
>>
>> Anthony
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
>
> --
> Laruence Xinchen Hui
> http://www.laruence.com/