On 07/26/2012 11:36 PM, Alex Aulbach wrote:
> 1) The bigger the language grows, the more we need to think about how
> to implement new features.
> I think it's a bad argument to say "we made this and that not so
> ideal, so we can make this also. Don't be so idealistic." :)
> I think it's a duty to make new things more logical and more
> self-explaining and more fitting into the rest. Always, and the bigger
> it is, the more it must be done.
> 
> 2) We should do things better, if we can.
> This opens two questions. First: Is a new keyword better than none,
> second: can we?

Both of these points essentially argue that naming the ordered maps
"arrays" in PHP was somehow not ideal and we (well, I in this case)
should have done better. I completely disagree. One of the strengths of
PHP is that it scales. It scales up to the largest sites in the world
while at the same time it scales down to weekend warriors. Doing both in
the same codebase is a challenge.

Scaling up is something very technical people like yourself understands
well. It is usually all about getting the architecture right and
removing global locks and other bottlenecks. However, scaling down is
not a technical problem but rather a philosophical one. It is about the
overall approach, coming up with ways to make complicated concepts
simple to understand, great documentation with simple examples and
presenting an approachable ecosystem which extends well beyond the
language itself.

Very early versions of PHP v1 actually had distinct list, map and set
implementations but I replaced those early on with a unified hybrid
ordered map implementation and just called it the "Array" type. The
thinking was that in almost all situations in a Web app, an ordered map
can solve the problem. It looks and acts enough like an array that it
can be used in situations that call for an array and it eliminates the
problem of presenting the user with 3 or 4 types and related keywords
and syntax that forces them to try to figure out which one to use when.
This decision was made in 1994 and apart from a few pedantic naming
complaints over the years, I think this particular decision has stood
the test of time.

I don't think this generator question is any different. We need to
explain generators in the simplest way possible. The simplest way to
explain generators is to not even worry about them being generators at
all. Simply say that functions can now return arrays one element at a
time using the new yield keyword. That's all.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to