Martin Alterisio wrote:
> I didn't understand. Do you mean that I was wrong? Or that I was right about
> namespaces purpose, but that's only needed in development? Therefore,
> shouldn't the bundling process remove the need for namespaces (i.e. the
> bundling process removes namespaces)?
You can't expand classes in different namespaces as class Blah::Blah {}
is not possible.
In addition, by forcing code modifications on creating the bundle, you
introduce a level of complexity that can introduce subtle but critical
bugs, simply because the code being executed is different from the
pre-existing code. Having done this kind of work for years with PEAR in
the install phars for a different reason, I can say definitively that
any code modifications that are required to make something work in an
automatic fashion introduce a level of magic that is brittle and much
less maintainable.
> Aside form that, is it not coherent that a whole namespace conforms one
> bundle? Why should namespaces mix?
That's a developer's choice. The current implementation forces it to be
so, with code modifications. In addition, you would need to check for
all import clauses and replace them, as combining these files is a fatal
error:
<?php
namespace A;
class a {}
?>
<?php
namespace A;
import a as b;
class c extends b {}
?>
<?php
namespace A;
class b {}
?>
So in other words, without the simple 10-line patch to zend_compile.c
allowing combining of namespaces into a single file, you just can't
reliably combine multiple files containing a namespace statement even in
the same namespace, no matter what foobar magic your bundling script
practices.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
