Re: [PHP-DEV] short_open_tag

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 p

RE: [PHP-DEV] short_open_tag

> -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 <[EMAI

Re: [PHP-DEV] short_open_tag

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 fi

Re: [PHP-DEV] short_open_tag

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 requir

Re: [PHP-DEV] short_open_tag

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, howe

Re: [PHP-DEV] short_open_tag

On Sat, Mar 22, 2008 at 12:51 AM, Ralph Schindler <[EMAIL PROTECTED]> wrote: > > > Take this file: > > > > > > > > > > > > > > and run it through xmllint. > > > > Can we now stop this discussion and revert this patch? > > > > Take this file: > > > > "; ?> > > > and run it th

Re: [PHP-DEV] short_open_tag

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 fi

Re: [PHP-DEV] short_open_tag

Take this file: and run it through xmllint. Can we now stop this discussion and revert this patch? Take this file: "; ?> and run it through your xmllint. Passes right? Does that mean its valid xml/xhtml on the flip side? No, it wont pass. Is XML Spec compliancy a goal of the

Re: [PHP-DEV] short_open_tag

Please (OH! Please!!!) read our answers, read the specs and understand that many of us (if not the majority) have to work with xhtml or XML. Working with XML does not requires putting XML through PHP parser. Even if it did, with my patch it works better than without - it allows to have both HT

Re: [PHP-DEV] short_open_tag

On Fri, Mar 21, 2008 at 10:26 PM, Stanislav Malyshev <[EMAIL PROTECTED]> 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 > through PHP parser". Please (OH! Please!!!) read our answers, read

Re: [PHP-DEV] short_open_tag

On 21/03/2008, Elizabeth M Smith <[EMAIL PROTECTED]> wrote: > Wow, noisy... And having made the commit to the dox before the revert, I'm still reeling/reading to try and see which way I would go... > I'd argue that a the difference" between the ugliness of the long version and the need to > no

[PHP-DEV] Re: [RFC] Namespace syntax decision

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 a

Re: [PHP-DEV] short_open_tag

Elizabeth M Smith wrote: > I'd argue that a the difference" between the ugliness of the long version and the need to > not break php every time an xml declaration pops up in a file. +1 -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier Anti-XSS

Re: [PHP-DEV] short_open_tag

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 file with short tags on that

Re: [PHP-DEV] short_open_tag

Hello Stanislav, well, any XML tool seeing '> 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 pr

Re: [PHP-DEV] short_open_tag

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 t

Re: [PHP-DEV] short_open_tag

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 > have the headers outside of the PHP tags. And some people like to use tools. >> But maybe I am wrong. Either way. It appears tha

[PHP-DEV] [RFC] Namespace syntax decision

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.

Re: [PHP-DEV] short_open_tag

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 do

Re: [PHP-DEV] short_open_tag

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

Re: [PHP-DEV] short_open_tag

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.262&r2=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 c

Re: [PHP-DEV] short_open_tag

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 throug

Re: [PHP-DEV] short_open_tag

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, s

Re: [PHP-DEV] short_open_tag

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.262&r2=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 mig

Re: [PHP-DEV] short_open_tag

http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262&r2=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

Re: [PHP-DEV] short_open_tag

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

Re: [PHP-DEV] short_open_tag

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 templates

Re: [PHP-DEV] short_open_tag

Hi Stas, In 99.999% of cases you'd get parse error on first line of the file. I have yet to see any other context where short tags wouldn't work. So I don't see - what exactly would "not work or misbehave" without giving an error? Can you produce any example of application or other real code t

Re: [PHP-DEV] short_open_tag

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 insid

Re: [PHP-DEV] short_open_tag

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 MS

Re: [PHP-DEV] short_open_tag

Hello Stanislav, Friday, March 21, 2008, 9:32:48 PM, you wrote: >> 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 i

Re: [PHP-DEV] short_open_tag

lemme think, PHP is used to generate HTML and XHTML. And often people Neither of which require 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 s

Re: [PHP-DEV] short_open_tag

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 need

Re: [PHP-DEV] short_open_tag

The thing is that It is easier to use templates with then with full PHP syntax, they look cleaner. Just look how many other templates use "tag" syntax - either {SOMETHING} or <%= SOMETHING %> or some like that. Do you that's because they are too stupid or too lazy - or because they listen to

Re: [PHP-DEV] short_open_tag

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 arguing

Re: [PHP-DEV] short_open_tag

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 t

Re: [PHP-DEV] short_open_tag

Hello Stanislav, Friday, March 21, 2008, 9:08:02 PM, you wrote: >> However the '> like ' trouble. If we had something short and nice like would make PHP templates look clean, but doing http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

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 Softwa

Re: [PHP-DEV] short_open_tag

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 parse

Re: [PHP-DEV] short_open_tag

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.

Re: [PHP-DEV] short_open_tag

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 becaus

Re: [PHP-DEV] short_open_tag

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 missin

Re: [PHP-DEV] short_open_tag

However the ' trouble. If we had something short and nice like would make PHP templates look clean, but doing -- 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

Re: [PHP-DEV] short_open_tag

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 Malyshe

Re: [PHP-DEV] short_open_tag

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. than Then goes for "include XML as template" case. And Rasmus objecting t

Re: [PHP-DEV] short_open_tag

On Fri, Mar 21, 2008 at 8:37 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > > I'd rather see > Does be template systems couldn't use it until 5.3 is widely deployed - which > means no template system can use it as standard for about 2-3 years at > least. Unless we put but might be a

Re: [PHP-DEV] short_open_tag

Hello Stanislav, Friday, March 21, 2008, 8:37:18 PM, you wrote: >> I'd rather see Does be template systems couldn't use it until 5.3 is widely deployed - which > means no template system can use it as standard for about 2-3 years at > least. Unless we put but might be a trouble for others.

Re: [PHP-DEV] short_open_tag

Stanislav Malyshev kirjoitti: I'd rather see all. Does No, someone decided it shouldn't be added. least. Unless we put but might be a trouble for others. I wouldn't mind. Nor would couple of thousand other people. :) I'd even use it myself. But I will not EVER enable the damn short tags a

Re: [PHP-DEV] short_open_tag

Hi! But the non programmers don't understand either. And instea They do. "Non programmer" != "idiot". of promoting See my previous mail on that. That is more than 5 years ago though. OK, so? But I do not have to use something is no reason to add a function. I never brought it as a

Re: [PHP-DEV] short_open_tag

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

Re: [PHP-DEV] short_open_tag

I'd rather see Does be template systems couldn't use it until 5.3 is widely deployed - which means no template system can use it as standard for about 2-3 years at least. Unless we put but might be a trouble for others. I'd even use it myself. But I will not EVER enable the damn short tags

Re: [PHP-DEV] short_open_tag

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 and I am years old. My name is and I am years old. I'd rather see I'd e

Re: [PHP-DEV] short_open_tag

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 featur

[PHP-DEV] Extension Developer Questions

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, how?

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 an

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 leav

Re: [PHP-DEV] Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 pre

Re: [PHP-DEV] Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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-8

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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, A

Re: [PHP-DEV] short_open_tag

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

Re: [PHP-DEV] Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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: http

Re: [PHP-DEV] Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 i

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 na

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 dependen

[PHP-DEV] RE: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 the

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 > > > exten

[PHP-DEV] short_open_tag

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 -0800 From: Stanislav Malyshev <[EMAIL PROTECTED]> Hi! I wonder - is there a reason why short_open_tag

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 d

[PHP-DEV] Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

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 pos

RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 nam

Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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

RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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 b

Re: [PHP-DEV] [PATCH] Bug 43477 - Unicode error mode ignored

The original patch works as it should. Substitution with user-defined characters only works in the "FROM_UNICODE" case. When converting to Unicode, U+FFFD is always substituted because it is the standard substitution character. Even the ICU library does not allow this to be changed (with good r

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

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 >

Re: [PHP-DEV] Problem with Namespaces

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

[PHP-DEV] Problem with Namespaces

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 I

[PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension

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, >

Re: [PHP-DEV] [PATCH] Bug 43477 - Unicode error mode ignored

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,

Re: [PHP-DEV] [PATCH] Bug 43477 - Unicode error mode ignored

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 substitu

Re: [PHP-DEV] [PATCH] Bug 43477 - Unicode error mode ignored

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

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

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: main/fopen

[PHP-DEV] Re: [PATCH] adding stream wrappers to include_path

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 ti