2012/7/28 Rasmus Lerdorf <ras...@lerdorf.com>:
> 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.
I think I remember that. I hated how it was done in Perl and I loved it in PHP.
> 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.
Well. I think you're right, saying this is not technical but
philosophical. So I will put aside all my technical arguments, because
they won't bring us further here.
>From the sight of now we can say arrays like in PHP have been a good
concept. But in 1994 I must say, that was a brave decision!
So the question is: Can we say this for functions, too? What will we
say over those "functions" in 2030?
Thinking this from all sides I must admit, that you're right. Some
details of my thinking:
- There will be more than generators and such stuff, which - with the
same technical reasons - will also need new keywords. And this in the
end ugly.
- In the long run, it always was a good idea to introduce as few as
possible new language constructs, because it is easier to remember.
- You will then programm without an IDE only in very rare cases.
- Programmers will be used to it over time.
BTW: This thinking brought me to other aspects, but that's another mail.
And I have something on my mind, I can't forget: How can we reduce the
fuckuops in the beginning as much as possible?
Docs - ok! But I always come back to the same thinking: Is it enough?
And I think not in this case, because of the big difference between
now and then. It's a difference if you introduce a new thing in the
beginning or after 18 years.
Hm. I know, some will say "not again", but how about an *optional*
keyword? This follows also some "standards" in PHP (thinking of
"static", "public" etc. which are also "some kind of optional", so we
know that concept already).
Optional keywords are also used in SQL, where it helps to make a query
more self-descriptive. Not more or less should it be here.
How it works: PHP will warn (E_STRICT) if using a function as
generator without that optional keyword. Maybe it's possible to turn
that feature off, if you don't like that and in future the default
warning is removed. From aspect of parser the keyword "generator" will
have no implications (handled like a comment), because it will only be
a keyword, if "function" follows.
Suggested syntax will look like this:
[generator] function bla() { ... yield ...}
I think this could help to remove some of the ugliest fuckups, when
introducing it. And - this is my secret hope :) - this will kill the
need for discussion of this *now*. The future will show us, if this is
accepted/needed or not. Because who knows? This gives also more
options for the future and is in my eyes good design.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
