Quoting Marcus Boerger <[EMAIL PROTECTED]>: > In fact it may be related. As i said before it is one of the ways to get to > a class. >
The class is related to the object. The method is related to the class. Is the method related to the object? It is not. There are many indirect ways to get to a class. I'll try to illustrate with an example. Say that we introduce a new semantic rule that says you can call methods on arrays. The behavior is to scan through the array for any object on which it can call that method. i.e. $array = array($object1, $object2, ...); $array->method(); /* Calls method on all objects in array. */ Could that be useful to coders? Yes. Is it a good language element? I would argue no because the array is not directly related to the method. Quoting Hartmut Holzgraefe <[EMAIL PROTECTED]>: > So why? as i stated before the only difference between static and > non-static member functions is that non-static members *may* change > the state of an instance while static members definetly won't > > From a callers point of view it is not even important to know > that one is calling a static member when invoking the member > function over an object instance, so why shouldn't it be callable > like that? > With non-static methods, you KNOW that the object is required in order for the method call to be valid. Thus the statement $object->nonStaticMethod() includes all of the information required for execution and no more. I agree that it's logically safe to continue with the current semantics, but it introduces a few maintenance headaches. When reading through code, it helps to be able to know exactly what is being affected without having to refer to any documentation or code. I agree that reading documentation is important, but if it's not necessary, then it shouldn't need to be done. Consider the case where an object needs to be altered/removed from a solution for one reason or another. Each place where a static method call is made from that object has to be examined (i.e. refer to documentation). Depending on the project, the number of these could be very large, whereas simply indicating the class directly would alleviate that extra work. It adds virtually no extra work for the original coder, since they are probably familiar with the objects they are manipulating. This is similar to the excessive use of global variables. I've had to maintain software where the original author thought it best to use global variables as function parameters. Doing so relates the parameter to the whole of the global scope. This makes code maintenance a huge pain. Had the minimal relation been used, this coder simply would have added a few more parameters to that function's parameter list. Granted, that's much more of a pain than the static methods, but the idea is similar. So I guess my message is minimalism. I am completely in favor of a $className::... syntax. It is consistent with the $object->$elementName and $functionName() syntaxes which I consider to be very strong points for PHP. Also, if the $object->staticMethod() scheme is to persist, for the sake of consistency, it would be nice to see $object->staticMember and $object->CONSTANT This is kind of part of my argument against $object->staticMethod() because I imagine those would also create some headaches. Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
