Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62193
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
MIME-Version: 1.0
Sender: sebastian.krebs.berlin@gmail.com
In-Reply-To: <CAEKFTWWizHi4JGUgOvTSXVCE4e7R3ooKnXo0NRgPc8pFCij3MA@mail.gmail.com>
References: <CAEKFTWWmER9FKsCW=3SzhZb16Gno-Xrd=zSSgQuPWStw_sSFeQ@mail.gmail.com>
	<CAKxcST80H8vWOe3-nvDfc74EC6E6WgS2K24nYbNnWJMTQozd3A@mail.gmail.com>
	<CANVTSm6sjF9SwjROv8Y5jR=K8CFEivzfOS9d7yGdF9qwqs6aqg@mail.gmail.com>
	<CAEKFTWWizHi4JGUgOvTSXVCE4e7R3ooKnXo0NRgPc8pFCij3MA@mail.gmail.com>
Date: Wed, 15 Aug 2012 15:54:47 +0200
Message-ID: <CALtuQzDr-goh1gzz7Cx6vXwDgY0+_sx39nz+OfJG2orp40rFYw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b603a781582cb04c74e4513
Subject: Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
From: krebs.seb@gmail.com (Sebastian Krebs)

--047d7b603a781582cb04c74e4513
Content-Type: text/plain; charset=ISO-8859-1

2012/8/15 Giedrius Dubinskas <d.giedrius@gmail.com>

> On Wed, Aug 15, 2012 at 2:19 PM, Yahav Gindi Bar <g.b.yahav@gmail.com>
> wrote:
> > On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis <dragoonis@gmail.com>
> wrote:
> >>
> >> Comments inline.
> >>
> >> On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
> >> <d.giedrius@gmail.com> wrote:
> >> > Hello Internals!
> >> >
> >> > I'm just on and off luker here but thought I'll throw in an idea for a
> >> > feature I'd love to see in PHP: aliasing static methods.
> >> >
> >> > Syntax would look something like this:
> >> >
> >> >   use Namespaced\SomeClass::staticMethod;
> >> >   use Some\Foo::bar as fooBar;
> >> >
> >> >   staticMethod(); // would call Namespaced\SomeClass::staticMethod()
> >>
> >> Then you're confusing the reader, they think you're calling a
> >> function, but you're actually calling a class method. Confusion++
>
> Static method essentially is a function (with elevated access to
> containing class) so I don't see much of a problem here.
>

Don't know, how much I heard this, but: This is wrong! A function is a
standalone construct, without _any_ sideeffects, which means, that it will
always return the same result, when you give it the same input. I know,
that this is not completely true (see rand(), file related functions, or
functions build on top of (ugh...) globals), but thats not the point here.
Static methods have a well defined context and state: The class they are
defined in. This especially means, that they are explictly allowed to have
side effects (depending on the classes state).


>
> >>
> >> >   fooBar(); // would call Some\Foo::bar()
> >>
> >> What if a function called staticMethod() already exists, there'd be a
> >> bunch of confusion on referring to the right one.
>
> Aliased static method would be translated during compilation and no
> additional resolution rules would be required. If one would try to
> define a function with same name in same file as alias, that would
> result in fatal error just like with class aliases:
>
>   use Foo::bar as fooBar();
>
>   function fooBar() {} // Fatal error: Cannot redeclare ...
>
> >>
> >> >
> >> > This would make code more readable, by removing the the noise of
> >> > repetition of class names. For use cases we can look at Java use cases
> >> > for "import static".
> >>
> >> When you find a function call, you'd have to scroll up to the top of
> >> the page to see if it's actually a method alias. In this case being
> >> explicit is a good thing, no scrolling, no confusion.
>
> As of now when we see ``fooBar()`` we already have no idea where that
> ``fooBar`` declaration is. It may be declared in same namespace in
> some other file, in global namespace in some other file or built in
> function. I don't think that explicit alias in same file adds much
> confusion to what we already have.
>

Thats wrong: "fooBar" is either in the current, or in the global namespace,
thats all. It's extremely easy to find out, wether or not a function is
built-in or not (hint: Manual ;)). If it's a custom function, ok, then you
usually have to look at it, but I don't see, how this is a reason to make
it even more worse by adding the possibility, that it can be a method too.


