Ryan Panning wrote:
Jessie Hernandez wrote:
Hi Stan,
I made a proposal and patch a few months ago...
The developers should really take a serious look at this issue or it
will come back to haunt them later. I'm not sure why no one seems
comment on your proposal and patch. It seemed like
Nathan Rixham wrote:
Ryan Panning wrote:
Jessie Hernandez wrote:
Hi Stan,
I made a proposal and patch a few months ago...
The developers should really take a serious look at this issue or it
will come back to haunt them later. I'm not sure why no one seems
comment on your proposal
On Fri, May 16, 2008 at 4:51 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
Nathan Rixham wrote:
Ryan Panning wrote:
Jessie Hernandez wrote:
Hi Stan,
I made a proposal and patch a few months ago...
The developers should really take a serious look at this issue or it
will come back to
Hi,
I'd like to nudge the discussion back to issues with the resolution rules
that we're discovering :)
The actual char(s) used can only be mildly annoying to some (at worst),
compared.
Can we please agree on those (or explain why you'd not):
1) functions, constants and classes should use
Stan Vassilev | FM wrote:
Hi,
I'd like to nudge the discussion back to issues with the resolution
rules that we're discovering :)
The actual char(s) used can only be mildly annoying to some (at worst),
compared.
Can we please agree on those (or explain why you'd not):
1) functions,
is it too late to scrap all this and go with Java/AS3 style
base.package.class please?
Is it too late to switch to Java/AS3? ;)
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime
Hi!
1) functions, constants and classes should use the same resolution
rules. Making special cases just for some of them, or just for user or
just internal ones will lead to confusion.
No, not necessarily. Functions, constants and classes have different
traditional usage patterns in PHP,
Hi!
$classes = ::get_declared_classes();
$classes = ::array_merge($classes, ::get_declared_interfaces());
$this-classes = ::array_flip($classes);
unset($this-classes['NSParser::Parser']);
$functions = ::get_defined_functions();
$this-functions =
Stanislav Malyshev wrote:
Hi!
$classes = ::get_declared_classes();
$classes = ::array_merge($classes, ::get_declared_interfaces());
$this-classes = ::array_flip($classes);
unset($this-classes['NSParser::Parser']);
$functions =
Stanislav Malyshev wrote:
is it too late to scrap all this and go with Java/AS3 style
base.package.class please?
Is it too late to switch to Java/AS3? ;)
Already have switched front end design to flex3/as3 which is why I'm
asking :o)
Nath
--
PHP Internals - PHP Runtime Development
Hi,
No, not necessarily. Functions, constants and classes have different
traditional usage patterns in PHP, and as such may have resolution rules
that follow these patterns. I don't say we should look for making them
different, but if necessary, we should use rules that benefit the most
Hi!
Trying to fudge the behavior of PHP to fit some kind of presumed usage
patterns is what got us features like magic quotes and register globals.
You sound like these usage patterns are figment of my imagination. They
are not. As for magic quotes and register globals, I understand that's
internal or user. But in namespace context I'll have to do something
along the lines of:
if (function_exists('json_encode')) {
$encoded = json_encode($raw);
} else {
$encoded = ::json_encode($raw);
}
What this code is supposed to do? If it's supposed to call namespace's
json_encode in
Hi!
But inside a namespace, you'll need to do the above checks since
internals and user functions don't resolve under the same rules.
No, not really - just use:
$encoded = ::json_encode($raw);
It might be even possible to allow something like:
use ::json_encode;
to allow you to write just
Hi Stan,
I made a proposal and patch a few months ago at
http://news.php.net/php.internals/34097, which Julian later adapted to a
more recent version of PHP 5.3 at the time at
http://news.php.net/php.internals/36822 (don't know if the patch still
applies cleanly).
Unfortunately I haven't
15 matches
Mail list logo
