Some of them are:
- Problem with import.
- Problem with variables.
- Enterprise applications including UML tools have been written without namespaces (I have taken part in quite a few such projects including Rational (IBM) Rose).
I am confident that one can write enterprise applications without namespaces. You're making a mountain out of a mole hill.
Andi
At 04:30 PM 6/2/2003 +0200, Marcus Börger wrote:
At 14:13 02.06.2003, Stanislav Malyshev wrote:stas Mon Jun 2 08:13:11 2003 EDT
Modified files: /ZendEngine2 [...] Log: MEGA-patch: namespaces are R.I.P.
Hi all,
removing namespaces because of a few remaining problems was a very bad idea.
And after reading the last threads on this i have the strong feeling that the majority
of people interested in PHP development is pro namespaces.
By removing namespaces we lost one of the last things we need to be fully
enterprise ready. Let me explain. By changing the object model to fully support
visibility and also having abstract methods and interfaces we have reached a
language level that allows to design PHP code with UML tools. Unfortunately
now namespaces are missing we lack a dedicated grouping mechanism. Such
grouping is often used as a package alternative (in languages where that is
missing) and hence plays a role in responsibility organizing and highlevel software
abstract organizing.
Coming back to the problems. There are two major problems with namespaces as they were until they were removed. First there is the problem with import which doesn't work right now. Here i must say that noone cared about yet simply because it was never in a acceptable state. This said dropping it for now would have been the best solution. Adding a working version of import at a later time/version of PHP would have been also now problem.
The second problem is the support of ':' in namespaces which caused trouble with the ternary operator. About this i can only say that really noone ever understood why it was needed besides the guys who have implemented it. Not even the pear developers said that they have a need for it. For them (if i am not mistaken) it was ony a nice to have goodie.
For me this leeds to only one possible solution: Put namespaces back in without
import and ':' support.
After fixing the real problems in the current engine. We could then add a working
import. As it was already said that "import cannot be 'fixed', because it's not broken".
i feel a need to show a possible solution. First of all i am not really interested in
the import we had, since it was broken. Second what i'd like is a kind of "select".
For me this means that an import statement should import selected symbols
into the active namespace. I do not expect this to overwrite anything because i think
the solution is to have a dedicated hash table for the imports and use them only
when the original symbol table fails to deliver the requested symbol. Anything that
this solution cannot handle is an error by software design. Especially importing
symbols which interfere with symbols already in the target hash table could result
in an error to prevent such bad design. Also it is easy to emit an error when multiple
import statements would result in a conflict. Since PHP is not a strong typed language
i do not see any real error besides the mentioned problems.
regards marcus
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
