Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86989
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Aaron Piotrowski'" <aaron@icicle.io>,
	"'Sara Golemon'" <pollita@php.net>
Cc: <pthreads@pthreads.org>,
	<internals@lists.php.net>
References: <1413875212.2624.3.camel@localhost.localdomain> <CAF+90c_RhEYvFrQ7Vs+2eSsLR+_rf8D_3W6Ao0M_e5iC6iPqFA@mail.gmail.com> <CAESVnVquViA2SHErqPih-aqFjBVQqcO+wazhczL77wWShEWHBA@mail.gmail.com> <CAL=_i_=wHtnHwCMzktcMU=yuyvUtogBAEDjNNCusXTbjHCBoyQ@mail.gmail.com> <CAESVnVqUK3oU8EhmJ5=81dh62jhKqLiy26FbZ=oU+nA5_TtGBg@mail.gmail.com> <5873FC04-0579-41A6-86BD-9755A57CFED5@icicle.io>
In-Reply-To: <5873FC04-0579-41A6-86BD-9755A57CFED5@icicle.io>
Date: Wed, 1 Jul 2015 21:25:27 +0200
Message-ID: <065901d0b433$b1ef5bd0$15ce1370$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQIdUSgNhz0pVAfMCRF9s8KVcENA9wNeeANiA0B8gS4CUqx+rwG7uZtvAtEdeCacwc2LcA==
Content-Language: en-us
Subject: RE: [PHP-DEV] [RFC] UString
From: anatol.php@belski.net ("Anatol Belski")

Hi,

> -----Original Message-----
> From: Aaron Piotrowski [mailto:aaron@icicle.io]
> Sent: Wednesday, July 1, 2015 9:00 PM
> To: Sara Golemon
> Cc: pthreads@pthreads.org; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] UString
> 
> 
> > On Jul 1, 2015, at 1:06 PM, Sara Golemon <pollita@php.net> wrote:
> >
> > On Tue, Jun 30, 2015 at 10:36 PM, Joe Watkins <pthreads@pthreads.org>
> wrote:
> >> Another possible issue is engine integration:
> >>
> >>    $string = (UString) $someString;
> >>    $string = (UString) "someString";
> >>
> > That sounds as a cool idea to discuss as a completely separate,
> > unrelated RFC, and not specific to UString.
> >
> > e.g.   $obj = (ClassName)$arg;   /* turns into */ $obj = new
ClassName($arg);
> >
> > So you could use casting with any class which supports single-argument
> > constructors.
> >
> > But again, orthogonal to this RFC.
> >
> > -Sara
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > visit: http://www.php.net/unsub.php
> >
> 
> Expanding on this idea, a separate RFC could propose a magic
__cast($value)
> static method that would be called for code like below:
> 
> $obj = (ClassName) $scalarOrObject; // Invokes
> ClassName::__cast($scalarOrObject);
> 
> This would allow UString to implement casting a string to a UString and
allow
> users to implement such behavior with their own classes.
> 
> However, I would not implement such casting syntax for UString only. Being
able
> to write $ustring = (UString) $string; without the ability to do so for
other classes
> would be unusual and confusing in my opinion. If an RFC adding such
behavior
> was implemented, UString could be updated to support casting.
> 
> Obviously a UString should be able to be cast to a scalar string using
(string)
> $ustring. If performance is a concern, UString::__toString() should cache
the
> result so multiple casts to the same object are quick.
> 
One way doing this is already there thanks
https://wiki.php.net/rfc/operator_overloading_gmp . Consider

$n = gmp_init(42); var_dump($n, (int)$n);

However the other way round - could be done on case by case basis, IMHO.
Where it could make sense for class vs scalar, casting class to class is a
quite unpredictable thing.

While users could implement it, how is it handled with arbitrary objects?
How would it map properties, would those classes need to implement the same
interface, et cetera? We're not in C at this point, where we would just
force a block of memory to be interpreted as we want.

Regards

Anatol