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.
>>> 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.
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?
>> 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.
>>>>> 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.
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.
>>> 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.
>>>>> 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 ;-)
>>>> 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.
>> 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
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
