On October 17, 2002 06:21 pm, Andi Gutmans wrote:
> It's not safe against something stupid like:
> <?xml . foo() ?>
Okie, point made, there will be that one or more users who will be affected by
this patch in a negative way. However, I think you'll agree with me that
those users are doing something out of the ordinary. My proposal is a VERY
DIRTY hack, but it's a hack that'll solve a problem for 99% of the users.
Quite frankly, if I were in your shoes I am not sure I'd accept this hack
myself.
Adding an ini option IMHO is a very bad idea, because it opens the door to
various other engine hacks, which in the end may lead to ini file looking
like
xml_hack=no
case_sensetivity_hack=yes
multibyte_hack=yes
and so on.
If it is all the same to you, I would rather see my patch rejected then added
with an ini setting.
Ilia
> Yes you can say it's stupid but this is what I could think of now and it's
> a valid PHP statement. This patch would add ambiguity to the language.
> We could have an INI directive such as xml_hack=on but I hate adding INI
> stuff too.
>
> I suggest people who are generating XML just turn off short-tags.
>
> Andi
>
> At 06:17 PM 10/17/2002 -0400, Ilia A. wrote:
> >On October 17, 2002 06:03 pm, Andi Gutmans wrote:
> > > This is definitely one thing to think about. This is exactly the reason
> > > why I was against in the beginning. I had a feeling such ambiguities
> > > could arise.
> >
> >The latest incarnation of the patch I am attaching below is 'safe' against
> >the
> >problem demonstrated by Rasmus.
> >
> >Ilia
> >
> > > Andi
> > >
> > > At 09:43 AM 10/17/2002 -0700, Rasmus Lerdorf wrote:
> > > >My main worry with such a hack would be breaking a script like this:
> > > >
> > > > <?php
> > > > function xml() {
> > > > echo "Hello World";
> > > > }
> > > > ?>
> > > > ...
> > > > <?xml ()?>
> > > > ...
> > > >
> > > >Now, people generally don't put spaces between the function name and
> > > > the (), but it is a BC concern since the above script works just fine
> > > > today.
> > > >
> > > >One idea would be to only strip <?xml tags up until we see the first
> > > > PHP tag. That should cover most cases, but it may be a bit too
> > > > magical.
> > > >
> > > >-Rasmus
> > > >
> > > >On Thu, 17 Oct 2002, Andrei Zmievski wrote:
> > > > > They are _not_ the same person!
> > > > >
> > > > > On Thu, 17 Oct 2002, Zeev Suraski wrote:
> > > > > > Well, I differ with you on that. I don't think there's anything
> > > > > > in the same class as <?xml.
> > > > > >
> > > > > > Zeev
> > > > > >
> > > > > > At 18:08 17/10/2002, Andi Gutmans wrote:
> > > > > > >I don't think we should add special hacks to the scanner. Soon
> > > > > > > we're
> > > >
> > > > going
> > > >
> > > > > > >to have a zillion hacks for other XML/SGML/foobar documents.
> > > > > > >
> > > > > > >Andi
> > > > > > >
> > > > > > >At 12:17 PM 10/16/2002 -0400, Ilia A. wrote:
> > > > > > >>Since the general consensus by the developers is not to remove
> > > > > > >> the short_tags
> > > > > > >>or even disable them. Perhaps we should consider alternate
> > > > > > >> solutions to this
> > > > > > >>problem. Given the buzzword popularity of XML and its slowly
> > > > > > >> growing popularity among website designers (XHTML) this issue
> > > > > > >> is likely to come up in
> > > > > > >>the future yet again.
> > > > > > >>The solution I would like to offer, is a patch that adds
> > > > > > >> special
> > > >
> > > > handling
> > > >
> > > > > > >>for
> > > > > > >><?xml. Thus preventing the language parser from attempting to
> > > > > > >> parse
> > > >
> > > > data
> > > >
> > > > > > >>inside <?xml as PHP source.
> > > > > > >>
> > > > > > >>Ilia
> > > > > >
> > > > > > --
> > > > > > PHP Development Mailing List <http://www.php.net/>
> > > > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > > >
> > > > > -Andrei
> > > > > http://www.gravitonic.com/
> > > > >
> > > > > "Claiming Java is easier than C++ is like
> > > > > saying that K2 is shorter than Everest."
> > > > > -- Larry O'Brien (editor, Software Development)
> > > > >
> > > > > --
> > > > > PHP Development Mailing List <http://www.php.net/>
> > > > > To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
