Re: [PHP-LANG] "Mission Statement"
[email protected] (Sascha Schumann)
| Newsgroups | php.lang |
|---|---|
| Message-ID | <[email protected]> |
> I'm not worried - I don't see the point in aiming at a document that would
> help forks, though. Forks are not such an unlikely thing to happen (e.g.,
> that GPL fanatic guy that mailed group@ the other day). I'm not really
> worried about him, but I sure don't want to help him breaking PHP up.
Well, I don't favor the Microsoft way of raising the barrier
for competition arbitrarily.
In the remote case that someone forks PHP, it should be in
our interest to convince the community that there is an open
independent group of well-known people who maintain control
over the language evolvement.
We are now in a position where we can set the standard for
PHP. In the long run, this will help us to convince users of
the continuity of PHP. We cannot ensure that with the current
structure where the term "PHP language" is defined in the
context of the respective implementation.
In the short to mid term, there are a couple of interesting
projects which are currently virtually impossible to do
because of the lack of a PHP language standard (i.e. a gcc
front-end; engine with coroutines). Those projects would
ultimately benefit PHP and that is why I'm pushing this.
> I don't know really, I haven't studied languages history. I know that what
> the users would want is a user-oriented document, and not a
> compiler-spec. A compiler spec will probably not be too harmful (even
> though it'll encourage forks, to some degree), but I agree with Rasmus that
> this should not be the main concern of this forum.
Well, as the guy who created the mailing list ;-), I can
savely assert that my main concern was never documenting a
particular implementation.
> > I agree with you that diversity of the PHP language is bad.
> > That is why I'm here and proposing a standardization effort
> > for the language we know as PHP. We cannot prevent forks,
> > but we can prevent diversity.
>
>
> I suggest we give it a start and see how it goes. This usually proves to
> be the best approach, instead of discussing theocratically in advance...
Well, we should agree on the structure of this approach.
IMHO, The PHP Language Specification must not contain
implementation details.
Based upon that, there can be a separate document detailing
implementation-dependent behaviour.
What do you think of that?
- Sascha