static keyword ambiguity

[andr3a]

Hello guys, nice to meet You in this forum :)

Yesterday I opened a bug but it seems to be a bogus.
I think one link:
http://bugs.php.net/bug.php?id=40886
should be better than every other comment about the problem.

Please tell me what do you think about that, thank you.

[Shrike]

Having read your posts on the bug site, I can't really see what your issue is.

Using a static method from a class instance results in a warning being generated - indicating the PHP engine thought something was not quite right. If you code to E_STRICT you'll get this warning, which resolves any ambiguity there might be.

PHP is not C++ :)

[Piranha]

I think that you should read the part of the instructions that is inside the paranthesis in the part of the documentation you submitted.

But I wonder why you ask this questions on these forums when you have already gotten an answer from the PHP developers.

[Shrike]

Hmm, actually I am mistaken - a warning is only generated if a non-static method is used statically. This is indeed a bit odd, but also useful.

error_reporting( E_STRICT );
class Example
{
public function instancemethod()
{}
public static function staticmethod()
{}
}
Example::instancemethod(); // E_STRICT Warning
Example::staticmethod(); // Ok
$e = new Example();
$e->staticmethod(); // Ok

[dream.scape]

I agree that it is inconsistent, but it is stated in the documentation, so it's a bit of a stretch to call it a "bug" even if you think the behavior should be different.

You'll find that the PHP language is choked full of inconsistencies. Part of the goal of PHP 6 is to improve in this department, so who knows, maybe they will change it for PHP 6.

[andr3a]

I agree that it is inconsistent, but it is stated in the documentation, so it's a bit of a stretch to call it a "bug" even if you think the behavior should be different.
the problem is that I jumped paranthesis comment (I know, it was my error)



You'll find that the PHP language is choked full of inconsistencies.
I agree, but I can't understand why a keyword as static shouldn't be implemented correctly!



Part of the goal of PHP 6 is to improve in this department, so who knows, maybe they will change it for PHP 6.
I hope so and thank You for your reply.


I wonder why you ask this questions on these forums when you have already gotten an answer from the PHP developers.
because I think that's an horrible answer. static is inconsistent and not useful and make code excecution slower ... I wrote here because they call them a feature but any other OO program language has a feature like that, that's why I hoped You'll help me to solve this problem :)

Regards

[andr3a]

I wrote a "response report" about this problem, part 1 (http://webreflection.blogspot.com/2007/03/php-5-developers-teach-us-what-does.html) and part two (http://webreflection.blogspot.com/2007/03/php-5-static-keyword-feature-part-2.html), with examples in different program languages.

I definitively think this isn't callable as feature, this is just a logic bug, wrote on documentation ... or not.

Regards.

[Shrike]

Interestingly, the same behaviours appear in Java.

class Test
{
public static void main( String[] args )
{
//Test.InstanceThing(); // non-static method InstanceThing() cannot be referenced from a static context

Test.StaticThing( "Called static method from static context" ); // OK

Test t = new Test();
t.InstanceThing( "Called instance method from instance context" ); // OK
t.StaticThing( "Called static method from instance context" ); // OK
}
public void InstanceThing( String msg )
{
System.out.println( msg );
}
public static void StaticThing( String msg )
{
System.out.println( msg );
}
}
C:\javatest>java Test
Called static method from static context
Called instance method from instance context
Called static method from instance context

Given that alot of PHP 5 is modelled on concepts in Java I find this behaviour less suprising now. I do think the response you got from the PHP developers was less than inspiring though. Although they are hardly likely to admit 'Yeah we copied Java' :D

I'll put this up on your blog post.

A bit more from Sun

Note: You can also refer to static methods with an object reference like

instanceName.methodName(args)

but this is discouraged because it does not make it clear that they are class methods.

http://java.sun.com/docs/books/tutorial/java/javaOO/classvars.html

[andr3a]

As I wrote on my Blog, Java should have the same behaviour .. but

1 - 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. ;)

2 - Java supports method overloads, so Java can do what I was trying to do


Finally, I totally agree with You:
Although they are hardly likely to admit 'Yeah we copied Java'
but in 2006, copy Java without Java OO Power, is a nonsense, do You agree? :)

Since PHP doesn't support method "pure" overload, they copied Java style but they forget that it's not a good practice on Java too and with Java You can simply overload a method ... so, they implement static keyword incorrectly but they call them a feature, it's totally hilarious, imho.

Thank You for posting both here and on my blog :)

[Shrike]

Correct me if I'm, wrong but method overloading in Java is done with the parameter list rather than access modifiers:

class Test
{
public static void foo()
{}
public void foo()
{}
}
C:\javatest>javac test.java
test.java:5: foo() is already defined in Test
public void foo()
^

I think the root of the problem is PHP doesn't support true overloading rather than any issue with the static keyword.

Since PHP is weakly typed it's not possible to provide true overloading across the board. This is an issue which has been pushed back and forth since before PHP 5 was released.

Do you think it would be more sensible for the PHP developers to have made static methods only ever acessible from a static context? This would go against the grain of Java (and presumably other languages).

