I think a preprocessor is one of the worst things that can ever happen to PHP.
It can be done as a Summer of Code project for academic reasons but I
would never be in favor of adding it to PHP. I think there's very
little use in a language like PHP and it will lead to the same
maintenance/debugging problems as with C.
If someone really needs a pre-processor then they should use it in
their private environment and can even use cpp if they want.
I can't believe Marcus that you are in favor of something like this.
In any case, it doesn't matter. Nothing can stop the student from
doing something like this and dumping it in pecl or something, but
I'd never want to see a pre-processor in PHP itself.
Andi
At 03:19 PM 5/26/2006, Marcus Boerger wrote:
Hello Zeev,
actually there was plenty of discussion prior to selecting the summer
of code projects. Nonetheless we will see how it will work out. For example
#line <num> <source> can easily be aded to the lexer already and doesn't
require a full blown preprocessor. Versioning is very different since it
should either be a real preprocessor and thus not doing any harm to php
or it is a language feature and then a bunch of stuff probably has to be
changed. Though maybe even then it is a simple additional state in the
lexer - those tools can be so easy.
Anyway you might want to contact the student.
marcus
Friday, May 26, 2006, 11:04:30 AM, you wrote:
> Yeah I heard, but it doesn't mean it'll become a part of the language
> (doesn't mean that it would not, but as usual, no discussion ;).
> What Alan suggested is already a part of the language, bares no
> additional overhead (both CPU cycles and brain cycles), and also
> (least important point) is very easy to implement.
> Zeev
> At 05:08 26/05/2006, Marcus Boerger wrote:
>>Hello Zeev,
>>
>> actually there is a student working on a pre-processor for his summer
>>of code project. And that will most likely cover versioning, too.
>>
>>best regards
>>marcus
>>
>>Friday, May 26, 2006, 4:06:00 AM, you wrote:
>>
>> > I read it as if it was declare() ;)
>>
>> > I agree with Pierre that the best way to handle BC break is not to
>> > introduce it, but since that's not always 100% possible, this may
>> > make sense. Of course, it'll only work with stuff that is
>> > syntax-compliant with the currently running PHP version, but that
>> > covers most BC breakage.
>>
>> > Zeev
>>
>> > At 04:57 26/05/2006, Alan Knowles wrote:
>> >>actaully it should have been declare() - as I think the syntax for that
>> >>almost works already, but yes, code doesnt get compiled if it's inside a
>> >>block.
>> >>
>> >>Regards
>> >>Alan
>> >>
>> >>Zeev Suraski wrote:
>> >> > At 03:57 26/05/2006, Alan Knowles wrote:
>> >> >> Can we start concentrating on finding a real solution to BC breaks
>> >> >> rather than throwing them out there and everyone complaining?
>> >> >>
>> >> >> define(php5) {
>> >> >> stuff that breaks in php6
>> >> >> }
>> >> >> define(php6) {
>> >> >> stuff that doesnt work in PHP5
>> >> >> }
>> >> >
>> >> > What's the semantics of that? The code inside doesn't get
executed if
>> >> > it's not the define()'d PHP version?
>> >> >
>> >> > Zeev
>>
>>
>>
>>
>>Best regards,
>> Marcus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
