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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.