# Proposal: use SomeClass::staticMethod

- Thread: https://externals.io/message/62184
- Original archive: https://news-web.php.net/php.internals/62184
- Started by Giedrius Dubinskas on 2012-08-15T10:59:16+00:00
- Messages: 14
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #62184 — Giedrius Dubinskas — 2012-08-15T10:59:16+00:00

URL: https://externals.io/message/62184#62184

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

---

## #62185 — Paul Dragoonis — 2012-08-15T11:09:32+00:00

URL: https://externals.io/message/62184#62185 · In reply to: #62184

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.

---

## #62186 — Nikita Popov — 2012-08-15T11:18:54+00:00

URL: https://externals.io/message/62184#62186 · In reply to: #62184

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

---

## #62187 — Yahav Gindi Bar — 2012-08-15T11:19:05+00:00

URL: https://externals.io/message/62184#62187 · In reply to: #62185

> Comments inline.
>
> On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
> <d.giedrius@gmail.com> wrote:
> > […]
>
> Then you're confusing the reader, they think you're calling a
> function, but you're actually calling a class method. Confusion++
>
> > […]
>
> What if a function called staticMethod() already exists, there'd be a
> bunch of confusion on referring to the right one.
>
> > […]
>
> 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.
>
> > […]
>
> Not 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.

---

## #62189 — Sebastian Krebs — 2012-08-15T11:26:37+00:00

URL: https://externals.io/message/62184#62189 · In reply to: #62186

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:
> > […]
>
> 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

---

## #62191 — Giedrius Dubinskas — 2012-08-15T13:29:13+00:00

URL: https://externals.io/message/62184#62191 · In reply to: #62187

> 
> > […]

Static method essentially is a function (with elevated access to
containing class) so I don't see much of a problem here.

> > […]

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 ...

> > […]

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.

> > […]
>
> 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

---

## #62192 — Giedrius Dubinskas — 2012-08-15T13:52:31+00:00

URL: https://externals.io/message/62184#62192 · In reply to: #62189

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,
> Sebastian
>
> 2012/8/15 Nikita Popov <nikita.ppv@gmail.com>
>
> > […]

---

## #62193 — Sebastian Krebs — 2012-08-15T13:54:47+00:00

URL: https://externals.io/message/62184#62193 · In reply to: #62191

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:
> > […]
> wrote:
> > […]
>
> 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).


>
> > […]
>
> 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 ...
>
> > […]
>
> 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.


>
> > […]
> which
> > […]
>
> I think a good example from top of my head would be PHPUnit testing
> framework. It has class PHPUnit_Framework_Assert that contains only
> static assertion methods like assertEquals(), assertTrue(), etc. Then
> it has class PHPUnit_Framework_TestCase that extends
> PHPUnit_Framework_Assert.
>
> AFAICT there is no other reason for this hierarchy except to allow
> shorter assertion syntax. Example from PHPUnit manual:
>
>   require_once 'PHPUnit/Framework.php';
>
>   class MessageTest extends PHPUnit_Framework_TestCase
>   {
>       public function testMessage()
>       {
>           $this->assertTrue(FALSE, 'This is a custom message.');
>       }
>   }
>
> What is more PHPUnit_Framework_TestCase also contains methods
> dedicated for mocking like `once()`, returnValue(), etc. Another
> example:
>
>   class StubTest extends PHPUnit_Framework_TestCase
>   {
>       public function testReturnArgumentStub()
>       {
>           // Create a stub for the SomeClass class.
>           $stub = $this->getMock('SomeClass');
>
>           // Configure the stub.
>           $stub->expects($this->once())
>                ->method('doSomething')
>                ->with($this->lessThen('something'))
>                ->will($this->returnValue(true));
>
>           $this->assertTrue($stub->doSomething('foo'));
>           $this->assertTrue($stub->doSomething('bar'));
>       }
>   }
>
> Note that PHPUnit manual promotes using $this despide the fact that
> these methods are ``public static``.
>
> I think assertions and mocking could be decoupled and would be more
> readable like this:
>
>   use PHPUnit_Framework_Assert::assertTrue;
>   use PHPUnit_Framework_Assert::lessThen;
>   use PHPUnit_Framework_MockObject_Matcher::once;
>   use PHPUnit_Framework_MockObject_Matcher::returnValue;
>
>   class StubTest extends PHPUnit_Framework_TestCase
>   {
>       public function testReturnArgumentStub()
>       {
>           // Create a stub for the SomeClass class.
>           $stub = $this->getMock('SomeClass');
>
>           // Configure the stub.
>           $stub->expects(once())
>                ->method('doSomething')
>                ->with(lessThen('something'))
>                ->will(returnValue(true));
>
>           assertTrue($stub->doSomething('foo'));
>           assertTrue($stub->doSomething('bar'));
>       }
>   }
>

This means, this is once more a "I want to save characters in my code"? If
you ask me:

- assert*() could be _real_ functions.

function assert\tue($arg, $msg) {
  $arg or throw new AssertionException($msg);
}

- assert*() could be methods within _a trait_ (to decouple it from the
TestCase-class)

class StubTest extends PHPUnit_Framework_TestCase {
    use Assertion\Boolean;

      public function testReturnArgumentStub()
      {
          $this->assertTrue(true);
          // or?
          self::assertTrue(true);
      }
}


Not, that I want to rewrite PHPUnit (maybe I should suggest it Sebastian
Bergman for a (very) future release? :3).


tl;dr: The problem I have with this suggestion is, that I don't get, want
you want to solve and/or to win.


Regards,
Sebastian



>
>
> > […]
>
> --
> Giedrius Dubinskas

---

## #62194 — Sebastian Krebs — 2012-08-15T13:59:57+00:00

URL: https://externals.io/message/62184#62194 · In reply to: #62192

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 Dubinskas
>
> On Wed, Aug 15, 2012 at 2:26 PM, Sebastian Krebs <krebs.seb@gmail.com>
> wrote:
> > […]

---

## #62195 — Giedrius Dubinskas — 2012-08-15T15:23:54+00:00

URL: https://externals.io/message/62184#62195 · In reply to: #62193

> 2012/8/15 Giedrius Dubinskas <d.giedrius@gmail.com>
>
> > […]
>
> 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... :-)

> > […]
>
> 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.
>
>
> > […]
>
> 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

---

## #62196 — Lester Caine — 2012-08-15T15:54:21+00:00

URL: https://externals.io/message/62184#62196 · In reply to: #62195

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

---

## #62197 — Giedrius Dubinskas — 2012-08-15T17:07:34+00:00

URL: https://externals.io/message/62184#62197 · In reply to: #62196

> Giedrius Dubinskas wrote:
> > […]
>
>
> 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

---

## #62200 — Lester Caine — 2012-08-15T19:52:10+00:00

URL: https://externals.io/message/62184#62200 · In reply to: #62197

Giedrius Dubinskas wrote:
> 
> > […]
>
> 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

---

## #62216 — Sebastian Krebs — 2012-08-16T07:26:14+00:00

URL: https://externals.io/message/62184#62216 · In reply to: #62195

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:
> > […]
> for a
> > […]
> Namespaced\SomeClass::staticMethod()
> > […]
> will
> > […]
> here.
> > […]
> have
> > […]
>
> 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... :-)
>
> > […]
> cases
> > […]
> namespace,
> > […]
> you
> > […]
> too.
> > […]
> the
> > […]
> of
> > […]
> be
> > […]
> If
> > […]
>
> 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.
>

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.


>
> > […]
>
> 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.


>
> > […]
>
> 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