Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62217
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
Sender: sebastian.krebs.berlin@gmail.com
In-Reply-To: <CAF+90c_srmS-VTJFHk30r-17F_n=jV0xNpbm85neEyRJ4nBjiQ@mail.gmail.com>
References: <A3182DBB9506422D9DCD5667BE48A0C4@pc>
	<CAFMT4NpOEFgDckOUdSx5x8h=H0a6FPubmyyPyvz-SMgxKgyhdw@mail.gmail.com>
	<CAAyV7nE-QTvXju3JayAaeLY1iDtUzWo6j+b66him11dzKAUKsw@mail.gmail.com>
	<502A86AA.2030203@sugarcrm.com>
	<E7BA2752DEBB42BF99C96CAECFBB2C80@pc>
	<CAAyV7nHVRZo8XCw77boMAxXtjrFxDGrCQPDAStpLSW5sA-6L5g@mail.gmail.com>
	<CAKOpQSyyMRAKMHi4QV55g8ddnwOojnTDSgGtbedOvfp4vw-tFw@mail.gmail.com>
	<CAF+90c_srmS-VTJFHk30r-17F_n=jV0xNpbm85neEyRJ4nBjiQ@mail.gmail.com>
Date: Thu, 16 Aug 2012 09:36:49 +0200
Message-ID: <CALtuQzAysN1R4wm2Mmniipu8cPedRJdB3tS2OzSLZYAHvBAc+w@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b34395839195204c75d1bed
Subject: Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
From: krebs.seb@gmail.com (Sebastian Krebs)

--047d7b34395839195204c75d1bed
Content-Type: text/plain; charset=ISO-8859-1

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.ppv@gmail.com>

> On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig <kris.craig@gmail.com> wrote:
> > On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara <ircmaxell@gmail.com
> >wrote:
> >
> >> Stan,
> >>
> >> On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass <sv_forums@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
>
>

--047d7b34395839195204c75d1bed--