static keyword ambiguity

[Weedpacket]

crux_op wrote:

Using static variables/methods from with nonstatic calls....

Frankly it seems like a horrible practice from a strict OO perspective, and from the point of view of anyone who wants to write maintainable programs.

Even the java developers agree with this:

Quote:
Note: You can also refer to static methods with an object reference....
but this is discouraged because it does not make it clear that they are class methods.
http://java.sun.com/docs/books/tutor...classvars.html

That clarifies what's been bothering me about all this (I didn't say anything because unlike you I probably wouldn't have made much sense).

What didn't help was the OP's claims that the static methods were somehow being "inherited" by the instance, as if there was some sort of magic rewriting going on behind the scenes which somehow literally turned a static method into an instance method just because the latter's syntax ($objectname->staticmethod() instead of classname::staticmethod()) was used.

I was thinking, "well, obviously the method isn't going to be written with any access to $this or its methods or properties, only class ones, otherwise it couldn't be a static method itself, and it's certainly not going to create any just 'cos that's how it was called, so given that $objectname is an instanceof classname, of course if $objectname->staticmethod() were to mean anything at all it would be the same as classname::staticmethod(). It's a bit creepy, but the intention is unambiguous since it's not like PHP can have two different functions with the same name (hence the existence of self:: and the necessity of $this->). So what's the issue?"

[andr3a]

crux_op wrote:

Using static variables/methods from with nonstatic calls....

Frankly it seems like a horrible practice from a strict OO perspective, and from the point of view of anyone who wants to write maintainable programs.

Even the java developers agree with this:

http://java.sun.com/docs/books/tutor...classvars.html

You seem to think of Java as the Gold Standard so why are you complaining that PHP implemented the static key word in the way the Java developers wanted to originally? It would seem to me they only allowed object references to static methods as a kludge, a way to defray criticism, and allow lazy designers or programmers inexperienced in OO to jump into OO without having to learn the object structure of the programs they are using.

Please read one more time the problem ... it seems that You didn't understand what is the problem so I've no time to explain You OOP ... and what I would like to do is perfectly writable with Java, C++ and C# respecting correctly (at least better) OOP concepts.
Regards.

[andr3a]

Weedpacket wrote:

the intention is unambiguous since it's not like PHP can have two different functions with the same name

PHP supports override, the problem is that a generic top level static function will "block" totally its method name, for its instances as for every extended class and it's horrible with or without PHP.

Java can overload a method, PHP doesn't support pure overload. My bogus is obvious even for Java developers ... only PHP developers seems to don't understand what is the problem (and an asnswer like "if You're looking for pure OO Language don't use PHP" could only confirm my opinion).

As I wrote on Zend too, I hope PHP 6 will not has these problems.

[Weedpacket]

andr3a wrote:

a generic top level static function will "block" totally its method name, for its instances as for every extended class

If by that you mean that if class1 define a static method "foo" and class2 extends class1, class2 can't define an instance method named "foo", my question is ... so? It's not like there's an international name shortage. What's the desperate need for them to have the same name?

andr3a wrote:

PHP doesn't support pure overload

Because PHP is not strongly typed; it would be impossible to determine until the method is called which one was intended. It's not even enough to just count the number of arguments, because method with a signature listing n parameters can take n+m[/m] for m>=0. You could argue that if there is a method that has n+m+1 parameters should take priority over one that has only n, but the former would shadow the latter and limit the number of arguments passable to it (i.e., the method would change its behaviour for no apparent reason as the number of arguments increases) and besides, if it were necessary in the first place, both methods could be written as one with internal logic to decide the cases.

andr3a wrote:

I hope PHP 6 will not has these problems.

I submit that you're the one having problems.🙂 A good cure for that would be if you didn't use PHP.

[andr3a]

Weedpacket wrote:

I submit that you're the one having problems.🙂 A good cure for that would be if you didn't use PHP.

I've any problem, I remove E_STRICT or I change program language (I think is not a good thing that a certified Zend Engineer shows a logic error and everyone tell Him that error doesn't exist ... if you can't see them, I suppose you probably need to study better OO concepts).

Finally (this problem exists and this 3D is becomming quite boring) the reason only I have this problem is that you haven't good fantasy, imho.

Even a PHP developer tells me that this is a PHP limit and to solve them I should change language choosing one more (pure) Object Oriented (but do you like Joke Oriented language or do you like to code locally?) .

Regards and please mark this 3D as solved, I'll never come back to explain one more time what is the problem and why that is a problem, bye.

[andr3a]

sorry guys, locally => logically 😉

[Weedpacket]

I guess you just aren't very good at explaining your problem (what does "3D" mean, anyway? Don't worry, you can mark it resolved yourself.).

As far as I can make out, your claim is that the fact that

class A
{
	public static function foo(){}
}

class B extends A
{
	public function foo(){}
}

is illegal in PHP is somehow the crime of the century. (I think that's what you're saying the problem is.)