>
> >> >
> >> > Aliasing class constants like that would also be very nice.
> >> >
> >> > What does everyone think?
> >> > Would it be possible in PHP?
> >> >
> >> > --
> >> > Giedrius Dubinskas
> >>
> >> Not that I don't welcome your suggestions, I encourage them, but for
> >> this paritcular one I vote -1 on it.
> >>
> >> Thanks.
> >>
> >> >
> >> > --
> >> > 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
> >>
> >
> > Hi,
> >
> > To be honest, I'm not a fan of aliasing - and Paul supplied some of the
> > reasons that stands for me.
> > When one see an class / function declaration - I think that it'll make
> > confuse if he/she'll have to look if this is an alias or not. Besides of
> > that, there's still the issue of "overriding existing functions" rules
> which
> > can confuse the user.
> >
> > Put that aside, if you can bring some example of good practice it'll be
> > great :)
>
> I think a good example from top of my head would be PHPUnit testing
> framework. It has class PHPUnit_Framework_Assert that contains only
> static assertion methods like assertEquals(), assertTrue(), etc. Then
> it has class PHPUnit_Framework_TestCase that extends
> PHPUnit_Framework_Assert.
>
> AFAICT there is no other reason for this hierarchy except to allow
> shorter assertion syntax. Example from PHPUnit manual:
>
>   require_once 'PHPUnit/Framework.php';
>
>   class MessageTest extends PHPUnit_Framework_TestCase
>   {
>       public function testMessage()
>       {
>           $this->assertTrue(FALSE, 'This is a custom message.');
>       }
>   }
>
> What is more PHPUnit_Framework_TestCase also contains methods
> dedicated for mocking like once(), returnValue(), etc. Another
> example:
>
>   class StubTest extends PHPUnit_Framework_TestCase
>   {
>       public function testReturnArgumentStub()
>       {
>           // Create a stub for the SomeClass class.
>           $stub = $this->getMock('SomeClass');
>
>           // Configure the stub.
>           $stub->expects($this->once())
>                ->method('doSomething')
>                ->with($this->lessThen('something'))
>                ->will($this->returnValue(true));
>
>           $this->assertTrue($stub->doSomething('foo'));
>           $this->assertTrue($stub->doSomething('bar'));
>       }
>   }
>
> Note that PHPUnit manual promotes using $this despide the fact that
> these methods are ``public static``.
>
> I think assertions and mocking could be decoupled and would be more
> readable like this:
>
>   use PHPUnit_Framework_Assert::assertTrue;
>   use PHPUnit_Framework_Assert::lessThen;
>   use PHPUnit_Framework_MockObject_Matcher::once;
>   use PHPUnit_Framework_MockObject_Matcher::returnValue;
>
>   class StubTest extends PHPUnit_Framework_TestCase
>   {
>       public function testReturnArgumentStub()
>       {
>           // Create a stub for the SomeClass class.
>           $stub = $this->getMock('SomeClass');
>
>           // Configure the stub.
>           $stub->expects(once())
>                ->method('doSomething')
>                ->with(lessThen('something'))
>                ->will(returnValue(true));
>
>           assertTrue($stub->doSomething('foo'));
>           assertTrue($stub->doSomething('bar'));
>       }
>   }
>

This means, this is once more a "I want to save characters in my code"? If
you ask me:

- assert*() could be _real_ functions.

function assert\tue($arg, $msg) {
  $arg or throw new AssertionException($msg);
}

- assert*() could be methods within _a trait_ (to decouple it from the
TestCase-class)

class StubTest extends PHPUnit_Framework_TestCase {
    use Assertion\Boolean;

      public function testReturnArgumentStub()
      {
          $this->assertTrue(true);
          // or?
          self::assertTrue(true);
      }
}


Not, that I want to rewrite PHPUnit (maybe I should suggest it Sebastian
Bergman for a (very) future release? :3).


tl;dr: The problem I have with this suggestion is, that I don't get, want
you want to solve and/or to win.


Regards,
Sebastian



>
>
> > Regards,
> > Yahav.
>
> --
> Giedrius Dubinskas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--047d7b603a781582cb04c74e4513--