Re: Re: Opinions / Votes Needed

Stuart wrote:

2009/1/17 Nathan Rixham <nrixham@gmail.com>:

Stuart wrote:

2009/1/17 Nathan Rixham <nrixham@gmail.com>:

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)

You may think it's a simple need but it has consequences for all users of PHP. You may be able to implement typed variables while still allowing untyped, but it will impact performance at the very least, probably more.

hmm.. debatable on this one TBH, as the method signature (infact everywhere you can use static) is already getting tokenized for public static function etc so I'd assume that if a type token wasn't included then the internal code to do with it would be bypassed in any implementation; thus no performance hit at all - this is me assuming though only the internal dev's could say one way or the other for sure.

But you've added an extra piece of information to every zval floating around the system - what type it is, if any. Huge amounts of code would need to be changed to check that value and deal with it in an appropriate way. Not a huge performance hit per variable but repeated across a large CMS or framework the effect could be pretty huge. I don't even pretend to know enough about the internals of PHP to determine stuff like that, but I've been coding long enough to recognise that everything code does takes time so the less you can have it do the better.

*dunno* might ask the internals..

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

I would argue that what you have is a want based on your current implementation strategy, rather than a "need". I've never come across any situation where static types would make my code more secure. If your code can't control what you're putting into variables then you have bigger problems than the 5% of your "needs" PHP doesn't meet.

won't make code more secure to the outside world, but it will ensure all developers using my code use it correctly; I can currently control it using PHP however it's v complex to do correctly throughout an application compared to having static types.

Then your functions/methods should be checking their inputs in the same way you check the inputs from users. I recall a function I wrote a while ago which allowed the first line of each function and method did something like this... check_args(func_get_args(), 'error', 'int', 'string:30', 'int:5-100', 'bool'); First argument is the array of arguments.

nice, seen similar for validating forms;

Second it what the function should do in the case of an incorrect argument - in this case to trigger a user error. Other options here were 'warning', 'notice', 'email:user@domain.com' and true. Most of those should be self-explanatory, and if true is passed then an error message is returned. The rest of the arguments should be one per function argument stating what's allowed. The options here were numerous and I can't remember them all, but you get the idea. This single function made validating arguments for any function or method a doddle and extremely flexible. Could your static types validate the length of a string or ensure an integer it within a range?

yeah to some extent; but also would be more like calling a series of setters each one validating it's input on set so.. <?php class MaybeThisIsSlightlyMoreNameSpaceFriendlyEh { private int $a; private string $b; private string $c; private bool $d; public function __construct(int $a, string $b, string $c, bool $d) {

    $this->setProperties( $a, $b, $c, $d );

} public function setProperties(int $a, string $b, string $c, bool $d) {

    setA($a);
    setB($b);
    setC($c);
    setD($d);

} ... public function getB() {

    return $this->b;

} public function setB(string $b) {

    if( strlen($b) !== 30 ) {
    	throw Exception('with some message and code or whatever');
    }
    $this->b = $b;

} ... } ?> then you're validating at setter level and using the setters in the construct / sure you follow.. incidently, if you can see the benefits of this you'll probably see the how method overloading would be needed.. should be a no arg construct in there too by rights; otherwise you can't instantiate without having all vals, either that or you default all to null which you don't want in all cases.

Any data coming from the user would need the same amount of validation regardless of whether you were stuffing it into untyped or typed variables. IMHO the same goes for any uncontrolled inputs to isolated code regardless of whether it's expected to be reused or not.

from the user yup.. but this is about development and developers.

See my answer above - IMHO there's no difference since when you're writing code for other developers to use they are your users and should be treated as stupid and/or malicious, just like your website users.

i try to think of them like that but they don't like it; specially the other seniors (not to mention those on this list) <lol>

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

Really don't see why this is necessary. Please elaborate on why you want this?

said to jochem before, same reasons spl_object_hash was created etc etc / orms, persitance etc

IMHO an ORM should be wrapping scalar values in objects but that's probably just me.

exactly! I agree completely, this is half the point, static types would allow one to make Classes for each of the scalar/primative types and have them automatically converted to there db specific value by the orm; extra: would open up the door for having an magic method __cast on all objects so you could cast (String)'a string' - where String is the object wrapper for scalar string :)

Again I can't claim to know how PHP manages zvals so I can't be authoratitive as to how feasible it is to expose an internal ID for the storage a variable points to, but if it's readily available I wouldn't object to a function being added to get to it.

there's a thread on spl_object_id on internals covering this, may already be implemented and in cvs i dunno..

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:

<snip code> I mean no offence, but personally I think this is wanted by "lazy" programmers. It's *you* calling the function so *you* should know what you're giving it. Equally the function should validate what it's been given if it's possible it might not get what it's expecting or it will be used by idiots.