Seeing as I've never had cause to even contemplate doing this (not being aware of any "principle of OO programming" that would make it necessary), I'm certainly finding no cause to lose sleep over it. Personally I'd recommend you oughtn't either. But that's just me looking to get the last word in. 😃

[crux_op]

andr3a wrote:

PHP supports override, the problem is that a generic top level static function will "block" totally its method name, for its instances as for every extended class and it's horrible with or without PHP.

PHP is not java. Overloading is only really required if you are static typed. I.e. you need to have two functions just to do this:

int public MyFunct(int) { return 0; }
double public MyFunct(double) { return 0.0; }

In PHP you can simply have
public function(value) { return 0 }

And the language will take care of type casting for you.

In any case.... why do you want to override a superclasses static function and make it nonstatic? You're breaking consistency.

In any case... you can have operator overloading in PHP, so what if it isn't "pure". So what if the syntax is slight bit more convoluted? It's possible.

andr3a wrote:

Please read one more time the problem ... it seems that You didn't understand what is the problem so I've no time to explain You OOP ... and what I would like to do is perfectly writable with Java, C++ and C# respecting correctly (at least better) OOP concepts.
Regards.

Here's where we agree:

A languages support ( or non support ) of functionality under the heading OOP does not imply that is the right way.

Here's where we disagree:

You choose C++, C# as the standards. They're not. They weren't designed with OO in mind.

You added Java. As I said... the java developers say mix-matching static/nonstatic method calls is a bad idea.

---

Why should you call a method from an incorrect context? It breaks logical consistency. In PHP it doesn't cause a failure, but it does cause a notice. Just notice... telling you, the programmer, that something inconsistent is going on.

I don't rightly think I can convince you that you're wrong, but at least I can convince everyone else to think a bit deeper about this.... and when they do, they should write programs that are consistent.

[laserlight]

I think is not a good thing that a certified Zend Engineer shows a logic error and everyone tell Him that error doesn't exist ... if you can't see them, I suppose you probably need to study better OO concepts

Yeah, they need to raise the bar on the Zend Certified Engineer exam to ensure that ZCEs have a stronger grasp of what is OO and what is just syntactic sugar (or lack thereof) :p

[Weedpacket]

I was just reading through the C# 3.0 specification and came across §26.2

Extension Methods
Extension methods are static methods that can be invoked using instance method syntax.

Before showing how to specify such a beast (prepend a modifier "this" to the first parameter of the method, a la the convention in Perl, Python, and C of passing the object the method applies to as it first parameter) and how it works to call them (tries to find an instance method, and when it fails to do so, rummages around in all the static classes in the currently-imported namespaces for a suitable extension method), there is a note:

Note: Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible.

The emphasis and colouring are Microsoft's.

Ooh .... "3D"=>"thread". Nothing to do with three-dimensionality, and not short for "Data Display Debugger". Perfectly obvious. If only everyone could be as clear and precise in their writing. Then there wouldn't be all this confusion.

[crux_op]

Is that what it meant? My eyes glossed over when I read the sentence it was in. I couldn't figure out what it was... but since it was combined with the word "boring", I figured it couldn't be anything important.

[Weedpacket]

I just came back days later and discovered that my subconscious had been working on it in the meantime as though it hadn't anything better to do.

[andr3a]

My bad english doesn't allow me to explain perfectly what is the problem, this is absolutely true.

Last post about that:

class Mouse{
public static function mickey(){}
}

now:
1 - mickey is a Mouse static public method, not an instance public method. This is not OO and out of logic. Java developers know that and they suggest to don't use static classes methods as instances ones, beacuse this is too much ambiguous.

2 - if mickey is inherited by each instance, if mickey correctly cannot be overrided extending Mouse class, mickey is blocked, I can't use them as static inherited instance method because it's a non-sense (so why it should be there on each instance?).

3 - since second point is true, there's no way to "change" or use in a different way that method with an instance, not Mouse class (any explicit overload possibility, any runtime instance method override using __call)

These 3 points are correct only if I set E_STRICT, because with other levels there's any problem using static in a different way, one for the reason it was written, one for each instance, using simply dynamic overload (if(isSet($this)) ... I am an instance, not a class with a static public method)

If you can't understand, I'll study english to explain better ... but I suppose that now someone will speak one more time about PHP that's not Java, C#, C++ ... etc.

this is boring, PHP has implemented a static limit.
Do you never use a static method with an instance using the same name with different behaviour dedicated for one instance?
You haven't a good fantasy, imho, and you follow these wrong OOP implementations.
Wrong, because these haven't a sense and because other languages can overload simply a method, static or not, changing parameters, using them differently with instances or classes without problems.

It seems obvious only for me, Java developers, C# developers, C++ developers and many other programming language developers, but probably they read a better manual than "OO for dummies", or maybe every other developer that doesn't use PHP don't know OOP as you know it and so you're really lucky if PHP is so much perfectly Object Oriented!

