Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42685
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.21 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=PAUUAQdAGcJ+BS2EUIaoZ7CaHg4sfX21r9sYno+iVXA7fUaY4SQd/t91A+ASAjZiuF
         Ef+r/qtFPIeHncs4QrpyZIBb4SFD0/BlR9MM/PERDAcnWMz+sic4o+CR99sgPE7d9IFL
         Fguo9MPi/n4Enfg7wEsGE3UUrSnHnFZfiFik0=
Message-ID: <4973616D.8040903@gmail.com>
Date: Sun, 18 Jan 2009 17:05:49 +0000
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: internals@lists.php.net
References: <58.5A.41390.72012794@pb1.pair.com> <AF3C29BB-6653-42EE-BFC7-19D0E93A77B4@pooteeweet.org>
In-Reply-To: <AF3C29BB-6653-42EE-BFC7-19D0E93A77B4@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Really Need..
From: nrixham@gmail.com (Nathan Rixham)

first off; had a rather in-depth (but lacking when it comes to internal 
input) over on the general list; has been interesting.

Lukas Kahwe Smith wrote:
> 
> On 17.01.2009, at 18:06, Nathan Rixham wrote:
> 
>> a: Optional Static Typing
>> I'm finding an ever increasingly need to be able to staticly type 
>> properties, parameters, return types etc (in classes) I know there is 
>> type hinting but it's just not enough to do what one needs. 
>> Additionally support for staticly typing primatives.
> 
> I am not a type hinting fan .. then again I think that PPP is mostly 
> bogus for a scripting language as well. I would not mind this stuff if 
> it would just all just throw E_STRICT's instead of E_FATAL. To me the 
> point of a glue language is to keep running until the engine is about to 
> explode or the request has finished.

After talking this one out (and negating which E_ is thrown) I've come 
to the conclusion that optional type hinting in the following places 
would suffice:

class Example {
private TypeHint $var;

...

Example $var = new Example();

...

and finally primative/scalar type hinting in all of these places.

>> b: Object superclass
>> A base class type which all objects automagically extend, with (if 
>> nothing else) a unique id / hashcode for each object. Failing this 
>> some form of function to get a unique reference string for any variable.
> 
> I think this is quite pointless. I do not see any need for magic here. 
> No need to be able to magically redefine the base class and saving the 
> few chars to type is also not sensible (and this will not give you MI 
> through the backdoor either).

I'd be tempted to agree; however while you can currently TypeHint in php 
as such:

public function whatever(array $someArray)
and
public function whatever(SomeClass $obj)

*you can't*
public function whatever(object $obj)

which seems rather strange, some people are of the belief/misconception 
that stdClass is the superclass of all objects but it just isn't; all in 
it means that one can't specify (typehint) that a method param should 
simply be an object - seems strange and hopefully the internals will 
concider adding this functionality at the very least.

In the above scenario of you adding this functionality I ask you would 
the logical and appropriate approach be to perhaps make stdClass or some 
other class the super of all objects, and if this was the case surely 
adding in the functionality implemented in spl_object_hash or the 
discussed spl_object_id may be appropriate.

(reasons why not would be great) - or would the approach be to allow the 
aforementioned public function whatever(object $obj)


>> c: Method overloading
>> TBH it's something I could live without, whereas a/b aren't, but it 
>> would be an ideal addition to php; Many times I've had to work around 
>> the lack of this functionality with (what could be) unneeded code.
> 
> You mean polymorphism? I hope we will never see that in PHP. This kind 
> of magic is dangerous and just forces PHP even more into a static typed 
> corner. Maybe you need to whip up a patch for your PHP version that 
> makes PHP statically typed?
> 

fair enough; stut also raised the point that it makes no sence to 
implement this when you can have variable argument lists.

re patch: would love to, considering it, 7 years since I touched c - 
otherwise this is the approach I'd be taking! may still yet.

additional:
a magic method __cast may be beneficial to allow users to create there 
own primative/scalar wrappers and convert from primative to wrapper and 
back.. thoughts?

cheers for the input lukas.