Hi Greg,
At least your patch is incomplete.
Even it handles stream wrappers in include(), include_once() it doesn't
handle them in fopen() and some other functions.
In general I like the idea, so I'll look how to extend the support.
Thanks. Dmitry.
Gregory Beaver wrote:
Hi,
I found some
Hi Greg,
I've fixed your patch to work with all functions (fopen, file_get_contente).
Please verify it with ext/phar and then I'll commit it.
Thanks. Dmitry.
Gregory Beaver wrote:
Hi,
Please look at the stream wrappers in include_path patch I posted last week.
Thanks,
Greg
Index:
On 03/18/2008 06:51 AM, Stephen Bach wrote:
Attached is a simple proposed patch that fixes Bug 43477. Basically, the code
that set the error mode of the ICU converter was giving it an instruction
(the context parameter) to only skip or substitute if the code point was not
represented in the
On 21 Mar 2008, at 12:09, Antony Dovgal wrote:
On 03/18/2008 06:51 AM, Stephen Bach wrote:
Attached is a simple proposed patch that fixes Bug 43477.
Basically, the code
that set the error mode of the ICU converter was giving it an
instruction
(the context parameter) to only skip or
On 03/21/2008 06:28 PM, Geoffrey Sneddon wrote:
Patch committed, thanks.
Can we test U_CONV_ERROR_SUBST too? See attached patch. Also, the bug
should be closed.
The patch breaks the test.
Can you guys decide on what should work and how, I'll commit the patch
afterwards, ok?
--
Wbr,
On Fri, 21 Mar 2008, Stanislav Malyshev wrote:
You can't actually use the class name DateFormatter when you want
pecl/intl to be in core. Date is the prefix for the already existing Date
extension.
I think we still can name it DateFormatter, especially if we plan (and we do,
as I
Hello,
I'm currently fooling around with the new namespaces feature. Is
there any (semi) official documentation when to use use or import.
use Foo;
Warning: The use statement with non-compound name 'Foo' has no effect
in. Is there any additional information.
cheers
*.sebastian
--
PHP
On Fri, Mar 21, 2008 at 5:36 PM, Sebastian Deutsch
[EMAIL PROTECTED] wrote:
Hello,
I'm currently fooling around with the new namespaces feature. Is
there any (semi) official documentation when to use use or import.
use Foo;
Warning: The use statement with non-compound name 'Foo' has no
Dmitry Stogov wrote:
Hi Greg,
I've fixed your patch to work with all functions (fopen,
file_get_contente).
Please verify it with ext/phar and then I'll commit it.
Thanks. Dmitry.
Gregory Beaver wrote:
Hi,
Please look at the stream wrappers in include_path patch I posted
last week.
I admit to being unclear on why DateFormatter conflicts with Date. I'll have to
read the manuals later. Seems rather limiting if all names beginning with
Date are now verboten. That said:
A) Derick, Shifu, Can you (or anyone) demonstrate the name conflict? I think it
should have been caught by
On Fri, Mar 21, 2008 at 6:01 PM, Tex Texin [EMAIL PROTECTED] wrote:
I admit to being unclear on why DateFormatter conflicts with Date. I'll have
to read the manuals later. Seems rather limiting if all names beginning with
Date are now verboten. That said:
A) Derick, Shifu, Can you (or
On Fri, 21 Mar 2008, Tex Texin wrote:
I admit to being unclear on why DateFormatter conflicts with Date.
I'll have to read the manuals later. Seems rather limiting if all
names beginning with Date are now verboten. That said:
A) Derick, Shifu, Can you (or anyone) demonstrate the name
Gregory Beaver wrote:
Dmitry Stogov wrote:
Hi Greg,
I've fixed your patch to work with all functions (fopen,
file_get_contente).
Please verify it with ext/phar and then I'll commit it.
Thanks. Dmitry.
Gregory Beaver wrote:
Hi,
Please look at the stream wrappers in include_path patch I
In this case, all of the classes in pecl/intl should start with Intl.
IntlMessageFormatter is a pretty sucky name... But maybe if we don't
have another bright idea I guess that'd be the way to go. Pity we didn't
figure it out earlier in the loop, but I'm guessing it should not be too
hard to
All functions in pecl/intl should therefore be named intl_foobar() and
classes intlFooBar in theory.
Well, intl module as I mentioned is a bit different - it has functional
parts which could be in fact separate extensions, but for practical
reasons aren't. So leaving aside the collision with
On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] wrote:
On Fri, 21 Mar 2008, Stanislav Malyshev wrote:
You can't actually use the class name DateFormatter when you want
pecl/intl to be in core. Date is the prefix for the already existing
Date
extension.
I
Thanks Stas. Yes, it was because the INTL extension included unrelated modules,
that we opted out of the extension naming.
Besides the formatters we have graphemes and unicode normalization functions.
I don't see that we have an actual collision here, so I would be inclined to
keep things as
Hi!
I rather prefer to have this class (and related) within the ext/date
extensions. It is the only way to have a consistent and working
date/time API in php. Date/time formatting is part of this API.
That'd be kind of hard to do because it uses ICU infrastructure, which
would create
Hello Stanislav,
no, instead I think everything in those exts should have intl_ or Intl as
prefix. That works for Spl and SplTypes pretty well where I use Spl prefix
in SplTypes as well.
marcus
Friday, March 21, 2008, 6:52:52 PM, you wrote:
All functions in pecl/intl should therefore be
Hello Stanislav,
Friday, March 21, 2008, 6:50:53 PM, you wrote:
In this case, all of the classes in pecl/intl should start with Intl.
IntlMessageFormatter is a pretty sucky name... But maybe if we don't
have another bright idea I guess that'd be the way to go. Pity we didn't
figure it
Did you experiemnt with namespaces?
No, the reason is ext/intl should work with 5.2.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hello Stanislav,
thanks for rewriting this.
Friday, March 21, 2008, 6:57:40 PM, you wrote:
Hi!
Forwarding this mail again since apparently many people missed it
previously. Please discuss.
Original Message
Subject: short_open_tag
Date: Fri, 07 Mar 2008 12:45:59
no, instead I think everything in those exts should have intl_ or Intl as
prefix. That works for Spl and SplTypes pretty well where I use Spl prefix
in SplTypes as well.
Well, in date manual as I can see there are 2 prefixes: date_ and
timezone_. And in SPL there are non-prefixed iterators,
Hello Stanislav,
and there is no chance to wait?
Friday, March 21, 2008, 7:25:44 PM, you wrote:
Did you experiemnt with namespaces?
No, the reason is ext/intl should work with 5.2.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829
Hello Stanislav,
Friday, March 21, 2008, 7:31:59 PM, you wrote:
no, instead I think everything in those exts should have intl_ or Intl as
prefix. That works for Spl and SplTypes pretty well where I use Spl prefix
in SplTypes as well.
Well, in date manual as I can see there are 2 prefixes:
and there is no chance to wait?
To wait for? 5.2 is out there, and there are a lot of people needing
intl support. We are working on this project for almost a year now, so
we want to make a release. Of course, 1.0 is not the end of story, and
we are very much intending to work further, but
Hi,
Stanislav Malyshev wrote:
All functions in pecl/intl should therefore be named intl_foobar()
and classes intlFooBar in theory.
Well, intl module as I mentioned is a bit different - it has
functional parts which could be in fact separate extensions, but for
practical reasons aren't. So
Then the name of the extension is wrong.
Well, that's what we could do. You are welcome to propose a better one :)
But this way we get an overflow of prefixes. And I'd prefer grouped
functionality to share prefixes.
We don't have any limit on how many prefixes we can have, so I don't see
Couple quick questions.
1 - Is this the right list for extension developers?
2 - If #1 is no, what is the correct list?
3 - If #1 is yes, see the following.
a - In an extension's init function, is it possible to get the
values of SERVER_NAME, SERVER_PROTOCOL, and SERVER_PORT? If so,
Hi!
For me the largest issue is infact late enabling of short tags at run time.
The issue tracks down to the issue where peole might use code that enables
short open tags but forgets to disable that. Now why might I rely on short
I think this case is very unlikely. The use case for this
Stanislav Malyshev kirjoitti:
I think this case is very unlikely. The use case for this feature is
template system, written in long-tags style, but using short-tags
notation for PHP templates. To compare:
My name is ?= $name ? and I am ?= $age ? years old.
My name is ?php echo $name; ? and I
I'd rather see ?php= than having this whole short_open_tag thing at all.
Does ?php= work? I though echo shortcut works only with short tags.
?php= is not much worse than ?= so it'd be OK with me. Downside would
be template systems couldn't use it until 5.3 is widely deployed - which
means no
Hello Stanislav,
Friday, March 21, 2008, 8:11:04 PM, you wrote:
Hi!
For me the largest issue is infact late enabling of short tags at run time.
The issue tracks down to the issue where peole might use code that enables
short open tags but forgets to disable that. Now why might I rely on
Hello Stanislav,
Friday, March 21, 2008, 8:37:18 PM, you wrote:
I'd rather see ?php= than having this whole short_open_tag thing at all.
Does ?php= work? I though echo shortcut works only with short tags.
?php= is not much worse than ?= so it'd be OK with me. Downside would
be template
On Fri, Mar 21, 2008 at 8:37 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
I'd rather see ?php= than having this whole short_open_tag thing at all.
Does ?php= work? I though echo shortcut works only with short tags.
?php= is not much worse than ?= so it'd be OK with me. Downside would
The first hits explain quite well why short_open_tag is bad, mmkay.
OK, let's see what we have there:
0. Support for my email, skipping.
1. The web is a rapidly changing market and standards are being
activley evolved. ?php is more compatable with standards on the web
than ? ... and its not
The main reason is that they are not valid processing instructions.
See http://www.w3.org/TR/REC-xml/#sec-pi
Great, they are also probably not valid S-expressions and not valid
phrases in Mandarin. Why they are bad because of that? Is there any
requirement for them to be?
--
Stanislav
However the '?echo' I mentioned would work. We could also go for something
like '?phpecho'. I for one would really appreciate it. And I would not
?phpecho is too long. Really, saving one space here isn't worth a
trouble. If we had something short and nice like ?= that'd be good and
would make
On Fri, Mar 21, 2008 at 9:02 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
No explanation why it shows lazyness or why it's bad except for
hinting it's somehow bad for handling XML (which it isn't).
See below.
Should I go deeper? Did we use the same search engine? I'm still missing
Hello Stanislav,
Friday, March 21, 2008, 9:05:17 PM, you wrote:
The main reason is that they are not valid processing instructions.
See http://www.w3.org/TR/REC-xml/#sec-pi
Great, they are also probably not valid S-expressions and not valid
phrases in Mandarin. Why they are bad because of
Nobody can set memory_limit in a script during runtime. AFAICT.
Why? It's INI_ALL. So is, for example, include_path.
Short tags are language SYNTAX issue. That's why it's different.
You don't get any plain error if they're on and something doesn't work.
It just doesn't work or misbehaves.
I gave you the link to one main explanation, the XML specs. Or what
else do you need to explain the problem in the XML context?
I need to explain why XML specs have any relevance to PHP syntax and why
PHP sources should conform to them. Are we coding in XML now? Is
everybody using an XML
Great, they are also probably not valid S-expressions and not valid
phrases in Mandarin. Why they are bad because of that? Is there any
requirement for them to be?
The argument being?
Why they are bad because of that? Is there any requirement for them to be?
--
Stanislav Malyshev, Zend
Hello Stanislav,
Friday, March 21, 2008, 9:08:02 PM, you wrote:
However the '?echo' I mentioned would work. We could also go for something
like '?phpecho'. I for one would really appreciate it. And I would not
?phpecho is too long. Really, saving one space here isn't worth a
trouble. If we
On Fri, Mar 21, 2008 at 9:05 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
The main reason is that they are not valid processing instructions.
See http://www.w3.org/TR/REC-xml/#sec-pi
Great, they are also probably not valid S-expressions and not valid
phrases in Mandarin. Why they are
Hello Stanislav,
lemme think, PHP is used to generate HTML and XHTML. And often people
have the headers outside of the PHP tags. And some people like to use tools.
But maybe I am wrong. Either way. It appears that nearly every single
person replying is against this. So can we please stop
The thing is that ?php echo would require a ; while ?phpecho wouldn't.
And if you ronly argument is saving a few keystrokes then we should really
get rid of short open tags completely. And definitively not making their
use easier.
It is easier to use templates with ?= ? then with full PHP
PHP works more and more in a multi cultural environment (php, jsp,
xml, etc.). One of the goals of a standard is to avoid conflicts,
Great. So let's see when there could be a conflict. Only way there could
be a conflict is when XML is included as PHP source. Now, how frequently
one really
There is also an issue when I want to verify my stuff using XML tools.
One can't really verify PHP code with XML tools, so what exactly are you
verifying - could you explain more on that?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829
Hello Stanislav,
since when can I not verify that my general HTML/XHTML structure is valid?
This is especially valid in template systems as you mentioned earlier.
Because in fact PHP is a tmeplate system for HTML/XHTML after all. So as
long as I only do easy stuff and avoid generating tags
Hi!
since when can I not verify that my general HTML/XHTML structure is valid?
The question is since when PHP code has any XML structure?
This is especially valid in template systems as you mentioned earlier.
OK, so you are verifying templates. Great. Obviously, if you use XML
On Fri, Mar 21, 2008 at 8:11 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
And if you look at the discussion, there were opinions - including
Zeev's - that there's nothing wrong with shorts tags in general, only in
some rare use cases.
http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262r2=1.263
guess who made that commit...
I wish I remembered what the rationale for that was, but of course I
don't. Anyway, in 7 years there might be a bit of a change in how people
use PHP, and that of course doesn't support the point
On Fri, Mar 21, 2008 at 10:19 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262r2=1.263
guess who made that commit...
I wish I remembered what the rationale for that was, but of course I
don't. Anyway, in 7 years there might be a
Hello Stanislav,
Friday, March 21, 2008, 10:11:24 PM, you wrote:
Hi!
since when can I not verify that my general HTML/XHTML structure is valid?
The question is since when PHP code has any XML structure?
This is especially valid in template systems as you mentioned earlier.
OK, so you
Yeah, there has been a huge change. A good chunk of that change is XML.
XML as parsing XML and working with DOM, not XML as putting XML
through PHP parser. It is very important to understand that no short
tags would ever cause you any problems with any XML *unless* you put
that XML through
Hello Stanislav,
Friday, March 21, 2008, 10:19:19 PM, you wrote:
http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262r2=1.263
guess who made that commit...
I wish I remembered what the rationale for that was, but of course I
don't. Anyway, in 7 years there might be a bit of a change
This was discussed several times already and Pierre put you directly onto
its definition. What more can we say? I think we have a valid technical
You obviously think so, but it doesn't automatically makes it valid.
Explaining again: PHP code needs to conform to XML standard *only* if
you have
But maybe the change is that now it is considered evil by an even larger
amount of people.
So far I saw four. I do not double I can find 5 people that like
templates with short tags. But anyway it doesn't matter much because
short tags are in PHP 5 and not going anywhere. So the question is
Hello Internals,
we all were asked to stop discussing syntax of namespaces as we were told
that we would decide after the namespace functionality was fully implemented.
Now I think that the functionallity is pretty much settled we should
revisit the syntax. We all have been very patient so far.
Hello Stanislav,
Friday, March 21, 2008, 9:37:51 PM, you wrote:
lemme think, PHP is used to generate HTML and XHTML. And often people
Neither of which require ?. HTML in fact doesn't support it even.
have the headers outside of the PHP tags. And some people like to use tools.
But maybe I
I haven't seen a single technical argument from your side.
That's just hilarious. I spend entire half-day repeating arguments about
XML and short tags and templates and users and what not - but why bother
if Marcus doesn't even read it? Well, I hope at least somebody reads it.
As for trying
Hello Stanislav,
well, any XML tool seeing '?=' or '? ' would error out as that is
invalid XML.
Friday, March 21, 2008, 10:26:52 PM, you wrote:
Yeah, there has been a huge change. A good chunk of that change is XML.
XML as parsing XML and working with DOM, not XML as putting XML
Marcus Boerger wrote:
Hello Internals,
we all were asked to stop discussing syntax of namespaces as we were told
that we would decide after the namespace functionality was fully implemented.
Now I think that the functionallity is pretty much settled we should
revisit the syntax. We all
Take this file:
?xml version=1.0 encoding=utf-8 ?
foo
? echo bar; ?
/foo
and run it through xmllint.
Can we now stop this discussion and revert this patch?
Take this file:
?xml version=1.0 encoding=utf-8 ?
foo
?php echo bar; ?
/foo
and run it through your xmllint.
Passes right? Does
On Sat, Mar 22, 2008 at 12:51 AM, Ralph Schindler [EMAIL PROTECTED] wrote:
Take this file:
?xml version=1.0 encoding=utf-8 ?
foo
? echo bar; ?
/foo
and run it through xmllint.
Can we now stop this discussion and revert this patch?
Take this file:
?xml
On Sat, Mar 22, 2008 at 12:46 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
I often use xmllint or other w3c tools to verify that my xml/xhtml
code is valid, before being parsed by php:
Right, so _you_ are using XML templates. Don't do short tags then. Many
other people, however, use
Hi Rasmus,
On Sat, Mar 22, 2008 at 1:20 AM, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
Will actually do about the same thing in the sense that the top-level
script can run with short_open_tag turned off and the main.php script
can run with short_open_tag enabled. The first version requires
Elizabeth M Smith wrote:
Wow, noisy...
I've been in the situation where I use php for templating and the short
syntax is much nicer on the eyes. The ability to flick the switch for
short tags would be nice.
However, like Steph, I've also been bitten by having a simple xml
declaration in a
-Original Message-
From: Pierre Joye [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 8:30 PM
To: Rasmus Lerdorf
Cc: Elizabeth M Smith; internals@lists.php.net
Subject: Re: [PHP-DEV] short_open_tag
Hi Rasmus,
On Sat, Mar 22, 2008 at 1:20 AM, Rasmus Lerdorf [EMAIL
Hi Andrés/Rob,
as usual my are playing up so I'll use ==
=
I'm new to the internals, but I've been reading you for months... now, let
me
ask,
Are there any security issues with short tags?
Is it really harder for the interpreter to have them enabled?
Is the short tags
71 matches
Mail list logo