Regards.

[Piranha]

andr3a wrote:

1 - mickey is a Mouse static public method, not an instance public method. This is not OO and out of logic. Java developers know that and they suggest to don't use static classes methods as instances ones, beacuse this is too much ambiguous.

Read that again. You say that Java developers know, not that Java does not allow it. In other words, this point have nothing to do with the programming language, it have to do with the developers.

andr3a wrote:

It seems obvious only for me, Java developers, C# developers, C++ developers and many other programming language developers, but probably they read a better manual than "OO for dummies", or maybe every other developer that doesn't use PHP don't know OOP as you know it and so you're really lucky if PHP is so much perfectly Object Oriented!

This attitude will certainley get PHP developers to change.

But I have to say one thing. I hate that PHP doesn't have overloading and strong typeing, it makes it so much harder to do some things.

[laserlight]

Do you never use a static method with an instance using the same name with different behaviour dedicated for one instance?

What do you mean?

You haven't a good fantasy, imho, and you follow these wrong OOP implementations.
Wrong, because these haven't a sense and because other languages can overload simply a method, static or not, changing parameters, using them differently with instances or classes without problems.

You need to structure your argument more coherently. Stating that "these haven't a sense" is not convincing at all, and it is not clear whether overloading is better than dynamic typing.

It seems obvious only for me, Java developers, C# developers, C++ developers and many other programming language developers, but probably they read a better manual than "OO for dummies"

Please be reminded that you are not the only one here with experience in programming languages other than PHP, and that the same applies to the PHP developers.

[andr3a]

laserlight wrote:

What do you mean?

I mean something like:

class File {

private	$file;

public function __construct($file){
	$this->file = $file;
}

public static function exists($file) {
	return file_exists((string)$file);
}

/* not implementable with PHP,
implementable with "every" other language */
public function exists() {
	return file_exists($this->file);
}

public function __toString(){
	return $this->file;
}
}


if(File::exists("mickey.txt"))
	// do stuff

$file = new File("mickey.txt");
if($file->exists())
	// do stuff

Horrible, uh? And this is only a typo

laserlight wrote:

You need to structure your argument more coherently. Stating that "these haven't a sense" is not convincing at all, and it is not clear whether overloading is better than dynamic typing.

in this case, dynamic typing is blocked by static keyword.
"Magic dynamic" disappear, bye bye dynamic if You use static.
__call ? doesn't work because instances inherits a static class method!
So in this case PHP is stronger than Java, C#, C++, JavaScript ... etc.

laserlight wrote:

Please be reminded that you are not the only one here with experience in programming languages other than PHP, and that the same applies to the PHP developers.

I know it but seems that anyone can see where and what is the problem while I've stopped from different days my FileSystem namespace PHP 5 development trying to solving this ambiguity or, in my opinion, this static implementation limit (bug)

[andr3a]

Piranha wrote:

Read that again. You say that Java developers know, not that Java does not allow it. In other words, this point have nothing to do with the programming language, it have to do with the developers.

As I've just said different times, Java can do what I would do with PHP too.

Call them as You prefer but I think that limit word is perfectly and "often" a scripting language, as is PHP, shouldn't be more limited than strongly typed languages ... but probably this is just another personal, wrong, opinion.

[laserlight]

in this case, dynamic typing is blocked by static keyword.

It does not look like that is the case in your code snippet, more like there is no function overloading. Your claim of "implementable with "every" other language" is false, since there are programming languages other than PHP which do not have function overloading in general (Python is an example, if I remember correctly).

Function overloading has little to do with OOP, anyway. It is a kind of ad-hoc polymorphism, not polymorphism via inheritance.

[Weedpacket]

andr3a wrote:

Java can do what I would do with PHP too

And as we've said often: so what?

Here's a bit of experience. If you've used enough languages of different types you'll realise that they're all arbitrary constructs (and they all suck). None of them have any meaning beyond themselves. Getting bent out of shape because one language doesn't meet some personal predilection of yours or because it's not identical to some other language is ... quixotic, to put it mildly.

If you're that determined to see PHP supporting what it is you reckon it should support, you're free to download the source code and modify it.

[andr3a]

Weedpacket wrote:

If you're that determined to see PHP supporting what it is you reckon it should support, you're free to download the source code and modify it.

I just downloaded last PHP 5 csv ... while I was looking for static implementation, they released another CSV version 😃

The problem is that I hope some php developer will read about this problem, here or in Zend forum (more than 100 visitors, any PHP developer?) because I don't want to fix manually each release with other fixes this "personal problem".

As last point, my disappointment is that I've always do, with PHP, things that I could do with other programming languages, but this time I've not found any solution to this bogus and if core will not change, for E_STRICT or for static methods inheritance, I have to change my FileSystem schema ... and after different time spent to think about that, it's quite an horrible solution, imho.

Regards