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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