or by people working with lazy programmers.. it's *them* calling *my* functions; a function should (and in my case will) validate whats been given to it, but hell this is why we already have type hinting isn't it ;)

I already responded to the developer to developer argument above.

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

If you need this functionality why not create a member variable in the constructor containing sha1(microtime(true)). However, exposing PHP's internal ID is unlikely to cause BC issues so might be worth requesting on the internals list. It's possible there's already a way to get it, we just don't know about it.

spl_hash_id currently (but only objects.. i think) and yeah I already have my own class "Object" with hashid's and it's most useful - but then I use one of you're objects that doesn't have this and well problems arise.. if this was on every object then we'd all have a nice global single way of getting a unique id for an object.. so your app would work with mine, and mine with yours - and oh that nice open source orm would work with all our existing php classes without us rewriting them!

An admirable goal, and as I said above if it's simple and has no nasty side-effects I have no problem with such a function being added.

nice to hear :)

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?

PHP does not need method overloading as is found in other languages as it has optional parameters with defaults. It is also possible to cast each parameter into wahetever type is necessary. It achieves the same result but using a different method.

the same functionality can be achieved, however not without a lot of additional code to test variable types using conditional blocks with lots of is_ and instanceof comparisons; adding method overloading is by no means needed but would majorly simplify the code of scripts which need this functionality.

You can't have both method overloading and variable argument lists - they're just not compatible. You can simulate overloading by putting the common code into a private method and having several differently named public methods that all use the private method. Alternatively you can use variable arguments to get around it. Either way I definitely prefer support for variable and undefined arguments than overloading.

fair enough and a very good argument! strong enough for me to say yeah drop the idea (unless both where possible and an internal dev confirmed this), as I mentioned it's one I can live without and already code around - in addition to the method you mentioned there's always: <?php error_reporting(E_ALL | E_STRICT); class Base { public function method( $a, $b ) { return __METHOD__ . '(' . $a . ',' . $b . ')' . PHP_EOL; } public static function staticMethod( $a, $b ) { return __METHOD__ . '(' . $a . ',' . $b . ')' . PHP_EOL; } } class Extender extends Base { public function method( $a ) { if( func_num_args() == 2) {

     $a = func_get_arg(0);
     $b = func_get_arg(1);
     return parent::method( $a , $b );

} return __METHOD__ . '(' . $a . ')' . PHP_EOL; } public static function staticMethod( $a ) { if( func_num_args() == 2) {

     $a = func_get_arg(0);
     $b = func_get_arg(1);
     return parent::staticMethod( $a , $b );

} return __METHOD__ . '(' . $a . ')' . PHP_EOL; } } $test = new Extender(); echo $test->method(4); echo $test->method(4,5); echo Extender::staticMethod(4); echo Extender::staticMethod(4,5); /* returns: Extender::method(4) Base::method(4,5) Extender::staticMethod(4) Base::staticMethod(4,5) */ ?>

If you really have classes with those names you need namespaces more than most ;-)

only in test code :P also addressed this higher up

Absolute rubbish! You have obviously been used to a different language and have recently moved to PHP, but cannot get used to the fact that it *IS* a different language, therefore it has different syntax and achieves similar things in different ways. If your feeble brain can't handle the differences then I suggest you stick with your previous language and LEAVE PHP ALONE!

actually I've been a senior php dev for 5 years and muddled along trying to help people out on this list for a long time too - it is my primary language, PHP always changes and the beauty of the language is that it tries to allow people to program the way they want, hence it being both procedural and object orientated, obviously there's a need for this otherwise Type Hinting would never have been introduced.

Type hinting is the happy medium between untyped and strongly typed variables.

yup-ish, could do with that type hinting on vars, properties and return types too (infact if you had it on vars and properties you could forget return types theoretically, wouldn't be quite as contracted but the functional need would be covered)..

Something just occurred to me... what would you want the engine to do if a type was not correct at runtime? Throw an exception? Raise a fatal error? Or just a notice? Personally I prefer to be in full control of what occurs when something unexpected happens.

same as it currently is for Type Hints on methods, catchable fatal error. and you would be in control, catch it.

Also, PHP is procedural with OO capabilities due to its history and the engine developers commitment to maintaining backwards compatibility whenever possible.

fine job they do with bc as well :)

Indeed they do. Most of the time ;-)

PHP could easily be a one for all language and AFAIK the only major functionality missing is static typing..? I'm not trying to knock PHP, simply expand it's functionality and scope by having additional *optional* functionality implemented - like namespaces, if you don't like 'em don't use 'em.

Namespaces have a distinct and discrete advantage for all PHP users... they will allow code to insure against naming clashes. All IMHO - PHP FTW!! -Stuart

yeah!! cheers stut

No problem - love discussions like this. -Stuart

good good, me too!