Hello Andi,
i for one think it might be a solution to at least lower the pain of
version differences. Which is the reason why i liked the proposal from
the beginning and took mentorship.
best regards
marcus
Sunday, May 28, 2006, 2:39:21 AM, you wrote:
> 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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
