Eliminate arg() in favor of context

$context['arg:0'] ? \o/

Hmm after the path stuff this seems not that hard.

function arg($index = NULL, $path = NULL) {

I'm only concerend about $path, how will it look?
$context->getValue('arg:0:node/1') ??

Can a path contain a : (I think it's called semicolon in english?)
When the http and path handlers are in code I'll fix this one.

And if I'm not mistaken the next chuck of code will be handled by the context system

  // Even though $arguments doesn't need to be resettable for any functional
  // reasons (the result of explode() does not depend on any run-time
  // information), it should be resettable anyway in case a module needs to
  // free up the memory used by it.
  // Use the advanced drupal_static() pattern, since this is called very often.
  static $drupal_static_fast;
  if (!isset($drupal_static_fast)) {
    $drupal_static_fast['arguments'] = &drupal_static(__FUNCTION__);
  }
  $arguments = &$drupal_static_fast['arguments'];

Hmm this is a little trickier than I thought.

You can call arg($index, $path);
So for context this could be arg:$index:$path.

1) $path can be null ==> arg:$index
2) $path and $index can be null ==> arg

But now comes the tricky part

3) $index can be null ==> arg:NULL:$path

This seems like a nasty problem...
I hacked my way through it by passing a negative index and test for it but that sound sooooooooooooo bad :).

Good news
----------
Arg gets called a lot (+/-20 times on simple test I performed), the context system only gets called once for each combination of $path and $index (5 times on my test), I don't know how the caching works but that is my observation.

note: these are not real bechmarks ;)

Btw its build on top of the path handlers

If Drupal path handling API ends up in OOP, there is not reason not to keep the arg() function as a static helper (part of this API). arg($index, $path) function signature is totally legitimate, and context handler could use it as backend for splitting the path. Remember that context is only an accessor to contextual data, and is not a replacement for a lower level API.

Path is something in the core of Drupal way, and right now we have no clue how to remove it or how it will evolve. It sounds legitimate to have an API to manipulate pathes (atomic API) that can be used for other use case such as, dunno, admistration screens or configuration handling, or internal menu handling.

In addition to the upper statement, I'd say that keeping an arg() function (but renamed otherwise, in a bigger path handling API) seems something that makes sense.

Regarding this perspective, I don't think removing arg() solve any problem; people that would do raw path handling for some reason would then become dependant of context where they should not.

Context handlers will have, per definition, a dependency over the API that gives birth to the data they expose. If a context handler expose a path, path handling API is then a dependency, it doesn't make any sense otherwise.

Per catch, and blessed by Larry, moving this and all other WSCCI issues to the Drupal core queue.

Based on the wscci branch I made a new argument handler patch that removes the arg function and removes the path argument.

I don't say an argument handler has to look like this. I was curious if I could make it work without the path handler and without introducing extra functions.

I'm not going to set this to needs review as this is based on a sandbox branch.