| 1 |
joko |
1.1 |
<!-- @metadata-begin --><pre> |
| 2 |
|
|
|
| 3 |
|
|
@sequence main |
| 4 |
|
|
@title DummyNamespaces in PHP - final proposal |
| 5 |
|
|
@file C:\home\amo\develop\netfrag.org\joko\doc\twingled\SampleNewsPosts\DummyNamespaces in PHP - final proposal.twingle |
| 6 |
|
|
@url http://grasshopper.netfrag.org/c/home/amo/develop/netfrag.org/joko/doc/twingled/SampleNewsPosts/DummyNamespaces in PHP - final proposal.twingle |
| 7 |
|
|
@is-a rfc, rfp |
| 8 |
|
|
@todo tbd |
| 9 |
|
|
|
| 10 |
|
|
@glossary |
| 11 |
|
|
rfc [request for comments] (the classic) |
| 12 |
|
|
rfp [refactoring proposal] (code already written) |
| 13 |
|
|
tbd [to be discussed] (api not fixed yet) |
| 14 |
|
|
|
| 15 |
|
|
@sequence cvs-info |
| 16 |
|
|
$Id$ |
| 17 |
|
|
$Log$ |
| 18 |
|
|
|
| 19 |
|
|
</pre><!-- @metadata-end --> |
| 20 |
|
|
|
| 21 |
|
|
|
| 22 |
|
|
DummyNamespaces in PHP - final proposal |
| 23 |
|
|
|
| 24 |
|
|
The problem: (copied from ancestor document) |
| 25 |
|
|
[...] |
| 26 |
|
|
Here is the glitch: We actually have two *different* |
| 27 |
|
|
types of namespaces following this proposed component |
| 28 |
|
|
architecture: |
| 29 |
|
|
- ClassNamespace |
| 30 |
|
|
- ModuleNamespace |
| 31 |
|
|
[...] |
| 32 |
|
|
|
| 33 |
|
|
|
| 34 |
|
|
The solution: |
| 35 |
|
|
|
| 36 |
|
|
We split up everything into *two* things: |
| 37 |
|
|
- two layers (core, api) ... |
| 38 |
|
|
... to get better code structure |
| 39 |
|
|
- two types of things to manage (native php classes, our modules) |
| 40 |
|
|
... to get better api structure |
| 41 |
|
|
-> just the api layer adds namespacing support! |
| 42 |
|
|
-> the core layer is "dumb" ;-) |
| 43 |
|
|
|
| 44 |
|
|
|
| 45 |
|
|
1. core layer (mk) |
| 46 |
|
|
|
| 47 |
|
|
php::mkComponent should be able to pass back instances |
| 48 |
|
|
of components from *both* namespaces using infrastructure |
| 49 |
|
|
code from the php:: namespace, which is: |
| 50 |
|
|
|
| 51 |
|
|
php::mkInstance should pass back a new instance |
| 52 |
|
|
of a component from the ClassNamespace. |
| 53 |
|
|
|
| 54 |
|
|
php::mkModule should pass back a new instance |
| 55 |
|
|
of a component from the ModuleNamespace. |
| 56 |
|
|
|
| 57 |
|
|
|
| 58 |
|
|
2. api layer (use,get) |
| 59 |
|
|
|
| 60 |
|
|
php::useNamespace limits the scope of the core... |
| 61 |
|
|
... in a way that further operations occour on |
| 62 |
|
|
namespaces get prefixed by this namespace. |
| 63 |
|
|
Must accept an identifier which designates the |
| 64 |
|
|
to-be-used namespace. This identifier should be |
| 65 |
|
|
capable to point to components living in either |
| 66 |
|
|
the ClassNamespace *or* the ModuleNamespace. |
| 67 |
|
|
|
| 68 |
|
|
php::getComponent should return an instance |
| 69 |
|
|
of a component regardless in which namespace |
| 70 |
|
|
it lives. (It can be a class *or* a module) |
| 71 |
|
|
Given the logic required for php::useNamespace, |
| 72 |
|
|
we can reduce the amount of arguments required |
| 73 |
|
|
to actually get to a component: |
| 74 |
|
|
Just a "global" declaration would be required |
| 75 |
|
|
on top of your "metacode" ... |
| 76 |
|
|
php::useNamespace('Deep::nested::Module'); |
| 77 |
|
|
... and inside it you are able to do: |
| 78 |
|
|
php::getComponent('Even::more::deeper::Submodule'); |
| 79 |
|
|
Of course (master requirement for getting our |
| 80 |
|
|
stuff with bareface's neutral proposal together) - the same should also work |
Parent Directory
| 
Revision Log