I don't know, it's a tough decision :)

[andr3a]

Correct me if I'm, wrong but method overloading in Java is done with the parameter list rather than access modifiers
exactly ... this is the point.

PHP, as Python, JavaScript, AS1 and many other scripting languages, doesn't support "pure" overload, just support "fake" overload, based on arguments.

As You say, with Java, as C# and C++, You can change method behaviour using overload.

With PHP 5 the static keyword block totally method overloads, so You can use the same name to do different things, one for class static public method and one for every instance method.

This is the example, showed on part 2 of my blog

class StaticString{
private $str;
public final function __construct($str){
$this->str = $str;
}

/* try to change instance method (runtime override) ... */
public final function __call($method, $values){
switch($method) {
case 'write':
$this->str .= ' from instance';
StaticString::write($this);
break;
}
}
public function getString(){
return $this->str;
}

public static function write(StaticString $what){
echo $what->getString(), '<br />';
}

/* overload is not possible with PHP 5
public function write(){
echo $this->str;
} */
}

$ss = new StaticString("Hello World!");
StaticString::write($ss);
$ss->write(); // Catchable fatal error:
// Argument 1 passed to StaticString::write() must be an instance of StaticString
// none given (hey PHP, I didn't call static class method !)

The problem is that with static keyword You loose method control and you can't absolutely modify its behaviour.

The only way to use fake overload is forget static keyword.
class StaticString{
private $str;
public final function __construct($str){
$this->str = $str;
}
public function getString(){
return $this->str;
}
public function write($what = null){
if(func_num_args())
echo $what->getString(), '<br />';
else {
$this->str .= ' from instance';
StaticString::write($this);
}
}
}

$ss = new StaticString("Hello World!");
StaticString::write($ss); // E_STRICT notice
$ss->write(); // everything is ok ... but E_STRICT notice again

That's only a simple example ... now consider that with static keyword I can't create, for example, a class String using both public static methods and instances methods

JS example

var str = String.concat("a", "b", "c");
var obj = new String("a");
str = obj.concat("b", "c");

obj var uses this reference inside its concat method ... this is a stupid, but I hope perfect, example of PHP 5 static keyword limit!

[Shrike]

Although they are hardly likely to admit 'Yeah we copied Java'
but in 2006, copy Java without Java OO Power, is a nonsense, do You agree? :)

This again is a tough decision. We can't forget how PHP started and why it has become so pervasive. A quote from the bug referenced at the top of this post sums it up well:

If you are wanting absolutely "perfect" OO, there are plenty of other languages that will provide exactly the straightjacket and punishment you desire. If you want to code efficient, easy to maintain, working programs, use PHP.

With the power of Java comes a greater degree of complexity. Adding such a degree of complexity might effectively remove PHP from the arena which made it so popular in the first place.

[andr3a]

This again is a tough decision. We can't forget how PHP started and why it has become so pervasive. A quote from the bug referenced at the top of this post sums it up well ...
Ok but this static implementation is, in this way, a limit, not a feature ... after my last post, do You agree?



With the power of Java comes a greater degree of complexity. Adding such a degree of complexity might effectively remove PHP from the arena which made it so popular in the first place.
Ok, I agree with You, but if they add more complexity introducing static keyword, why did they add them in an absolutely restrictive, nonsense, way?

This is a bug, a logic bug or a wrong implementation ... so, it's a bug, IMHO.

[Shrike]

I'm still not sure I agree it is a bug. It's hard to compare PHP to Javascript, since Javascript allows you to define and redefine functions, and also have instance and static methods with the same name. PHP (and FWIW Java) do not allow you these things.

Is it a feature or a limitation? Both I suppose, depending on what you are trying to do :)

I can't really comment on Python and Actionscript, but AS relying on a bug is somewhat interesting ;)

[andr3a]

I'm still not sure I agree it is a bug. It's hard to compare PHP to Javascript, since Javascript allows you to define and redefine functions, and also have instance and static methods with the same name. PHP (and FWIW Java) do not allow you these things.
Is this so hard to imagine ?
class String {

private $str = '';

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

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

public final function concat() {
$args = func_get_args();
return new String((isset($this)?$this:'').implode('', $args));
}
}

$str = String::concat("a", "b", "c");
$sts = new String("a");
echo '<pre>';
var_dump(array(
$str,
$sts,
''.$str,
''.$sts,
'$str === $str->concat("b", "c") ?',
''.$str === ''.$sts->concat("b", "c")
));
exit('</pre>');
Works perfectly! ... ooops, I forget the E_STRICT notice ... so if E_STRICT is a good feature, it should shut up because this code isn't replicable with static keyword feature ...

Are You sure, now, static implementation is a bug or a limit and not a feature with PHP 5?

And this is only an example .... now think about a class called File

echo File::getContent("test.txt");

$test = new File("test.txt");
echo $test->getContent();

it's soo much simple to do, impossible to apply respecting E_STRICT and using static keyword ... what a feature!

[ahundiak]

A singleton pattern will usually do what you want with minimal extra effort.

