-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Christian Schneider wrote:
William Candillon wrote:
I think that a macro will be a very nice and powerful solution to this
problem but according to me it needs to be done by an external tool.
That already exists ;-)
Try
cpp -w -P -C
Hello Christian,
first of all c would be enough. Preprocessing has nothing to do with c++.
Also a lot of compilers allow to use the pre-process stand alone. And then
there is this one little disadvantage. A c compiler doesn't know that it
is not supposed to deal with stuff outside ?php...? and
At 04:03 28/05/2006, Marcus Boerger wrote:
Hello Andi,
i for one think it might be a solution to at least lower the pain of
version differences.
It does look like a clear example of shooting one's head off over a
headache :) What Alan suggested does the job equally well without
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
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
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
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
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
}
It would be nice to back port this to PHP4, but at least make the
On 5/26/06, Alan Knowles [EMAIL PROTECTED] wrote:
Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?
The most important point to discuss for any BC break is about why
introduce it. Purity and OO compliance are not
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
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
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
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
13 matches
Mail list logo
