Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46651
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.78.25 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Uv43RjCkROMmz2FVOgj+O3jX3UxLRW4Hi/BN1fs2lFaJGMMbgyqk72hGFgaFejnJae
         3wM2OOqLQvet4wrRdtWDb/1Rsn18W85484+atW8UoOvplq7iEieCLql5yACHXZhLUe+v
         clNY6MDKz4DCg8a3XUb+kZ9e86JlX5CdY1ANM=
MIME-Version: 1.0
In-Reply-To: <3A.94.26332.3E9EB4B4@pb1.pair.com>
References: <BF.85.26332.88E6B4B4@pb1.pair.com>
	 <e666c3891001111729n7294ef23la55b02272044662e@mail.gmail.com>
	 <3A.94.26332.3E9EB4B4@pb1.pair.com>
Date: Mon, 11 Jan 2010 19:32:08 -0800
Message-ID: <c25f8d341001111932o3a0f28e8w27985700c6684454@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] __toString(), __toArray()
From: 0xcafefeed@gmail.com (mm w)

cast is not needed in PHP

i 'd rather be more interesting in

class Obj {
     function __catch($data, $type) {
            //$type [ static_method, method, get_property, set_property]
            if (observed &&  $type =3D=3D set_property && somevalueIsObserv=
ed) {
                  $observer->notify("somevalue::valueWillChanged");
                  $this->somevalue =3D $data['somevalue'];
                  $observer->notify("somevalue::valueDidChanged");
            } else {
                  continue__call();
            }
     }
}

On Mon, Jan 11, 2010 at 7:17 PM, Clint Priest <cpriest@warpmail.net> wrote:
>
> Etienne Kneuss wrote:
>>
>> Hello,
>>
>> On Mon, Jan 11, 2010 at 7:31 PM, Clint Priest <cpriest@warpmail.net>
>> wrote:
>>>
>>> I know there's been requests to add a __toArray() and most of the
>>> arguments
>>> against it is that there are too many magic functions already. =C2=A0I =
just
>>> thought I'd propose an alternative that would satisfy all of them.
>>>
>>> Why not a __cast($Type) magic function?
>>
>> I'd advance two reasons against this idea:
>>
>> 1) It's more self-explanatory to explicitly call the appropriate
>> converting method, enough with implicit madness!
>>
>> 2) For some operations, you'd have to know the types in advance before
>> knowing what operations needs to be performed:
>>
>> $obj1 + 2;
>>
>> Now what __cast should be called? Int? Float?
>
> Wouldn't it make sense to be an integer since its being added to an integ=
er?
>
>>
>> Also, what about $obj1 + $obj2: Int? Float? Array?
>
> This is where operator over-loading would be useful however perhaps only
> explicit casts would make sense here.
>
>>
>> Another example: str_replace($obj1, "bar", "foo"); what to call?
>> __toString or __toArray? str_replace accepts both.
>
> This is an interesting situation, could be resolved by attempting a
> __cast('array') followed by a __cast('string') if the first call was
> rejected (false, exception or something).
>
>>
>> IMHO it would only make sense to invoke methods on explicit casts
>> only, otherwise it will just be a mess with PHP's current type
>> juggling. But, as we seen with __toString, limiting the field of
>> application was annoying (and it was later extended to nearly all
>> string usages).
>
> I would agree with this as well, only called during explicit casts.
>
>>
>> So, what will it be? Inconsistent and Confusing or Limited and Annoying?
>>
>
> One other alternative, probably not as easy would be to pass multiple typ=
es
> to cast, much the way the Accepts: HTTP header does, providing a list of
> possible cast types, in the preferred order.
>
> One could even implement an interface such as:
>
> interface Castable {
> =C2=A0 function GetCastableTypes();
> }
>
> or some such.
>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>>
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>