$content = File::getInstance()->getContent('test.txt');

[andr3a]

A singleton pattern will usually do what you want with minimal extra effort.

$content = File::getInstance()->getContent('test.txt');
Who spoke about Singleton pattern?
Did You understand what's the problem with static?

However, PHP 5 singleton pattern is something like ...

$content = File::getInstance()->getInstance()-> getInstance()->getInstance()->getInstance()-> getInstance()->getInstance()->getContent('test.txt')

... that's PHP 5 feature! (without overload possibility for instances)

"New" PHP 5 supports a storic Java ambiguity with static methods inherited ... feature! ... without Java possibility, again.

[ahundiak]

Wow. Did we get up on the wrong side of the rock this morning?

Yes I understand the issues with static. Not sure I would call most of them problems. The way to work around the issues is to not use statics in the first place.

And please read up on the difference between overloading and statics. Very different concepts no matter how many times you insist otherwise.

[andr3a]

Wow. Did we get up on the wrong side of the rock this morning?
not this morning, about from 3 days (the day I opened the bogus that blocked my classes development)


Yes I understand the issues with static. Not sure I would call most of them problems. The way to work around the issues is to not use statics in the first place.

I said them ... and this way doesn't respect E_STRICT and I develop PHP (both 4 and 5) everytime with maximum error_reporting level, to solve future problems/compatibility.


And please read up on the difference between overloading and statics. Very different concepts no matter how many times you insist otherwise.
If You read up my posts about this problem, You'll see that I'm talking exaclty about missing PHP overload and, with static keyword, missing instance overload possibility blocking that method for each instance (any instance can use them in a different way using $this reference).

There's anything wrong on my knowledge about overloading and C#, Java and C++ examples should tell you better than any post.

Your answer (how should be a Singleton that isn't File example class goal) is, in my opinion, totally Off Topic.

[crux_op]

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:


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


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.


Is this so hard to imagine ?
class String {

private $str = '';

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

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

public final function concat() {
$args = func_get_args();
return new String((isset($this)?$this:'').implode('', $args));
}
}

$str = String::concat("a", "b", "c");
$sts = new String("a");
echo '<pre>';
var_dump(array(
$str,
$sts,
''.$str,
''.$sts,
'$str === $str->concat("b", "c") ?',
''.$str === ''.$sts->concat("b", "c")
));
exit('</pre>');
Works perfectly! ... ooops, I forget the E_STRICT notice ... so if E_STRICT is a good feature, it should shut up because this code isn't replicable with static keyword feature ...

Are You sure, now, static implementation is a bug or a limit and not a feature with PHP 5?

And this is only an example .... now think about a class called File

echo File::getContent("test.txt");

$test = new File("test.txt");
echo $test->getContent();

it's soo much simple to do, impossible to apply respecting E_STRICT and using static keyword ... what a feature!


It's mind boggling why you would want a concat function to do two different things when it is called from an object instance, and when it is called statically.

Functions should have one clear function, and that function shouldn't change based on the calling context!

In your example I could legitimately do something like this:

echo String::concat("b", "c"); // returns bc
$sts = new String("a");
echo $sts.concat("b", "c"); // returns abc

Now it boggles my mind, why I would want to do that. Shouldn't concat return the same thing if I give it the same parameters? Ofcourse it should!

And in PHP with E_STRICT it throws you a helpful notice (not fatal error) so you can rethink your design along proper OO lines.

Then after many long and terrible hours of reasoning, you'll simply start using your function statically and calling it like this.

echo String::concat($sts, "b", "c"); // returns abc

Anytime you think you're FORCED to use a static call from instance object, then you should stop, sit back, and re-think your design. Ask yourself? Do I really need to expose this functionality in this place without knowing what type of object this is?

If the answer is yes... then write a new non-static function to delegate the call to the static reference.

i.e.


class MyObject
{

public function A()
{
return "something that's really really really needs this objects internal data to resolve";
}

public function callB()
{
return self::B();
}

public static function B()
{
return "Something that all objects of this type are capable of doing and only depends on the parameters";
}
}

$foo = new MyObject;

echo $foo->A();
echo $foo->callB();

$i_am_lazy = "return ".get_class($foo)."::B();";
echo eval($i_am_lazy);



Or you can use get_class to fudge your way into knowing the class name.

In either case... if you want to call a method (and you want to really call this method), then that means:

a) You know this method exists on this object
Which implies
b) You know which class this object belongs to
and
c) You know the parameters the method accepts, the expected return value and.... if the method is declared as static or not

Since you know all that... why not just make the static call?

[Weedpacket]

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]

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]

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]

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?

PHP doesn't support pure overloadBecause 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 [i]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.

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]

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 thatclass 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. :D

[crux_op]

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.

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]

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.


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]

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


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.



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]

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]

Java can do what I would do with PHP tooAnd 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]

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 :D

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

[Weedpacket]

Ah, found it. Knew it was around here somewhere.

http://www.phpbuilder.com/annotate/message.php3?id=1016118

And now some people are whinging that PHP isn't OO [i]enough[i] - marvellous!