Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
2012/8/15 Giedrius Dubinskas d.giedr...@gmail.com
On Wed, Aug 15, 2012 at 4:54 PM, Sebastian Krebs krebs@gmail.com
wrote:
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).
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
``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
[PHP-DEV] Proposal: use SomeClass::staticMethod
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
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++ 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. -- 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
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
On Wed, Aug 15, 2012 at 12:59 PM, 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() 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
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++ 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. -- 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 :) Regards, Yahav.
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
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@gmail.com On Wed, Aug 15, 2012 at 12:59 PM, 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() 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
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.
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 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')
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
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 On Wed, Aug 15, 2012 at 2:26 PM, Sebastian Krebs krebs@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, Sebastian 2012/8/15 Nikita Popov nikita@gmail.com On Wed, Aug 15, 2012 at 12:59 PM, 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() 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 -- 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
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
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
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
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.giedr...@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 Dubinskas On Wed, Aug 15, 2012 at 2:26 PM, Sebastian Krebs krebs@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, Sebastian 2012/8/15 Nikita Popov nikita@gmail.com On Wed, Aug 15, 2012 at 12:59 PM, 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() 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
On Wed, Aug 15, 2012 at 4:54 PM, Sebastian Krebs krebs@gmail.com wrote:
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).
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
``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
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
On Wed, Aug 15, 2012 at 6:54 PM, Lester Caine les...@lsces.co.uk 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 to ``use`` them :-) -- Giedrius Dubinskas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
Giedrius Dubinskas wrote: On Wed, Aug 15, 2012 at 6:54 PM, Lester Caine les...@lsces.co.uk 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 to ``use`` them :-) 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
