Hi,
after reading this mail: Is it just me or is a userspace implementation
really that trivial?
function ensure($object, $class) {
if ($object instanceof $class) {
return $object;
}
throw new InvalidArgumentException(sprintf('Object is not of type %s',
$class));
}
And then instead of all a new syntax
$myObject = ensure($another->foobar, MyType::class); // [1]
Did I miss something.
Regards,
Sebastian
[1] There was another RFC that suggested this special property.
2012/8/15 Nikita Popov <nikita....@gmail.com>
> On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig <kris.cr...@gmail.com> wrote:
> > On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara <ircmax...@gmail.com
> >wrote:
> >
> >> Stan,
> >>
> >> On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass <sv_for...@fmethod.com>
> wrote:
> >>
> >> > Hi!
> >> >>
> >> >> I agree with you. The one case where this syntax may be very useful
> is
> >> if
> >> >>> we want to implement class casting. So introduce a pair of magic
> >> methods
> >> >>>
> >> >>
> >> >> I do not think we want to implement class casting. I'm not sure how
> >> >> class casting even makes sense - if the object is of one class, how
> can
> >> >> you just make it into another class by casting? If you mean "casting"
> >> >> actually returns another object of different class, then just make a
> >> >> method for that that returns that object, I do not see how obscuring
> the
> >> >> purpose of this operation with unobvious syntax would help.
> >> >>
> >> >
> >> > The discussion is starting to drift very far from my original
> proposal.
> >> >
> >> > Instead of trying to guess what I mean, can't people just refer to my
> >> very
> >> > simple definitive proposed behavior?
> >> >
> >>
> >> My point was that what I posted was the only way that I can see for the
> >> original proposal to be useful.
> >>
> >> Anthony
> >>
> >
> > Though I'm clearly in the minority on this, I for one think this proposal
> > does have more merit than is being argued. There seems to be general
> > agreement all around that this would provide a benefit as it pertains to
> > code readability-- Not just by humans, but theoretically by doc/etc
> parsers
> > as well.
> >
> > This is where we get into arbitrary, subjective territory. To me, that
> > benefit in and of itself is sufficient to warrant this feature. To many
> of
> > you, it is not enough.
> >
> > The tie-breaker for me is the fact that, though the benefits are modest,
> > there's really no noticeable cost, either. The argument seems to,
> > essentially, break down as follows: "This feature isn't worth our time."
> > .... "Yes, it is!" .... "No, it isn't."
>
> Every feature has a cost, even if that cost is just maintaining the
> code. Doing language changes for minority use cases, which already
> have sensible solutions, doesn't make much sense.
>
> Another aspect here is that there is no reasonable syntax for this
> feature, at least I can't think of one:
>
> * The syntax `$foo = (InterfaceName) $container->service` is
> completely out of question. It looks like a cast, but wouldn't
> actually do a cast.
> * Same is to be said about `InterfaceName $foo =
> $container->service`. This syntax implies that the $foo variable will
> always be of type InterfaceName, even if it is later reassigned. It's
> not a sensible syntax for a one time validation
> * The other three syntaxes that were mentioned were just as unclear.
> E.g. `$foo = $container->service as InterfaceName` again looks like a
> strange cast syntax and `$foo = $container->service is InterfaceName`
> looks like the assignment should evaluate to a boolean (i.e. `is` is
> some kind of `instanceof`).
>
> On the other hand, the current ways of accomplishing the same goal are
> well-established and easy to understand:
>
> * Using a docblock: /** @var $foo IntefaceName **/
> * Using an assertion: assert($foo instanceof InterfaceName).
>
> I think that the assertion is a rather concise and clear way to do
> this. It is much more obvious than some new and obscure `$foo =
> (InterfaceName $container->service)` syntax.
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
