Jochem Maas wrote:
Nathan Rixham schreef:
Tony Marston wrote:
"Nathan Rixham" <nrixham@xxxxxxxxx> 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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
