Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:8044
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <1077428654.403841ae69a2f@webmail.purdue.edu>
Date: Sun, 22 Feb 2004 00:44:14 -0500
To: internals@lists.php.net
References: <1077090830.30573.1.camel@coogle.localdomain> <pan.2004.02.20.23.56.17.725796@uol.com.br> <EAC53018-6414-11D8-B087-000393030CE6@bellsouth.net> <200402212010.53919.zhundiak@comcast.net> <1077427838.40383e7e58b76@webmail.purdue.edu>
In-Reply-To: <1077427838.40383e7e58b76@webmail.purdue.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2-cvs
Subject: Re: [PHP-DEV] Re: Static weirdness..
From: fuhs@purdue.edu (Josh Fuhs)

Sorry, mis-click.

Quoting Josh Fuhs <fuhs@purdue.edu>:

> If I'm not mistaken, Java does not allow calls to static methods via object
> instances. It simply doesn't make sense to couple the unecessary object
> instance
> into a method call in which it has absolutely no bearing.
> 
> If the object has nothing to do with the operation, then there's no point for
> it
> to be in the syntax. I am completely in favor of a 
> 
> $stringName::staticMethod();
> 
> type call if this hasn't already been done.
> 

Continuing on...

Consider the following piece of code:

class Foo{
    /* It is possible to register something with an instance. */
    function register($param){
        ....
    }

    /* It is possible to register something with the class. */
    static method register2($param){

    }
}

/* Assume the class definition is separate from this. */

$instance = new Foo();

/* Hmm, the code reads register something, but I can't really be sure of 
   the meaning without referring to the documentation. */
$instance->register2($param);

When reading OO (or arguably any) source, one should be able to describe what is
happening simply by looking. A method describes what it is doing by its name. If
a class method name makes sense for an object, a point of confusion arises for
someone who is maintaining the code.

C++, though powerful, can hardly be considered the authority on OO behavior.
Multiple inheritance and a few other features that it incorporates have not been
accepted into the mainstream OOPLs for a reason.

Like multiple inheritance, static method invocation via an object instance
should be considered a bad practice.

Josh

> Quoting Art Hundiak <zhundiak@comcast.net>:
> 
> > On Friday 20 February 2004 20:23, Herr Witten wrote:
> > > Well, calling a static method from an instance breaks down the logic.
> > > If it is static, then the instance has absolutely no bearing when
> > > calling it. Therefore, it logically makes sense to call only from the
> > > class name.
> > >
> > > Moreover, making a distinction between the method calling syntax begins
> > > to make the distinction between class objects and instance objects. I
> > > have a class which deals directly with classes and their static methods
> > > as if they are objects. This is a powerful notion that still needs more
> > > support in the Zend engine.
> > >
> > > The call for static method should be:
> > >
> > > ClassName->method();
> > >
> > > Herr Witten
> > >
> > > > C++ allows $a->bar() when bar() is a static method (yes, it is called
> > > > in a static context there too).
> > > >
> > > > IMO, there should be no error, warning or notice here.
> > 
> > Regardless of the final implementation, I think access to static methods
> and
> > 
> > static class variables should be consistent.  Currently, you cannot access
> a
> > 
> > class variable via an object instance.
> > 
> > And for what it's worth, I see no reason why static methods cannot be
> called
> > 
> > from objects.  Follow Java/C++ in this case.
> > 
> > -- 
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>