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.
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.
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.
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 ;)
I really don't see why typed variables would make implementing
anything easier or the result better. And IMHO a data structure class
(hashmap, map, list, etc) would be far more useful if it could contain
any type of variable rather than having to have a different subclass
for each type. Or are you thinking PHP should also support
templates?!!
nope I'm not suggesting templates/generics (yet lol); nah not at all
especially when a type could be passed through the construct; and
completely agree it is useful to have classes that contain any kind of
variable, and sometimes it's needed to make that subclass which can only
accept a certain type.
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
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 ;)
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!
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.
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)
*/
?>
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)..
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 :)
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
