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.
>
> 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
>>> 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.
> 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);
> <?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.
>> 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?
>
>>> 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.
>
>> 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.
>
> 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.
>
>>
>> That's just my opinion, of course.
>>
>
> and really thanks! gives me the chance to explain a bit more :p
>
> ps: feeble lol
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
