# Really Need..

- Thread: https://externals.io/message/42677
- Original archive: https://news-web.php.net/php.internals/42677
- Started by Nathan Rixham on 2009-01-17T17:06:38+00:00
- Messages: 8
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #42677 — Nathan Rixham — 2009-01-17T17:06:38+00:00

URL: https://externals.io/message/42677#42677

Afternoon all,

Recently I've been running in to a lot of frustrations with PHP, don't 
get me wrong I love the language, but I just can't do what I *need* to 
in a few situations, specifically when dealing with Classes and Objects.

I strongly feel that these need added in to PHP 6, for multiple reasons 
which I'd be happy to elaborate on.

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.

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.

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.

I can't stress enough what a vast difference the implementation of these 
three features would make to php, even above many of those currently 
rfc'd (imo), infact I'd put them on par with the need for namespaces, 
and additionally they'd compliment namespaces perfectly.

Is there any way to get the ball moving with any of the above? (if I was 
a c dev I'd do it myself.. infact even considered learning c just for 
this task)

Regards, Nathan

---

## #42684 — Lukas Kahwe Smith — 2009-01-18T16:42:05+00:00

URL: https://externals.io/message/42677#42684 · In reply to: #42677

> 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.

> 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).

> 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?

>
regards,
Lukas

---

## #42685 — Nathan Rixham — 2009-01-18T17:05:49+00:00

URL: https://externals.io/message/42677#42685 · In reply to: #42684

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:
> 
> 
> 
> > […]
> 
> 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.

> > […]
> 
> 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)


> > […]
> 
> 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.

---

## #42686 — Hannes Magnusson — 2009-01-18T19:31:09+00:00

URL: https://externals.io/message/42677#42686 · In reply to: #42684

>
> 
>
> > […]
>
> 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

It doesn't throw E_FATAL. It throws `E_RECOVERABLE_ERROR` which doesn't
do anything.

bjori@jessica:~$ cat t.php
<?php
function err() {
    return true;
}
set_error_handler("err", E_RECOVERABLE_ERROR);

function bar(array $array) {
    foreach($array as $k => $v) {
        printf("%s - %s\n", $k, $v);
    }
}

bar("hello world");

bjori@jessica:~$ php t.php

Warning: Invalid argument supplied for foreach() in /home/bjori/t.php on line 8


Totally not what you expected, heh?

-Hannes

---

## #42687 — Nathan Rixham — 2009-01-18T21:39:27+00:00

URL: https://externals.io/message/42677#42687 · In reply to: #42686

Hannes Magnusson wrote:
> 
> > […]
> 
> It doesn't throw E_FATAL. It throws `E_RECOVERABLE_ERROR` which doesn't
> do anything.
> 

 `E_RECOVERABLE_ERROR` seems appropriate IMHO

I've reworded my original mail completely maybe this one will have more 
feedback (or not)

question: Would anybody else like to see, or feel the need for, 
*optional* type hinting of variables and class properties in PHP?

examples (all optional, and syntax may differ):

class Example {
   private TypeHint $var;
}

Example $var = new Example();

in addition the ability to type hint primatives/scalars/[type object] in 
the existing implementation:

function(bool $flag) {
}

function(object $flag) {
}


This would all be under the assumption and proviso that an 
implementation would not break bc, have any markable perfomance hit, or 
in any other way effect existing applications or new applications that 
did not use the functionality (in the same way the existing type hinting 
implementation doesn't)

internals: can anybody confirm if this would even be possible and if so 
what the "cost" would be?

regards, thanks / apologies where needed etc.

Nathan

---

## #42688 — Robin Burchell — 2009-01-18T22:30:23+00:00

URL: https://externals.io/message/42677#42688 · In reply to: #42687

> I've reworded my original mail completely maybe this one will have more
> feedback (or not)
>
> question: Would anybody else like to see, or feel the need for, *optional*
> type hinting of variables and class properties in PHP?
>

I was involved on a thread on exactly this some weeks earlier. I (and
a few others, though I don't really remember specifics) would very
much appreciate the possibilities of proper code structure when
working with large teams that this could help provide :)

(As to your original proposal, multiple method signatures is something
I've come across a need for *occasionally*, though personally, I'm not
a big fan of the feature -- the one place I would like having it is
__construct().

Say, you've got an ORM class which is derived for usage:

class ORM
{
   public function __construct(string $sPK)
   {
        // Fetch and populate based on PK
   }
}

class Person extends ORM
{
   public function __construct(int $iID)
   {
        // Fetch and populate based on PK
        parent::__construct((string)$iID);
   }

   public function __construct(string $sNewName, string $sAddress)
   {
        parent::__insert(....);
   }
}

Yes, I realise that this can be done with retrieving arguments and the
like, but for such purposes it's not the neatest solution
syntactically.)

---

## #42689 — Nathan Rixham — 2009-01-18T22:44:07+00:00

URL: https://externals.io/message/42677#42689 · In reply to: #42688

Robin Burchell wrote:
> 
> > […]
> 
> I was involved on a thread on exactly this some weeks earlier. I (and
> a few others, though I don't really remember specifics) would very
> much appreciate the possibilities of proper code structure when
> working with large teams that this could help provide :)

it was a thread "q on primatives" i think.. guess who started it *ducks*

> 
> (As to your original proposal, multiple method signatures is something
> I've come across a need for *occasionally*, though personally, I'm not
> a big fan of the feature -- the one place I would like having it is
> __construct().

noted; found the same thing, another specific being that all classes 
have a default no arg constructor so it can be instantiated prior to 
calling the setters even if there's a constructor which demands params.

> Say, you've got an ORM class which is derived for usage:

[snip]
very interesting that you give an ORM example; this is exactly the area 
where I've found the need for this class property type hinting (and on 
web services tbh) - but still, mapping a "private bool $flag" to a 
tinyint(1) is so much easier than mapping a "private $flag" to it 
(complications multiplied somewhat with other data types)

> Yes, I realise that this can be done with retrieving arguments and the
> like, but for such purposes it's not the neatest solution
> syntactically.)

agreed any possible implementation in php feels like more of an 
inefficiant hack tbh (perhaps a bit strong..)?

cheers!

---

## #42692 — Hannes Magnusson — 2009-01-19T08:10:48+00:00

URL: https://externals.io/message/42677#42692 · In reply to: #42688

> 
> > […]

Since you obviously could not care less about our time and you would
like to waste our precious spare time on things that have been
discussed to death rather then actually improving the language, I'll
mention it one more time.

Variables and class properties will NOT be "type hinted" until PHP
version ~21.2.0.

And because you are disrespecting everyone on this list, by not doing
your homework, everything you have to say from here on now will
probably be ignored because we all will remember you as "the guy who
is to important to read the archives".


> (As to your original proposal, multiple method signatures is something
> I've come across a need for *occasionally*, though personally, I'm not
> a big fan of the feature -- the one place I would like having it is
> __construct().

I believe you know the basics of PHP. Knowing the basics of PHP you
should be able to imagine that this cannot work in PHP, ever. Not even
in PHP 21.2.0.
No matter how much you want it.


Unfortunately I would like scalar type hinting, but everytime you guys
drag scalar type hinting into the mud with features you very well know
will never happen, and don't read the archives, you are just hurting
the scalar type hinting team.

Thanks for absolutely killing it.

-Hannes