On Sun, Sep 8, 2019, at 2:11 PM, Mike Schinkel wrote: > Hi Stephen, > > Thanks again. > > > So let me start out by clarifying that what *I* was suggesting with unions > > is quite a different concept than you’re talking about. > > I did not realize you were proposing a different solution, too. Sorry I > missed that. > > > yes, I’m aware there’s potential ambiguous cases - what if the destination > > accepts `string|int` and the object supports both interfaces? > > > Precisely. And the goal of my proposal was in part to eliminate that > ambiguity. > > > Ok - the example given makes “sense” with the understanding that it’s > > alternative ‘short’ syntax - but that makes it yet another step further > > from ‘intuitive’ to me, compared with current type hints, and the extension > > to allow unions Nikita introduced - > > Acknowledged. > > > and if Im not mistaken it makes it incompatible too (i.e. you can’t have > > the behaviour Nikita’s RFC describes and what you describe with the > > ‘anonymous unions’ - they’re too very different approaches using the same > > syntax. > > I do not see how they are incompatible except for the details mine > changes, but maybe that is moot at this point? > > > I think the intuitiveness factor is easier to explain if you consider the > > case of the Number example - plenty of things will work exactly as you > > expect if you use either an int or a float. But then with your proposal > > suddenly you don’t have a scalar variable any more - yes I know you can > > call `value()` - part of the point of type hints is to reduce boilerplate > > with type checking arguments within the function body - and now you have to > > call a method to get a usable value anyway? > > I do not see any technical reason why mine would not be able to behave > the same using the magic methods you were proposing such as > __toString() and for other scalar types — since fundamentally the > proposed union type would be a class anyway. When used that way it > would nullify the benefit of the explicit typing, but if that is what > the developer wanted who was using then why not? > > In that context it would be almost the same as just passing in a scalar. > > > The GUID example still confuses me in terms of how your example ‘helps’. If > > $guid->getGuid returns null (signifying it’s a string?) presumably I still > > want to do something with that string - otherwise I wouldn’t have accepted > > it as a valid type - at which point I might as well just do a `instanceof` > > or `is_string` call - but now I have to check if the value I was given is > > null, even if I didn’t specify the parameter as being nullable? > > It does not help that way. The main help is with $guid->type() which > can be used in a switch. It's just cleaner code, though I can > appreciate that some might see this as not really a benefit: > > function processGuid(string|Guid $guid) { > switch( $guid->type()) { > case 'Guid': > $guid->toGuid()->doSomething(); > break; > case 'string': > $g = new Guid($guid->toString()); > $g-> doSomething(); > break; > } > } > > The other benefit is that it becomes a first-class concern that can be > extended when named union classes are used so I could implement this > inside the union class and use it in many functions like this, if I > wanted, rather than have to use type checking boilerplate in Every. > Single. Function: > > class GuidUnion { > types string|Guid > public function doSomething() { > switch( $this->type()) { > case 'Guid': > $this->toGuid()->doSomething(); > break; > case 'string': > $g = new Guid($this->toString()); > $g-> doSomething(); > break; > } > } > } > > /** > * HERE is where you start seeing a real benefit... > */ > function processGuid1(GuidUnion $guid) { > $guid->doSomething(); > } > function processGuid2(GuidUnion $guid) { > $guid->doSomething(); > } > function processGuid3(GuidUnion $guid) { > $guid->doSomething(); > } > > > > I think (or I hope so at least) we’re at least both clear what the other is > > talking about now. > > Hopefully, with that last point clarified, yes. > > Thanks again. > > -Mike
It seems like what you're describing here is more user-customizable autoboxing than anything to do with union types. Viz, since a Guid has a natural and round-trippable string representation, you want to be able to ask for a Guid, be given a string, and then work with it as a Guid either way. For that, it seems like you'd want more of a fromString() method (magic or interface): class Guid implements FromStringInterface { public static function fromString(string $s) { if (is_valid_guid($s)) { return new static($s); } throw new \TypeError(); } } function needGuid(Guid $g) { $g->doGuidThings(); } needGuid('a9d05a5f-e643-441e-8784-cfd613072072'); Whether or not something like that is wise I don't know, but it seems like it would resolve the use case you describe better than fiddling with union types. Or am I totally misunderstanding you as well? :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php