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 |