Stuart wrote:
2009/1/17 Nathan Rixham <nrixham@xxxxxxxxx>:
Stuart wrote:
2009/1/17 Nathan Rixham <nrixham@xxxxxxxxx>:
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)
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@xxxxxxxxxx' 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!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
