[<[EMAIL PROTECTED]>]
> Hi,
>
> About the language specification project:
>
> >The goal I see for this project is coming out with a document that is
> >useful for users. Something that they could hold in their hands, and from
> >reading it, they'd know whether something is supposed to work or not. Now,
> >I'm sure that it's possible that during the course of the project we'll
> >find inconsistencies in the implementation that need to be fixed, but as a
> >guideline the spec should describe the implementation. We really don't
> >need the kind of stuff that were with C++, with 80% conformance and 99%
> >conformance and all that headache.
> >
> >--
> >
> > I agree, in part. I think however we should document the syntax as it
> >"ought to be", ie, some of the stuff is not yet realized like what sascha
> >was reffering to as far as the zend-cvs discussion (which I didn't really
> >follow too well). Or, obviously, bugs should not be at all considered in
> >the specification itself.
>
> (discussed mid-november 2000)
>
> This project seems rather dead to me. Though, I think it should be
> continued. Some work was alread been done.
>
> I would like to try to reanimate it. I think, like Sacha I think, that a
> spec should be quite exact and precise.
> Zend was made without a proper specification, something they try to hammer
> all first-year students at my university you should NEVER do that.
>
> It is very annoying to have to specify all quirks, I think it is most
> practical to document it the way it should be, and then note whereever it
> goes wrong.
>
> Most of these 'where it goes wrong's are in fact quirks, that normal users
> shouldn't meet, and if they do, it works so strange, it can't be documented
> in a easy way.
>
> (what do you think of this one:
> $a[5] = 'abc';
> $foo = &$a[5];
>
> $b = $a; // should copy the array
> $a[5] = 'boe';
> echo $b[5]; // boe...
>
> Array elements that have a reference are not copyd, but a reference is
> made... bah!
> )
>
> And the target shouldn't be the user at first.
>
> Then, IMO the next step would be to make zend comply to the specs, finally
> making version 4.1 as some people seem to want.
> And THEN you can publish the spec. With the current quirky behaviour, PHP
> won't be seen as a well and neatly specified and LOGIC language, but rather
> as some potpourri (mixup) of other languages.
>
> But before I start, I want to know your opinions nowadays...
> And, I really need (=want) to know whether Zend WILL go comply to the new
> spec.
>
> About what the spec exactly will be: I, and anyone who wants, just make it
> based on their own views. First of course
> the framework should be made ready, so concurrent work can be done more
> easily. I think adapting a bit to the structure of the phpdoc documentation
> isn't such a bad idea.
>
> Regulary it is posted to phpdev, and then you can flame it, or whatever. And
> then some decission needs to be made, consensus seems hard, but hey, lets
> add the rule that if consensus isn't reached I'll decide ;)
>
> (by the way, I came onto this trying to document the language properly, but
> that is really hard to do... if you want it to have as exact as possible)
> (BTW2: zend-cvs discussion? where are the archives? and is there web-cvs for
> zend somewhere?)
>
> SUMMARY:
> - spec framework made (sacha?, myself?)
> - spec made, as how it should work, so close as possible to PHP, but in case
> of quirks, just a logic behaviour.
> (Anyone who wants. Myself included)
> WITH notes where zend does something strange.
> - extensive discussion on phpdev
> - zend adapted
> - spec published along with new version of PHP/zend
I think the important thing is just to have the language specified and
thoroughly documented, with BNF and all. Let quirks be quriks for
now, a specification process should not fix them, but put them all on
the radar for future fixing. There's always someone who relies on a
quirk. If you mix the spec/doc and fixing processes you're in deep
shit, that's something the first-year university students should
learn, too. ;-)
Anyway, this is a process Zeev & Andi would have to be deeply involved
in, even though I think it's best to have the actual writing done by
someone else, to have an extra "audit point" to come up with the
questions implementors sometimes forget.
On the other hand, Zeev and Andi may not want to prioritize their time
on this, since a real language specification would clear the path for
alternate parser implementations.
- Stig
--
Stig Sæther Bakken <[EMAIL PROTECTED]>
Fast Search & Transfer ASA, Trondheim, Norway
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
