Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
Hi Jochem,
Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas:
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for seperate
funcs?:
set_include_path('foo', INCPATH_OVERRIDE); // default
set_include_path('foo', INCPATH_APPEND);
set_include_path('foo', INCPATH_PREPEND);
Thanks for your support, but this seems counter intuitive. Why should
*set*_include_path() be used to *append* or *prepend* to the include
path? Also learning another mouthful of constants is maybe suboptimal.
Getting used to prepend_/append_...() is easy from my point of view, as
the name is derived from what's currently present (set_include_path()).
cu, Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
On 14.02.2008, at 10:20, Markus Fischer wrote:
Lars Strojny wrote:
Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas:
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for
seperate
funcs?:
set_include_path('foo', INCPATH_OVERRIDE); // default
set_include_path('foo', INCPATH_APPEND);
set_include_path('foo', INCPATH_PREPEND);
Thanks for your support, but this seems counter intuitive. Why should
*set*_include_path() be used to *append* or *prepend* to the include
path? Also learning another mouthful of constants is maybe
suboptimal.
Getting used to prepend_/append_...() is easy from my point of
view, as
the name is derived from what's currently present
(set_include_path()).
Just my senf (like 2c, but that's what we call it in Austria :)
Personally I never understood why we've set_include_path in the
first place anyway. ini_set('include_path', ... does exactly the
same and the C function does actually exactly this.
Short history lesson:
The reason for set_include_path() is that many shared hosters disable
ini_set(), yet many libraries/apps depend on users being able to
control their include path.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
On 14.02.2008, at 10:07, Lars Strojny wrote:
Hi Jochem,
Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas:
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for seperate
funcs?:
set_include_path('foo', INCPATH_OVERRIDE); // default
set_include_path('foo', INCPATH_APPEND);
set_include_path('foo', INCPATH_PREPEND);
Thanks for your support, but this seems counter intuitive. Why should
*set*_include_path() be used to *append* or *prepend* to the include
path? Also learning another mouthful of constants is maybe suboptimal.
Getting used to prepend_/append_...() is easy from my point of view,
as
the name is derived from what's currently present
(set_include_path()).
Yeah, I agree that if at all I would go with Lars's original proposal.
I am +1 if we also commit array_merge_replace() at the same time :)
No seriously, its rare enough stuff that I do not see a special need
for these functions. But I do buy the argument that it improves
readability and is easier to remember (and get proper autocompletion
in an IDE). So I am +0.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] final keyword
This is what I'm saying. But the current grammar lacks within the use of const and final! And that's what it's all about - that's my point. ;) Lukas Kahwe Smith schrieb: On 13.02.2008, at 21:52, Andi Gutmans wrote: Guys, I think we are over-engineering and over-complicating here. Reminds me of all the ugly workarounds in C++. If this is really what you need then just declare it private/protected and create accessor methods (getters/setters). I don't think it makes sense to introduce additional complexities both to the grammar and the visibility logic for something very few people are going to get their heads around... Thats exactly what I was thinking when I read this proposal and ensuing discussion. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
Lukas Kahwe Smith wrote:
On 14.02.2008, at 10:20, Markus Fischer wrote:
Personally I never understood why we've set_include_path in the first
place anyway. ini_set('include_path', ... does exactly the same and
the C function does actually exactly this.
Short history lesson:
The reason for set_include_path() is that many shared hosters disable
ini_set(), yet many libraries/apps depend on users being able to control
their include path.
Fair enough. I think I feel pretty lucky that I've never had to operate in
such environments ...
On the other hand I feel unqualified taking a position here either then :)
thanks,
- Markus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
Lukas Kahwe Smith schreef:
On 14.02.2008, at 10:07, Lars Strojny wrote:
Hi Jochem,
Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas:
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for seperate
funcs?:
set_include_path('foo', INCPATH_OVERRIDE); // default
set_include_path('foo', INCPATH_APPEND);
set_include_path('foo', INCPATH_PREPEND);
Thanks for your support, but this seems counter intuitive. Why should
*set*_include_path() be used to *append* or *prepend* to the include
path? Also learning another mouthful of constants is maybe suboptimal.
Getting used to prepend_/append_...() is easy from my point of view, as
the name is derived from what's currently present (set_include_path()).
Yeah, I agree that if at all I would go with Lars's original proposal.
point taken, I was just thinking out loud really, I didn't even know of
set_include_path() before yesterday. I happily use ini_set('include_path') and
have
no need for the extra functions ... but someone wrote them, someone might like
them
and I figure offering an idea (however stupid - heck of got so many ;-)) can't
hurt
(anything apart from my meager reputation)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HOST=] and [PATH=] cgi-only?
On 14/02/2008, Pierre Joye [EMAIL PROTECTED] wrote: Hi Stan, On Feb 14, 2008 1:52 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! Do I understand correctly that current [HOST=] and [PATH=] functionality for PHP works only for CGI/FCGI sapi? Is there any reason for other SAPIs not to do it (except for the obvious - lack of implementation :)? I know there's .htacess for Apache, etc. but there may be setups that might prefer to deal with php.ini... We first discussed about fastcgi as a first step but the goal is to support this syntax in all SAPI (well, cli makes little sense). It was thought as a replacement for htscanner (see pecl) but without its limitation. Whilst having HOST= may not make much sense for CLI, PATH= can be useful. Say you have a live and test websites (either by HOST=test.domain.com or PATH=C:\Sites\Test\Domain\public_html). The live site will have no errors displayed. The test site will have them displayed (maybe). For CLI having C:\Scripts\Live and C:\Scripts\Test is useful as this will provide the same functionality as non CLI. So, if you can please allow PATH= for CLI (rather than just assume it is of no use and ignoring it). I can't think of how I would use HOST= in CLI, unless maybe you could get the machine's name (stretching for an idea here). Thank you. Richard. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HOST=] and [PATH=] cgi-only?
On Wed, 2008-02-13 at 17:47 -0800, Stanislav Malyshev wrote: Hi! We first discussed about fastcgi as a first step but the goal is to support this syntax in all SAPI (well, cli makes little sense). It was thought as a replacement for htscanner (see pecl) but without its limitation. Ok, that makes sense, thanks. I don't know for sure but it should be possible to make it SAPI thing, ie. it would be available everywhere. Right now it's just implemented for CGI which lacked it the most. It's just about what path is passed for looking for ini files to scan for. :) Now that Marcus has implemented the conditional blocks for ini files, it makes more sense to make this available always as you can enable sections depending on current SAPI. (you can disable HOST sections if current SAPI is CLI for example) Anyone see any problems with this though? :) -- Patches/Donations: http://pecl.php.net/~jani/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Pierre Joye schrieb: Tell us the names of these entities, companies or persons, who are going to contribute and what are actually their requirements. What will they bring (saying expertise is not something I can buy)? I don't understand what is so hard to understand that it is a minimum to get before we can even discuss the CLA introduction. Let alone the fact that they don't consider us as good enough as discussions partner. Should be known, just to clearify... From MySQL side primarily Jay (Pipes) has been involved. Who can you talk to on MySQL side? Well, the usual suspects: me, Jay (Pipes), Georg (Richter), Kaj (Arnö), Giuseppe (Maxia), ... - and all the others being active in the PHP world. Who would contribute code? No clue, really. Check who has the skills for it and you can speculate, if that makes any difference to you. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Pierre Joye wrote: You (as group) We are individuals, all members of the mail lists. Tell us the names of these entities, companies or persons, who are going to contribute and what are actually their requirements. The general list of data access providers has been given before and isn't surprising. I can't represent anyone other than myself in these discussions. What will they bring (saying expertise is not something I can buy)? We bring development, maintenance, testing and documentation folk. We bring in-depth data access knowledge. We bring previous experience from working on standards. We bring experience from working on PHP. A side benefit is that this leads to more people familiar with PHP code and PHP processes. This grows the pool of talent with the potential to contribute to PHP in general (as my management would like me to do). The people are also able to help shape their future databases to help the PHP user, for example, Oracle's Database Resident Connection Pooling (DRCP). Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Lukas Kahwe Smith wrote: OSS is a collaborative process that is not about some manager allocating some ressources here and there. People usually make personal commitments here and maybe this is the bigger culture clash than the CLA. Oracle contributes to a range of open source projects, big and small, mature and too new to be known. The commitments come at the personal level and from management who expect their staff to work on those projects. OSS projects accept contributions on merit, and that doesn't always mean knowing much about the background of the people contributing. What is being proposed is to turn part of PHP into something that is managed by a manager and the budget he gets allocated by a manager above him. The proposal is a broader approach to the design and implementation of a DB access layer. Instead of a piecemeal, ad hoc set of designs that ultimately reduces general productivity, I'd like to sit down and discuss what users want and create a coherent solution. People do not commit access for saying what company they work for. People get commit access once they have send enough patches that are top notch, that php.net decides they can trust them. This is the model of trust we have gone by. So if we are going to change this to start trusting a managerial process, the least we can ask is to have some interaction with the people that will most likely be involved there, even if there is a good chance that things might be shuffled around by the time we get to see code. The code and strength of contributions and maintenance is the ultimate evidence of what can be trusted. Poor quality drivers, if they are distributed via a PECL-only distribution, will acquire their own bad reputation and remain little used like other dormant PECL extensions. Or if the drivers are part of the core PHP distribution, a poor driver should get pulled if it is not of sufficient quality as determined by the PHP community. I believe that all the data access providers potentially involved have some level of skill with PHP extension writing, and they certainly have some skill in writing software. I hope that the data access providers are not the only people contributing to, or gate-checking, the drivers. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
On 14.02.2008, at 22:07, Christopher Jones wrote: Pierre Joye wrote: You (as group) We are individuals, all members of the mail lists. Ok, could the Microsoft and IBM people on this list please speak up then? Could also one of the Oracle internals guys speak up on this list? That is what Pierre was asking for. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Hi Chris, On Thu, Feb 14, 2008 at 10:08 PM, Christopher Jones [EMAIL PROTECTED] wrote: The code and strength of contributions and maintenance is the ultimate evidence of what can be trusted. Poor quality drivers, if they are distributed via a PECL-only distribution, will acquire their own bad reputation and remain little used like other dormant PECL extensions. Or if the drivers are part of the core PHP distribution, a poor driver should get pulled if it is not of sufficient quality as determined by the PHP community. As we all agree that poor drivers are not welcome (and great drivers are...), the problem here is not about improving PHP database support (call it PDOv2 or DBDOv3) but to introduce CLA'ed areas in PHP, php core or PECL. It would be nice to dissociate the two and to begin a real dialog between all parties (see my list of questions). About the list having been already gaven, sorry but I can't remember any list or any post about this topic not coming from existing contributors. As I said, many times (not enough) Zend is not PHP. Zend is a (big) contributor but Zend is not PHP. Neither are any of us. Conferences and management meetings are great place to create personal contacts and improve one thing or another, they are not the place to decide such things for the whole community. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Lukas Kahwe Smith wrote: On 14.02.2008, at 22:07, Christopher Jones wrote: Pierre Joye wrote: You (as group) We are individuals, all members of the mail lists. Ok, could the Microsoft and IBM people on this list please speak up then? Could also one of the Oracle internals guys speak up on this list? That is what Pierre was asking for. What do you want the Oracle internals guys to speak about? They may not be known to you personally, but I've acknowledged some of the coders in various bugs fixes, one of the driver architects has featured in my blog, and some of the key people (including management) have attended the Zend Conferences here in California for the last couple of years. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
On 14.02.2008, at 22:19, Christopher Jones wrote: Lukas Kahwe Smith wrote: On 14.02.2008, at 22:07, Christopher Jones wrote: Pierre Joye wrote: You (as group) We are individuals, all members of the mail lists. Ok, could the Microsoft and IBM people on this list please speak up then? Could also one of the Oracle internals guys speak up on this list? That is what Pierre was asking for. What do you want the Oracle internals guys to speak about? They may Mainly I want them to send patches and explain them. A simple hi beforehand would be nice as well :) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
On 14.02.2008, at 23:06, Christopher Jones wrote: I think most multi-person plans that impact an existing OSS project have had some genesis in private discussions before being broadcast. For PDO V2, this discussion was just really slow and intermittent. Yeah, I am basically fine with this. I send private emails to people around OSS projects all the time. Its absolutely ok and actually something that is vital to keep things manageable. However the point here is. There is a proposal on the table to change the php.net project to be able to bring in developers we do not know, for code they have not yet written, for specs they have not yet contributed. This is flipping our development process upside down while adding legal hurdles. As such the only course of action I currently is to start working. If you guys do not feel like you can work within the current legal bounds of php.net, then I suggest you start working outside of them. Once we see actual value being contributed, the willingness to compromise and change will be much higher. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Lukas Kahwe Smith wrote: However the point here is. There is a proposal on the table to change the php.net project to be able to bring in developers we do not know, for code they have not yet written, for specs they have not yet contributed. This is flipping our development process upside down while adding legal hurdles. Since the process hasn't started yet, of course some of the participants aren't known. I don't think PDO V2 is going to be any different from other PHP projects: it starts at the beginning and progress is monitored. If it's not going well, people speak up and decisions are made about how to correct it. As such the only course of action I currently is to start working. If you guys do not feel like you can work within the current legal bounds of php.net, then I suggest you start working outside of them. Once we see actual value being contributed, the willingness to compromise and change will be much higher. I want to see the effort spent will have value to the community. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
-Original Message- From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 2:15 PM To: Christopher Jones Cc: Pierre Joye; [EMAIL PROTECTED]; PHP Internals Subject: Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2 -snip- As such the only course of action I currently is to start working. If you guys do not feel like you can work within the current legal bounds of php.net, then I suggest you start working outside of them. Once we see actual value being contributed, the willingness to compromise and change will be much higher. It's a bit of a chickenegg problem. The idea was to find a way for this to happen which would work long term for the project. This includes both the contribution process and then the distribution process. Theoretically working on this separately is an option the same way you have Propel for DB abstraction, Midnight Coders for Flex, NuSOAP for SOAP, etc... However we see this as an important core component for PHP and a lot of these processes can't just be changed/reversed once they are set in motion. For example, if this is developed separately then I assume there'd be no problem in having a legal entity (you mentioned some of the other standards bodies who are also entities). The issue will pop up when there are successes and we all believe it's beneficial to roll it into PHP. So instead we tried to come up with a proposal which would enable the long term feasibility and create a feasible path ahead of time. As an example with the legal entity issue we managed to get buy in for using PHP Group (not trivial, or should I even say, unprecedented). Anyway it's still an option but not the preferred one. I'd be interested to hear more about the ideas people had on how we can possibly decouple some of the packaging decisions and where the actual work happens. There'd obviously still need to be certain requirements including compatible licenses, integration into bug tracker (possibly), and configuration management guidelines, but maybe others have ideas for ways to accomplish the goals in a way which could still work for most people and allow the vendors to have some of their best people to fully participate. I say most because 100% of people are never happy including in all the million other discussions we have had on other topics over the years. Anyway, let's continue this discussion but with the intent to make a best shot at some ideas for how to achieve some of the goals I think the majority of us would like to see a PDO which includes a first-class PDO with the necessary functionality and consistency, high-quality and consistent drivers across all data access APIs, and well documented functionality. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
On Wed, February 13, 2008 9:47 am, Lars Strojny wrote: Hi everyone, the following patch[1] adds the functions append_include_path() and prepend_include_path(). These function are there to make include path adjustments easier than it is. Especially append_include_path() is what is done most of the time. The current patch is in a bit hacky state, as I have my doubts whether storing the include paths as a string is a good idea. I want to gain some feedback for this addition first before I invest more work on it. [1] http://lars.schokokeks.org/php/include_path_modifiers-1.diff Seems kinda silly, really, since one can just do: set_include_path(foo: . include_path()); set_include_path(include_path() . :bar); Okay, you need to use PATH_SEPARATOR and maybe you'd want to be sure you're not adding the same path twice in a really fancy version... But even that wouldn't be 100% with symlinks or other funkiness like using /foo/bar//baz/... -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Double quotes for NOWDOCS
Hi, I know, I might be a bit late but I've played around with NOWDOCS and one issue popped up instantly: it seems not really logical to me, why only single quotes are allowed and I have the feeling a lot of users will ask the same questions. The problem is, that we are used to the way we define strings. Both variants are possible, single-quotes and double quotes. Now we are going to use NOWDOCS and only single quotes are allowed. I think allowing both would be a good idea, so here is the patch: http://lars.schokokeks.org/php/nowdocs_double_quotes-1.diff cu, Lars -- »Die Glorifizierung der prächtigen underdogs läuft auf die des prächtigen Systems heraus, das sie dazu macht.« -- Theodor W. Adorno, »Minima Moralia«: They, the people Lars Strojny Nießenstr. 36 51103 Cologne Jabber/Mail: [EMAIL PROTECTED] Weblog: http://usrportage.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
Hi, Am Mittwoch, den 13.02.2008, 16:47 +0100 schrieb Lars Strojny: [...] The current patch is in a bit hacky state, as I have my doubts whether storing the include paths as a string is a good idea. I want to gain some feedback for this addition first before I invest more work on it. Just for the record, there is an improved version of this patch. It returns now false if snprintf() could not format the string properly. See http://lars.schokokeks.org/php/include_path_modifiers-2.diff for details. However I have the feeling that actually only a few see this patch as an improvement, so I we are not going to add this anyway. cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Double quotes for NOWDOCS
Hi, I know I am a bit late, but I've played around with NOWDOCS this evening, and one issue thing came up instantly: I asked myself why the heck are single quotes allowed but not double quotes? This seems to me counter intuitive to the way we handle strings in PHP. I think it would be perfectly alright to allow both, single quotes and double quotes. My proposed patch: http://lars.schokokeks.org/php/nowdocs_double_quotes-1.diff cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Double quotes for NOWDOCS
Hi, sorry for the manual duplicate. I had the feeling my mail from yesterday evening was lost, as I could not find it in the sent folder again. cu, Lars Am Freitag, den 15.02.2008, 07:41 +0100 schrieb Lars Strojny: Hi, I know, I might be a bit late but I've played around with NOWDOCS and one issue popped up instantly: it seems not really logical to me, why only single quotes are allowed and I have the feeling a lot of users will ask the same questions. The problem is, that we are used to the way we define strings. Both variants are possible, single-quotes and double quotes. Now we are going to use NOWDOCS and only single quotes are allowed. I think allowing both would be a good idea, so here is the patch: http://lars.schokokeks.org/php/nowdocs_double_quotes-1.diff cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
