> if their income depends on it, hmm, I wonder, why the hell are they
> only complaining?
point well made
> always been open and we have always gladly given account to
> people who contributed.
and it's been well noticed, not to mention the amount of times you have
to repeat yourself. Particularly over namespaces!
I used to work in a company that had been going for years, and they had
something that affected staff called the "ibean", or "ay been" or
translated "it's always been" - People don't like change. If only there
was a way to filter through only constructive critism..
Regards Nathan
Marcus Boerger wrote:
Hello Nathan,
if their income depends on it, hmm, I wonder, why the hell are they only
complaining? The amount of people being constructive and not actual
developers with a php.net account is close to zero. That is what Jani had in
mind. We have always been open and we have always gladly given account to
people who contributed.
marcus
Wednesday, December 12, 2007, 11:45:23 AM, you wrote:
Surely the noise coming from outside are people's valid opinions? I mean
it's the people making the noise who have to live with decisions made on
the internals list, on a daily basis, and for most there income depends
on it.
It's not just php you're discussing, it's thousands of developers
working environment.. think of changes like this as somebody coming in
and cleaning your pc and files structure up for you, yeah they're trying
to help, but you had your files where you wanted them already..
No Offense and agreed on the spam issue!
Nathan
Jani Taskinen wrote:
Nice to hear some work is done but I get very annoyed every time I see
the words "behind the scenes" (or something alike). I guess it was
because it's impossible to discuss anything on internals without the
noise coming from "outside"..? Could we finally make this list read-only
for every one but the @php.net people? I get enough spam already, spam
from this list is not something everyone should suffer from.
--Jani
On Tue, 2007-12-11 at 17:13 -0600, Gregory Beaver wrote:
Hi,
I've been furiously working behind the scenes with Stas and Dmitry, and
have some enhancements to namespaces in the form of 2 patches.
1) multiple namespaces per file
2) use ::name;
1) multiple namespaces per file
This is implemented as such:
<?php
namespace one;
use Blah::A;
// code
namespace two;
use Foo::A;
?>
The example above shows that imported names are reset at each namespace
declaration. There is no prohibition on this code:
<?php
namespace one; {
use Blah::A;
// code
}
namespace two; {
use Foo::A;
// code
}
?>
Users who wish to use brackets may do so. The performance penalty
imposed by using brackets is minor for some cases, and for users who are
following the recommended practice of 1 namespace per file, the syntax
is ideal.
Patch is:
http://pear.php.net/~greg/namespace/PHP_5_3/multi.patch.txt
http://pear.php.net/~greg/namespace/PHP_6_0/multi.patch.txt
Note that non-namespaced code cannot be present in a file containing
namespaces. For users who are bundling, this will mean you will need to
create 2 files, one with non-namespaced code, and one with namespaced
code. This minor prohibition is a design decision, not a technical
problem in the implementation.
2) use ::name
This code:
<?php
namespace Whatever;
use MDB2; // import PEAR's ::MDB2 from global scope
$a = MDB2::connect();
?>
is currently impossible, which will make namespacing old code harder.
The patch introduces this new syntax to import names from the global
namespace:
<?php
use ::MDB2, ::strlen as len;
?>
http://pear.php.net/~greg/namespace/PHP_5_3/use.patch.txt
http://pear.php.net/~greg/namespace/PHP_6_0/use.patch.txt
These patches are for review of both serious technical and serious
implementation issues. In order to help move things along, I'd like to
define "serious" as something directly related to the implementation
that would cause a failure in PHP's ability to run scripts
deterministically, or some kind of memory leak/crash.
commit is planned for the next 24 hours or so, but of course any issues
found in review can be fixed. The patches are short, so in the worst
case, reverting is not difficult.
Thanks,
Greg
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
