On Sep 9, 2008, at 6:22 PM, Stanislav Malyshev wrote:
.... if we cannot
We already have this serious flaw in our design. If we use "new Foo
()", and it's definition not included, it resolves differently
(namely, to fatal error) than if we had included the definition.
Also, with inheritance, if you include or define inherited classes
in wrong order - i.e. child before parent - you may get problem too.
You'd say this can be changed by autoloading, moving classes
around, etc. - but behavior you complain about can be changed
easily too, you just insist there would be no possible case,
however hard you try to make a mistake, to get different resolution.
make a performant solution in this case, we better have nothing.
I don't see how it's better to have nothing at all than a solution
that works in 99% of cases - unless you try on purpose to write
code that doesn't work. I also find it very strange that you and
other people are so insistent on having no namespace solution at
all. How that would help you? How that would make PHP better?
Let me advance an idea here, from somebody's who watched this issue
for a bit, if I may.
The idea is as follows: By writing one's *own* namespace-autoloader-
conceptual-framework (*cough*), there have been many, many, ideas
over the years and many, many implementations. Usually, the "correct"
one seems to be the one written by the developer arguing for their
specific variant. This is somewhat to be expected, as a decent amount
of ego often gets developers through the day.
At one time, this kind of cleverness often took the form of:
include($dynamic_location . $dynamic_filename);
Not too ugly... yet. Seems to make perfect sense. At first.
Lets add a few years, shall we?
foreach ($namespace as $dynamic_location => $dynamic_filename) {
include($dynamic_location . $dynamic_filename);
}
Not too shabby so far... until $namespace becomes an array with, say,
40 or 400 even 4000 entries, and somebody doesn't want to be
"hassled" with all that upkeep, and just wants "the computer" to fix
it. So they start getting "clever". They start expecting the language
to search through all 4000 locations (be they files or objects, or
*whatever*, it really doesn't matter), looking for the "right" thing
the developer wants. (I'd write meta-code for this, but my built-in
insanity over-ride precludes me from doing so.)
Where namespaces, indeed, where "dynamically loading code based on
arguments" has gone south for the last 40 years(!) is not because of
stubbornness, or because all-we-needed-was-another-language, or all-
we-needed-was-better-syntax-characters-in-a-language, but rather,
because it's a really, really, hard problem to "fix".
Conceptually, it's a really simple task to 'do what a programmer
wants'. Computationally, it's hard.
Analogy:
A small child leaves toys strewn all over the floor.
A few solutions:
1) Leave the floor as is.
The child will want some easier way of finding things, because
there's stuff all over the floor, and they're grabbing the wrong
thing all the time. They'll try to do their own organization, and
will fail, and succeed, in various ways.
If the child does not get what they want, the child pouts.
2) Place clearly colored buckets for specific kinds of toys about the
floor.
Eventually, the child wants different things in different buckets,
the same thing in multiple buckets, or things to only be in the blue
bucket after taking a toy from the red bucket.
If this does not happen, the child pouts.
3) Hire a full time nanny to constantly re-arrange toys in bins, and
buckets, and on shelves, to duplicate toys for them to be in multiple
locations, to constantly change and modify the toys themselves
depending on what the child has asked for.
When the child does not get what they want, because "the nanny is
slow", the child pouts.
Now, solution number 3 has sometimes worked for years, in *certain*
languages, where the nanny can be front-loaded into a compile phase
of some kind, so it's okay if 80 seconds are consumed by toy
management, or the language can dynamically create an toy-stack-of-
all-possible-combinations, according-to-rules, as a cost of severe
RAM and toy-stack persistence, and solution number 2 has a heavy
cost, and solution number 1 is where PHP is at in many ways.
...but the child will still pout.
The problem is not the toys, or how they are arranged, sorted,
managed, or manipulated.
-Bop
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
