Re: Re: Opinions / Votes Needed

Jochem Maas wrote:

Nathan Rixham schreef:

Tony Marston wrote:

"Nathan Rixham" <nrixham@gmail.com> wrote in message

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. Here's an example:

If you really *need* to used a staticly typed language then don't use PHP, and don't try to change PHP to match your needs.

why not? php fills 95% of my needs in most instances, I'm as much a valid user of php as you and php *could* change to fit my needs and others, not without some appreciated work mind you, but it could (and without affecting anybody else in this case) it's a simple need: if I can type that my variable can only contain an int, then I know it's always an int without tonnes of checks to check it actually contains an int / is getting set with an int throughout the rest of the app (especially when multiple dev's are working on it).

there are other ways of tackling this, but the biggest problem is handling the case when such a placeholder has something other than the given type stuffed into it ... typehint currently give a fatal error, not condusive to elegant error handling.

a catchable fatal error which is the key here, and thats what you'd want when statically typing; very condusive to elegantly handling using exceptions :) further.. it's only going to be developers who get the error (hopefully) whilst developing, so all you're doing is making sure both yourself and other people use you're code correctly. on something you said earlier about public properties.. currently I'll use getters and setters most of the time (with type hinting) like you occassionally do and see the need for; purely to make sure that my SomeClass property can't be a string(3) or something. Adding in this static typing of class properties would save you miles of code since: class Example { public bool $someflag; } would function identically to the current: class Example { public $someflag; public function getSomeflag() {

    return $this->someflag;

} public function setSomeflag(bool $val) {

    $this->someflag = $val;

} } I know you can't use primatives in a type hint currently but this example perfectly illustrates how it'd both save you code, and let you use public variables properly without worry. (i hope?)

additionally this functionality would open the door to the creation of a lot more apps and frameworks, not least the ability to create decent ORM's. Further, it would allow people to contribute proper developers classes that can be re-used time and time again (for instance a full set of collections [class, hashmap, map, list, set etc etc]). Once they're made and open source we all benefit, not only that but they could be made by users instead of the internals team ;)

gotta say that I think array() covers hashmap, map and list pretty well :-P

agreed (nobodies knocking php here, I'm here on the php lists asking for features as "I heart php", not over on the java forums asking for opinions on adding a tonne of php functionality and simplicity they miss ;-)) - now yeah it covers it great, till you want you're array to only contain instances of your User class then you've got to build a lot of code around it to ensure this, likewise if you want you're array to only have max 10 items in it, or only indexed / only associative, more.. but that's enough.

b: Object superclass A base class type which all objects automagically extend, with (if nothing else) a unique id / hashcode for each object (much like the Java Object class). Failing this some form of function to get a unique reference string for any variable. Example

Why should each class automaticaly extend a base class? For what purpose? For what benefit? I can achieve what I want without this *feature*, so I don't need it.

2 reasons: 1: it would allow all objects to have this uniqueid/hashcode i need

okay ... why do you need it. I don't grok the use personally but I'd like to hear your use case.

same reason one needs spl_object_hash - however coupled with 2 it seems the ideal implementation + every object is an object so why not make every class with a superclass of "Object"? it would also give a place for future functionality common to call objects to be added and why not?

2: it would allow one to type hint Object in methods (you currently can't) - you can method(array $var) but not method(object $var) see:

try this snippet on for size: function test(stdClass $o) { var_dump($o); } $o = (object)1; test($o);

ahh.. you miss the point, request: "I want to type hint that my function can accept objects of any type, but not primatives/array"

<?php class Example { public function someMethod(object $arg0) { } } $e = new Example(); $e->someMethod( (object)'y' ); ?> returns: Catchable fatal error: Argument 1 passed to Example::someMethod() must be an instance of object

here in lies a big problem, it would involve a *major* change to the way php works because you effectively would have to have the engine start throwing exceptions ... that's unprecendented and will most definitely break BC. not too mention there is a general stance AFAICT in internals that forcing people to use exceptions is a no-no.

dude that's existing code runs on any php 5.x+; thats the error thrown already by php.. try it and see.. point is that it *should*? work.. certainly function someMethod(array $arg0) works, as does any class in there.. but no way of simply saying you want it to be an object of any kind.

Why does each object need a unique id/hashcode? I have been using objects for years without this so it is not necessary, and does not provide any additional functionality.

for comparison of equality, so you can make indexed arrays quickly using the hashcode (you know like a hash table) so you can quickly tell the difference between two instances of the same object with the same values that are infact different, makes persisting data a 100 times easier...

Why do you need a unique reference string for each variable? WTF!

well because $a = 's'; $b = 's'; both are unique, internally php must hold a reference of some sort to each variable and where it's stored that is entirely unique; it would simply be a case of exposing this functionality /or/ adding functionality based on this.

why do you need this at the userland level?

why should we not have it at userland level? but answer is see above and more specifically for persistance and orm needs :) cheers for the reply again jochem - lovin the feedback