2012/8/15 Giedrius Dubinskas <d.giedr...@gmail.com>
> On Wed, Aug 15, 2012 at 2:19 PM, Yahav Gindi Bar <g.b.ya...@gmail.com>
> wrote:
> > On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis <dragoo...@gmail.com>
> wrote:
> >>
> >> Comments inline.
> >>
> >> On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
> >> <d.giedr...@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
>
>
