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()
fooBar(); // would call Some\Foo::bar()
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".
Aliasing class constants like that would also be very nice.
What does everyone think?
Would it be possible in PHP?
--
Giedrius Dubinskas
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++
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.
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.
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.
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++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.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.Aliasing class constants like that would also be very nice.
What does everyone think?
Would it be possible in PHP?--
Giedrius DubinskasNot that I don't welcome your suggestions, I encourage them, but for
this paritcular one I vote -1 on it.Thanks.
--
--
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 :)
Regards,
Yahav.
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.
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.
Aliasing class constants like that would also be very nice.
What does everyone think?
Would it be possible in PHP?--
Giedrius DubinskasNot that I don't welcome your suggestions, I encourage them, but for
this paritcular one I vote -1 on it.Thanks.
--
--
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'));
}
}
Regards,
Yahav.
--
Giedrius Dubinskas
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
fooBardeclaration 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 DubinskasNot that I don't welcome your suggestions, I encourage them, but for
this paritcular one I vote -1 on it.Thanks.
--
--
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 arepublic 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
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 (seerand(), 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).
That is an interesting thought but from my point of view just becasue
static method can access static class attributes does not imply that
static methods are or should be stateful. For me stateful static
methods just like stateful functions have their place (e.g. rand())
but its very limited and should not be considered common. I don't see
how stateful static method is any better then stateful function. If
you could share any resources that would convince my otherwise I'd be
like to learn that. Anyway I guess we are already drifting away from
the original suggestion... :-)
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
fooBardeclaration 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 DubinskasNot that I don't welcome your suggestions, I encourage them, but for
this paritcular one I vote -1 on it.Thanks.
--
--
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 arepublic 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);
}
This would still require some kind of namespace prefix. It may work
with assert\isTrue or something like that but it's not so
straightforward with mocking example above.
- 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); }}
This does not add anything to readability. This is just the same it is now.
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.
My main aim with this suggestion is readability. I'd like to remove
unnecessary noise in code where it doesn't add any value to the
reader. Code is easy to type (especially with good autocompletion) but
it is read more often then typed and I think that is important. Or is
it just me?
--
Giedrius Dubinskas
Giedrius Dubinskas wrote:
My main aim with this suggestion is readability. I'd like to remove
unnecessary noise in code where it doesn't add any value to the
reader. Code is easy to type (especially with good autocompletion) but
it is read more often then typed and I think that is important. Or is
it just me?
Depends who is doing the reading? Since a static method should be provided with
all the data it needs to produce a result, does it actually matter what it is
called and how it is called? Of cause it does when one is trying to find the
right descendent method of the class?
I've already been told that the code I'm working on upgrading is archaic but it
works fine. The bulk of the recent work has been pulling $this out of functions
and creating a static section for many that handles the results of building a
hash from the object, or supplying a ready built one. I'm told that it's bad
practice to include the static functions within the class? But they are an
integral part of processing the object, or are overridden by functions in the
descendant objects. So 'staticMethod' has to be the right one for the object
created, and SomeClass:: depends on the object being created. So how does the
proposal cope with that type of structure?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Giedrius Dubinskas wrote:
My main aim with this suggestion is readability. I'd like to remove
unnecessary noise in code where it doesn't add any value to the
reader. Code is easy to type (especially with good autocompletion) but
it is read more often then typed and I think that is important. Or is
it just me?Depends who is doing the reading? Since a static method should be provided
with all the data it needs to produce a result, does it actually matter what
it is called and how it is called? Of cause it does when one is trying to
find the right descendent method of the class?I've already been told that the code I'm working on upgrading is archaic but
it works fine. The bulk of the recent work has been pulling $this out of
functions and creating a static section for many that handles the results of
building a hash from the object, or supplying a ready built one. I'm told
that it's bad practice to include the static functions within the class? But
they are an integral part of processing the object, or are overridden by
functions in the descendant objects. So 'staticMethod' has to be the right
one for the object created, and SomeClass:: depends on the object being
created. So how does the proposal cope with that type of structure?
Sorry, I'm not sure I follow. Would it be possible provide some
examples of what you mean?
My proposal does not change anything to existing code. It only adds to
readability where it is most desired. I picked PHPUnit example just to
show that there is a desire for it in real world applications and in
that particular case looks like inheritance was used (IMHO
incorrectly) to reduce noise of prefixing class to each static method
call for assertion and mocking matcher.
With my proposal it would be posible to reduce this noise even more.
I am not saying that this feature would be used everywhere nor that it
should. But it would add a lot where it is already most desired.
And FWIW for PHPUnit it would work out of the box. The static methods
are already there. One would just need to use them :-)
--
Giedrius Dubinskas
Giedrius Dubinskas wrote:
Giedrius Dubinskas wrote:
My main aim with this suggestion is readability. I'd like to remove
unnecessary noise in code where it doesn't add any value to the
reader. Code is easy to type (especially with good autocompletion) but
it is read more often then typed and I think that is important. Or is
it just me?Depends who is doing the reading? Since a static method should be provided
with all the data it needs to produce a result, does it actually matter what
it is called and how it is called? Of cause it does when one is trying to
find the right descendent method of the class?I've already been told that the code I'm working on upgrading is archaic but
it works fine. The bulk of the recent work has been pulling $this out of
functions and creating a static section for many that handles the results of
building a hash from the object, or supplying a ready built one. I'm told
that it's bad practice to include the static functions within the class? But
they are an integral part of processing the object, or are overridden by
functions in the descendant objects. So 'staticMethod' has to be the right
one for the object created, and SomeClass:: depends on the object being
created. So how does the proposal cope with that type of structure?Sorry, I'm not sure I follow. Would it be possible provide some
examples of what you mean?My proposal does not change anything to existing code. It only adds to
readability where it is most desired. I picked PHPUnit example just to
show that there is a desire for it in real world applications and in
that particular case looks like inheritance was used (IMHO
incorrectly) to reduce noise of prefixing class to each static method
call for assertion and mocking matcher.With my proposal it would be posible to reduce this noise even more.
I am not saying that this feature would be used everywhere nor that it
should. But it would add a lot where it is already most desired.And FWIW for PHPUnit it would work out of the box. The static methods
are already there. One would just need tousethem :-)
Overriding just one version of 'staticMethod' with a shorthand is going to make
working out WHICH version is being called all the more difficult to understand
as one has to find a use clause to which it relates somewhere further up the
code chain? Simply to identify the relevant block of code that is being actioned.
In real applications (PHPUnit are not a real application only test case actions)
there will be several occurrences of say 'getDisplayUrlFromHash' for the base
class and for each specialised descendant class, so that referring to one via
shorthand does not work practically. There may be special cases where it could
be used, but that is just the sort of 'creep' that we need to avoid? At some
point using the shorthand has to be replaced with the proper version simply
because a different version of the code is needed.
The main problem I have here is that having reworked the code to remove all the
strict warnings/errors, I'm still not sure that the resulting code IS following
the right rules, so it may well be that there is another way of building
descendent static code that works more like you expect it to?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
2012/8/15 Giedrius Dubinskas d.giedrius@gmail.com
On Wed, Aug 15, 2012 at 4:54 PM, Sebastian Krebs krebs.seb@gmail.com
wrote: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 (seerand(), 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).That is an interesting thought but from my point of view just becasue
static method can access static class attributes does not imply that
static methods are or should be stateful.
I my opinion methods should be stateful, but thats more a "loose should",
because thats an implementation detail of the method itself, which I
shouldn't care about. However, even more I think, that functions
shouldn't have a state. There are many exceptions we all know, but I
don't think it's a good reason to produce own stateful functions at will
and begin to treat methods and functions as the same.
For me stateful static
methods just like stateful functions have their place (e.g.rand())
but its very limited and should not be considered common. I don't see
how stateful static method is any better then stateful function.
Other way round: Stateful functions are worse ;)
If
you could share any resources that would convince my otherwise I'd be
like to learn that. Anyway I guess we are already drifting away from
the original suggestion... :-)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
fooBardeclaration 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 DubinskasNot that I don't welcome your suggestions, I encourage them, but for
this paritcular one I vote -1 on it.Thanks.
--
--
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 arepublic 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);
}This would still require some kind of namespace prefix. It may work
withassert\isTrueor something like that but it's not so
straightforward with mocking example above.
I don't have any problem with namespaces, I like, how the tell me, where
something is coming from.
Because you mentioned your mocking-example: There you have the function
'assertTrue()'. 'assert*()' is just a prefix here, what reminds me of all
the good all functions like strpos() and such. Do you think this is
really better? And where is the ugly difference between 'assert\isTrue()'
and 'assertTrue()'? I like the namespaced version more, because 'assert' is
not just a prefix telling me, what "kind" of function that is, it is more
an indicator to which "family" it belongs to.
- 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); }}
This does not add anything to readability. This is just the same it is now.
Must say: Don't know, how unreadable it really is... Even with your mocking
example.
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.My main aim with this suggestion is readability. I'd like to remove
unnecessary noise in code where it doesn't add any value to the
reader. Code is easy to type (especially with good autocompletion) but
it is read more often then typed and I think that is important. Or is
it just me?
You are right, that code is read more often, than write, but thats exactly,
why "clarity" is part of "readabilit". Do you always need to read the whole
source (especially the head) just to find out wether foo() is a function,
or a method? Ambiguity is not good for readability.
--
Giedrius Dubinskas
On Wed, Aug 15, 2012 at 12:59 PM, 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()
fooBar(); // would call Some\Foo::bar()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".Aliasing class constants like that would also be very nice.
What does everyone think?
I have the suspicion that you are just using static methods as a way
to group functions into a "namespace". If that's what you want, then
why not just use namespaced functions for that? Should be a lot less
confusing and also semantically more correct.
Nikita
Hi,
because it fits into the context (even if it's slightly offtopic): Can I
throw in, that I would like to see autoloading for functions? :)
Regards,
Sebastian
2012/8/15 Nikita Popov nikita.ppv@gmail.com
On Wed, Aug 15, 2012 at 12:59 PM, 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()
fooBar(); // would call Some\Foo::bar()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".Aliasing class constants like that would also be very nice.
What does everyone think?
I have the suspicion that you are just using static methods as a way
to group functions into a "namespace". If that's what you want, then
why not just use namespaced functions for that? Should be a lot less
confusing and also semantically more correct.Nikita
Yes that is a very common use case and autoloading functions would
solve that one but my main aim here is readability. And that said I
would also suggest:
use function Namespaced\foo;
foo(); // calls Namespaced\foo();
;-)
--
Giedrius Dubinskas
Hi,
because it fits into the context (even if it's slightly offtopic): Can I
throw in, that I would like to see autoloading for functions? :)Regards,
Sebastian2012/8/15 Nikita Popov nikita.ppv@gmail.com
On Wed, Aug 15, 2012 at 12:59 PM, 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()
fooBar(); // would call Some\Foo::bar()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".Aliasing class constants like that would also be very nice.
What does everyone think?
I have the suspicion that you are just using static methods as a way
to group functions into a "namespace". If that's what you want, then
why not just use namespaced functions for that? Should be a lot less
confusing and also semantically more correct.Nikita
Hi,
This additional "function" seems little bit ... misplaced. :X Why not just
use MyFoo\Bar;
Bar\baz(); // <-- Would be cool, if this trigger an autloader if required
Except, that there is no autoloading everything already works this way.
Regards,
Sebastian
2012/8/15 Giedrius Dubinskas d.giedrius@gmail.com
Yes that is a very common use case and autoloading functions would
solve that one but my main aim here is readability. And that said I
would also suggest:use function Namespaced\foo;
foo(); // calls Namespaced\foo();
;-)
--
Giedrius DubinskasOn Wed, Aug 15, 2012 at 2:26 PM, Sebastian Krebs krebs.seb@gmail.com
wrote:Hi,
because it fits into the context (even if it's slightly offtopic): Can I
throw in, that I would like to see autoloading for functions? :)Regards,
Sebastian2012/8/15 Nikita Popov nikita.ppv@gmail.com
On Wed, Aug 15, 2012 at 12:59 PM, 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()
fooBar(); // would call Some\Foo::bar()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".Aliasing class constants like that would also be very nice.
What does everyone think?
I have the suspicion that you are just using static methods as a way
to group functions into a "namespace". If that's what you want, then
why not just use namespaced functions for that? Should be a lot less
confusing and also semantically more correct.Nikita