Use cases of Dream.path

[Adrián Montesinos González]

The function Dream.path has been marked as deprecated. I understand that structured routing is preferable, but its removal blocks use cases for which routes can't be computed upfront. For example:

• Dream.static depends on the internal equivalent to path to map paths to the file system; it should be possible to implement such a handler with Dream's public API as well.
• I'm currently writing a CGI handler, and I needed path to forward paths to CGI scripts.

If path were removed, implementing such handlers would become an exercise in recursive application of Dream.router to consume the entire path that wouldn't even provide any static information to parent scopes. Simple access to the path feels to me too foundational to remove, even if it competes with structured routes. (Would access to query parameters be removed as well if they were made routable?)

If widespread access to path is problematic for routing, maybe path could return a value only when the innermost route handler ends with a wildcard, and raise an exception otherwise. This would make handlers like static or my CGI handler fail unless mounted directly under a wildcard, which I think is reasonable.

[Josef Thorne]

Will the deprecation of this be reversed? For the above use cases I don't see a clear alternative. If this has already been un-deprecated and my dream version is out of date then my mistake :)