Re: [PHP-DEV] Proposal: use SomeClass::staticMethod

2012-08-15 Thread Giedrius Dubinskas
On Wed, Aug 15, 2012 at 6:54 PM, Lester Caine  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

2012-08-15 Thread Giedrius Dubinskas
On Wed, Aug 15, 2012 at 4:54 PM, Sebastian Krebs  wrote:
> 2012/8/15 Giedrius Dubinskas 
>
>> On Wed, Aug 15, 2012 at 2:19 PM, Yahav Gindi Bar 
>> wrote:
>> > On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis 
>> wrote:
>> >>
>> >> Comments inline.
>> >>
>> >> On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
>> >>  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
>> >>
>

Re: [PHP-DEV] Proposal: use SomeClass::staticMethod

2012-08-15 Thread Giedrius Dubinskas
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  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 
>
>> On Wed, Aug 15, 2012 at 12:59 PM, Giedrius Dubinskas
>>  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-08-15 Thread Giedrius Dubinskas
On Wed, Aug 15, 2012 at 2:19 PM, Yahav Gindi Bar  wrote:
> On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis  wrote:
>>
>> Comments inline.
>>
>> On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
>>  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'))

[PHP-DEV] Proposal: use SomeClass::staticMethod

2012-08-15 Thread Giedrius Dubinskas
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