[PHP-DEV] MEGA-patch: namespaces are R.I.P.
Marcus Börger
>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
Andi Gutmans
arguments against yours.
Some of them are:
- Problem with import.
- Problem with variables.
- Enterprise applications including UML tools have been written without=20
namespaces (I have taken part in quite a few such projects including=20
Rational (IBM) Rose).
I am confident that one can write enterprise applications without=20
namespaces. You're making a mountain out of a mole hill.
Andi
At 04:30 PM 6/2/2003 +0200, Marcus B=F6rger 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=
=20
>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=20
>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=
=20
>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=20
>without
>import and ':' support.
>
>After fixing the real problems in the current engine. We could then add a=
=20
>working
>import. As it was already said that "import cannot be 'fixed', because=20
>it's not broken".
>i feel a need to show a possible solution. First of all i am not really=20
>interested in
>the import we had, since it was broken. Second what i'd like is a kind of=
=20
>"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=20
>because i think
>the solution is to have a dedicated hash table for the imports and use=20
>them only
>when the original symbol table fails to deliver the requested symbol.=20
>Anything that
>this solution cannot handle is an error by software design. Especially=20
>importing
>symbols which interfere with symbols already in the target hash table=20
>could result
>in an error to prevent such bad design. Also it is easy to emit an error=20
>when multiple
>import statements would result in a conflict. Since PHP is not a strong=20
Marcus Börger
>I strongly disagree. Please re-read the original thread to see our=20
>arguments against yours.
There were no arguments just some sentences (from Zeev iirc) stating that it
can't work and that i am expecting something else. Since i don't see=
problems
with my idea of import that might be the case with the import we had.
>Some of them are:
>- Problem with import.
See above and please reread my original mail because i did some technical
explanation on this topic there already.
>- Problem with variables.
All solveable. And the problems are with import only (afaik) so we could=
drop
support for importing variables later when adding import.
>- Enterprise applications including UML tools have been written without=20
>namespaces (I have taken part in quite a few such projects including=20
>Rational (IBM) Rose).
Whatever they had in mind. Rational comes from a Java perspective where you
have packages as a grouping mechanism. PHP now has neither.
>I am confident that one can write enterprise applications without=20
>namespaces. You're making a mountain out of a mole hill.
Perhaps :-) I wanted to stress out what we lack and make clear that all=20
problems
could be solved.
regards
marcus
>Andi
>
>At 04:30 PM 6/2/2003 +0200, Marcus B=F6rger 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=
=20
>>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=20
>>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=20
>>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=
=20
>>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=
=20
Zeev Suraski
>Perhaps :-) I wanted to stress out what we lack and make clear that all=20
>problems
>could be solved.
Technically, maybe. I don't even want to argue. What cannot be solved is=
=20
the fact that the obscurity added by namespaces and related features is way=
=20
too high a price for the questionable gain they give. I'm sorry we weren't=
=20
bright enough to predict it before the initial implementation made it to=20
CVS, but I'm happy we caught it before it was too late.
Zeev
Andi Gutmans
>At 20:29 02.06.2003, Andi Gutmans wrote:
>>I strongly disagree. Please re-read the original thread to see our=20
>>arguments against yours.
>
it
>can't work and that i am expecting something else. Since i don't see=
problems
>with my idea of import that might be the case with the import we had.
A possible problem are variables. And two hash lookups sucks too but that's=
=20
bearable.
>>Some of them are:
>>- Problem with import.
>
>See above and please reread my original mail because i did some technical
>explanation on this topic there already.
I read it and I don't think it's good. I'd expect imported functions to at=
=20
least take precedence or cause an error if a function with the same name is=
=20
defined in current symbol table. Your solution always puts them second. You=
=20
might not agree but you can see it's not as simple as you claim.
>>- Problem with variables.
>
>All solveable. And the problems are with import only (afaik) so we could=
drop
>support for importing variables later when adding import.
When you create a variable how do you know where to create it?
>>- Enterprise applications including UML tools have been written without=20
>>namespaces (I have taken part in quite a few such projects including=20
>>Rational (IBM) Rose).
>
>Whatever they had in mind. Rational comes from a Java perspective where you
>have packages as a grouping mechanism. PHP now has neither.
If you have created so many enterprise apps with Rose then you should be=20
aware that it works with C++ and that's what I used it with. C++ without=20
namespaces. Rose was around (and I've been using it) *long* before Java was=
=20
around. Rational does definitely not come from a Java perspective on this=
one.
>>I am confident that one can write enterprise applications without=20
>>namespaces. You're making a mountain out of a mole hill.
>
>Perhaps :-) I wanted to stress out what we lack and make clear that all=20
>problems
>could be solved.
Again I disagree.
Andi
Andrei Zmievski
> Technically, maybe. I don't even want to argue. What cannot be solved is
Oh well. The powers that be have decided and there is no point in
arguing. Bye-bye namespaces. Maybe exceptions will be next.
-Andrei
* We are not a clone. *
Preston L. Bannister
The folks who want to do everything in one language, or not? :)
As far as namespaces are concerned - a nice idea, but not something I'd
personally miss. Sounded like not everyone was comfortable with the
implementation of namespaces. That's a pretty good consideration right
there. Better that what goes into PHP 5 be well thought out and well
implemented.
Both Ada and C++ provide useful examples of how doing too much at once
can get youi into trouble.
Ada was considered the most carefully designed and throughly reviewed
programming language at the time. Yet because of the complexity of the
language when implementing the first Ada compilers we found points where
significant behavior was completely unspecified.
C++ had so many new features shoveled in during the standardization
process that using the fancier features that (as does STL) requires
"porting" code to each new compiler.
Deferring namespaces might be the smartest choice.
Zeev Suraski wrote:
> The powers have decided that I have to argue?
>
> You're invited to argue as much as you please if you feel like
> spending your time on this. It appears that on the arguing front the
> C++/Java zealots are always on the winning side because they appear to
> have endless patience and they're represented in an entirely non
> proportional way in this forum.
Per Lundberg
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Tue, 2003-06-03 at 19:01, Zeev Suraski wrote:
> It appears that on the arguing front the C++/Java=20
> zealots are always on the winning side because they appear to have endles=
s=20
> patience and they're represented in an entirely non proportional way in=20
> this forum.
Non-proportional to what?
--
Best regards,
Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.nobolt.com
--=_salem-21058-1054716230-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQA+3bFFTN4aRo9LnpERAnd8AJ4waezQvfj+T1QhjnrLJ/suW512jACdFQKv
Z8dZLDdGONSrOJqLVe1yiG4=
=yR5I
-----END PGP SIGNATURE-----
--=_salem-21058-1054716230-0001-2--