Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

> Well, actually, I would prefer to see a proper BNDM > implementation in the tree. > > - character classes are handled for free > (i.e. a case insensitive search does not take longer) > > - combining shift-and and automata is much faster than our > current naive algorit

Re: [PHP-DEV] Feature Request #5919 case-insensitive version ofstr_replace()

> One last optimization to save memcpys when needle_len == str_len (thanks > again ilia): > > Actual Patch: > http://169.229.139.97/test/str_ireplace.diff-5.txt > > Resultant string.c for easy reading: > http://169.229.139.97/test/string-5.c > > I've heard enough Ayes over Nays (here, in bugs.php.n

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

> better and better... > One last optimization to save memcpys when needle_len == str_len (thanks again ilia): Actual Patch: http://169.229.139.97/test/str_ireplace.diff-5.txt Resultant string.c for easy reading: http://169.229.139.97/test/string-5.c I've heard enough Ayes over Nays (here, in bu

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

At 00:47 30.01.2003, Edin Kadribasic wrote: > I don't even see the speed difference as an issue as much as (A) > simplicity for the user who hasn't figured out regex yet, (B) consistency > (we have 'i' versions of most other string functions, why not this one?) +1 for the reasons stated above.

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

> I don't even see the speed difference as an issue as much as (A) > simplicity for the user who hasn't figured out regex yet, (B) consistency > (we have 'i' versions of most other string functions, why not this one?) +1 for the reasons stated above. Edin -- PHP Development Mailing List

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

better and better... Ilia offered up an optimized version of php_str_to_str which skips string resizing and handles do-no-work scenarios up front. I've made necessary changes to make this case_optional and made a new patch: http://169.229.139.97/test/str_ireplace.diff-4.txt as well as posting w

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

On Thu, 30 Jan 2003 09:09, Ilia A. wrote: > On January 29, 2003 04:35 pm, Shane Caraveo wrote: > > What's the benchmark code? How is the benchmark difference on large > > text (ie. 100K of text) vs. small text (1K or smaller)? > > Attached is the benchmark script that I've used. I've intentionally

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

On January 29, 2003 04:35 pm, Shane Caraveo wrote: > What's the benchmark code? How is the benchmark difference on large > text (ie. 100K of text) vs. small text (1K or smaller)? Attached is the benchmark script that I've used. I've intentionally used 'small' strings, since that is what I imagin

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

Gah. I botched that, I didn't reset the timer. Total Time: 00:00:03.08 //str_replace Total Time: 00:00:04.32 //preg_replace Total Time: 00:00:03.05 //str_replace Total Time: 00:00:03.67 //preg_replace Total Time: 00:00:03.27 //str_replace Total Time: 00:00:04.40 //preg_replace Closer than I thou

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

On Thu, 30 Jan 2003 06:48, Ilia A. wrote: > > I may be wrong since I haven't profiled this, but my understanding is > > that str_replace is much faster than doing either of the regex > > replacements. For that reason alone, there is a use for it. > > Normally it would be quite faster, however once

Re: [PHP-DEV] Feature Request #5919 case-insensitive version ofstr_replace()

I'd tip my hat towards implementing it. Pollita has a good point on consistency and for those who don't know regex's. On Wed, 29 Jan 2003, Sara Golemon wrote: > >> I may be wrong since I haven't profiled this, but my understanding is > >> that str_replace is much faster than doing either of the

[Fwd: Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()]

whoops, missent just to sascha instead of list... >> On a related topic, the 'boyer' option of str_replace isn't even >> documented. That alternate method of performing str_replaces look >> like it's a bit more efficient (no benchmarkes atm) but I'm wondering >> if there's a specific reasons why

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

Ilia A. wrote: I may be wrong since I haven't profiled this, but my understanding is that str_replace is much faster than doing either of the regex replacements. For that reason alone, there is a use for it. Normally it would be quite faster, however once case sensitivity is added to the mix I

Re: [PHP-DEV] Feature Request #5919 case-insensitive version ofstr_replace()

> On a related topic, the 'boyer' option of str_replace isn't even > documented. That alternate method of performing str_replaces look like > it's a bit more efficient (no benchmarkes atm) but I'm wondering if > there's a specific reasons why it wasn't documented yet. The BM algorithm is outd

Re: [PHP-DEV] Feature Request #5919 case-insensitive version ofstr_replace()

I suggest to check out http://citeseer.nj.nec.com/navarro01fast.html The presented BNDM algorithm is one of the fastest string searching algorithm while being easy to implement. Its main loop is faster than the naive str_replace implementation(*). Check out a C test impl

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

>> I may be wrong since I haven't profiled this, but my understanding is >> that str_replace is much faster than doing either of the regex >> replacements. For that reason alone, there is a use for it. > > Normally it would be quite faster, however once case sensitivity is > added to the mix I be

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

> I may be wrong since I haven't profiled this, but my understanding is > that str_replace is much faster than doing either of the regex > replacements. For that reason alone, there is a use for it. Normally it would be quite faster, however once case sensitivity is added to the mix I believe th

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

Derick Rethans wrote: On Wed, 29 Jan 2003, Sara Golemon wrote: I've got an implementation put together, the patch for which can be viewed at: http://169.229.139.97/test/str_ireplace.diff.txt After some comments on IRC, here's an alternate version to the above patch. This second approach av

Re: [PHP-DEV] Feature Request #5919 case-insensitive version ofstr_replace()

On Wed, 29 Jan 2003, Sara Golemon wrote: > > I've got an implementation put together, the patch for which can be > > viewed at: > > > > http://169.229.139.97/test/str_ireplace.diff.txt > > > After some comments on IRC, here's an alternate version to the above > patch. This second approach avoids

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

> I've got an implementation put together, the patch for which can be > viewed at: > > http://169.229.139.97/test/str_ireplace.diff.txt > After some comments on IRC, here's an alternate version to the above patch. This second approach avoids creating php_memnstri by simply searching through a copy

Re: [PHP-DEV] Feature Request: Auto Include a Function

Hi, on the last week's iSeminar Zeev said that in ZE2(php5) there will be new interesting function for implementing in userland. Its name will be __autoload(). It will be called in case the code wants to instantiate a class that is unknown. The function should require/include the file where the im

RE: [PHP-DEV] Feature Request: Auto Include a Function

On Mon, 13 Jan 2003, Brian T. Allen wrote: > If a hash file were used it would only have to "search" for the function > once, and even then only in the functions directory (like the include > directory, but specifically for functions). After that the order would > be: > > 1) Execute the function

RE: [PHP-DEV] Feature Request: Auto Include a Function

onday, January 13, 2003 2:16 PM > > Subject: Re: [PHP-DEV] Feature Request: Auto Include a Function > > > > > > I'm not a PHP Developer but I see a few problems with this. > > I'm not a PHP Developer either, but I use it 12 hours a day in my work. >

RE: [PHP-DEV] Feature Request: Auto Include a Function

> From: Andrew Brampton [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 13, 2003 2:16 PM > Subject: Re: [PHP-DEV] Feature Request: Auto Include a Function > > > I'm not a PHP Developer but I see a few problems with this. I'm not a PHP Developer either, but I

Re: [PHP-DEV] Feature Request: Auto Include a Function

I'm not a PHP Developer but I see a few problems with this. Since a PHP script is re-evaluated/"compiled" on each execution it would mean PHP would have to look through all your .php files for this file. This could be very time consuming, espically since it has to do it every execution. Also what

Re: [PHP-DEV] Feature request -- feedback welcomed.

You already have "public" which you can use instead of "var". I think method would look very nice but I don't think it's worth creating another reserved word. Andi At 01:34 PM 9/28/2002 -0600, Lamont R. Peterson wrote: >All: > >I can't hardly wait for PHP 4.3 (Zend 2.0) to hit the streets. I c

RE: [PHP-DEV] Feature request -- feedback welcomed.

age- > From: Shamim Islam [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 30, 2002 8:48 PM > To: Lamont R. Peterson; [EMAIL PROTECTED] > Subject: Re: [PHP-DEV] Feature request -- feedback welcomed. > > On the surface, it sounds like a good idea but underneath the semantic

Re: [PHP-DEV] Feature request -- feedback welcomed.

On the surface, it sounds like a good idea but underneath the semantic change is fraught with logical inconsistencies. A method is specifically a function declared within a class context. A static method is a static function declared within a class context. A method by itself has no meaning and

Re: [PHP-DEV] Feature request -- feedback welcomed.

> Uhm... 4.3.0 will not ship with Zend 2.0, that will b ethe honour of PHP > 5.0.0. But one can compile Zend 2.0 into PHP 4 - i think Zeev posted an HowTo some weeks ago. Regards Sascha -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Feature request -- feedback welcomed.

Sebastian Bergmann wrote: > His name is "Derick", like the TV inspector. +almost (my bad, http://us.imdb.com/Title?0070981) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.

Re: [PHP-DEV] Feature request -- feedback welcomed.

On Sat, 28 Sep 2002 22:23:08 +0200 Sebastian Bergmann <[EMAIL PROTECTED]> wrote: > His name is "Derick", like the TV inspector. yup, but he s more funny ;-) -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Feature request -- feedback welcomed.

"Lamont R. Peterson" wrote: > Derek & All: His name is "Derick", like the TV inspector. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing Lis

Re: [PHP-DEV] Feature request -- feedback welcomed.

Derek & All: [NOTE: The root message of this thread is the first I've read with this list. Therefore, I don't know what's been talked about here. I'll happily admit that this makes it much easier for me to look stupid when asking questions.] On Saturday 28 September 2002 13:50, [EMAIL PROTEC

Re: [PHP-DEV] Feature request -- feedback welcomed.

On Sat, 28 Sep 2002, Lamont R. Peterson wrote: > All: > > I can't hardly wait for PHP 4.3 (Zend 2.0) to hit the streets. I can't > express how anxiously I've been waiting for the class model to be reworked. > Great job! Uhm... 4.3.0 will not ship with Zend 2.0, that will b ethe honour of PH

Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT

Shell Shortcuts could be used to implement symlink like behaviour, and it would be compatible on more systems, but it would be a bigger pain to implement in PHP. As far as the directory junctions, this is how MS describes them: # NTFS Directory Junctions. These are NTFS directories that can be

Re: Re: Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT

ck, if the filesystem, the link is created in, is really NTFS. Timo -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Montag, 8. Juli 2002 08:05 To: Timo Weingärtner Cc: [EMAIL PROTECTED] Subject: Re: Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT Again, the fa

Re: Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT

Apache 2.x recognizes junctions >under NT (Options FollowSymlinks). It would be nice to have the code >included in PHP. > >Thanks in advance, Timo Weingärtner > >-Original Message- >From: Zeev Suraski [mailto:[EMAIL PROTECTED]] >Sent: Samstag, 6. Juli 2002 16:55 >T

Re: Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT

al Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Samstag, 6. Juli 2002 16:55 To: Timo Weingärtner Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT Are you sure they're equivalent to symlinks? They only work with directories as far as I know, whi

Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT

Are you sure they're equivalent to symlinks? They only work with directories as far as I know, which renders them significantly less useful than UNIX symlinks. Zeev At 05:26 PM 7/6/2002, Timo Weingärtner wrote: >NTFS supports directory junctions which are equivalent to unix symlinks. >I found

Re: [PHP-DEV] feature request

Is there a "portable" way to implement this on all/most OS'es? Please submit this feature request on bugs.php.net. - Stig On Wed, 2002-07-03 at 23:06, veins wrote: > hi, > I have a feature request for the exec() family. > I was thinking of adding a fourth optionnal argument to be passed as > t

Re: [PHP-DEV] Feature Request: Session Module

I figured it out, it was a problem in APC that was causing it. Deleting the compiled PHP files fixed the problem. I have no idea why that fixed it, but it did. Markus Fischer wrote: > Hi, > > http://bugs.php.net/report.php > > - Markus > > On Sat, May 04, 2002 at 06:20:28PM -0

Re: [PHP-DEV] Feature Request: Session Module

Steve Meyers wrote: > Do you need a backtrace of it? If so, how do I do that? http://www.php.net/manual/en/faq.installation.php#faq.installation.nodata -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://w

Re: [PHP-DEV] Feature Request: Session Module

Hi, http://bugs.php.net/report.php - Markus On Sat, May 04, 2002 at 06:20:28PM -0600, Steve Meyers wrote : > I just tried ext/shmop, and without even using it, the fact that it is > compiled in to php causes it to segfault on every request. > > Here's my ./configure line > > ./c

Re: [PHP-DEV] Feature Request: Session Module

I just tried ext/shmop, and without even using it, the fact that it is compiled in to php causes it to segfault on every request. Here's my ./configure line ./configure --with-mysql=/usr --with-pgsql --enable-ftp --with-ldap --with-gmp --disable-pear --enable-shmop --enable-apc --with-apache=

Re: [PHP-DEV] Feature Request: Session Module

Markus Fischer wrote: > Hi, > > I think what you want can (and should) be done with shared > memory, ext/shmop . This way you exchange values as you want > (it's not tied to sessions in anyway, btw). > Markus' method works nicely for single server It is recommended way. Try ses

Re: [PHP-DEV] Feature Request: Session Module

Hi, I think what you want can (and should) be done with shared memory, ext/shmop . This way you exchange values as you want (it's not tied to sessions in anyway, btw). - Markus On Sat, May 04, 2002 at 11:08:52AM +0200, Michael Virnstein wrote : > Hi! > > What really would

Re: [PHP-DEV] feature request for __LINE__, __FILE__ and trigger_error

I wrote this extension a while back, but I never released it since I didn't follow coding style and it was my first forage into extension coding for PHP. It should be what your looking for though for the most part... the function of usefulness is: get_function_call_stack() which will return an ar

Re: [PHP-DEV] feature request for __LINE__, __FILE__ andtrigger_error

__LINE__ , __FILE__ (and now __FUNCTION__ & __CLASS__) are converted at compile time into a string - have a look at zend/zend_language_scanner.l for more details. regards alan Michael Virnstein wrote: >A short question on this: >how about __LINE__? >doesn't this also require runtime context

Re: [PHP-DEV] feature request for __LINE__, __FILE__ andtrigger_error

A short question on this: how about __LINE__? doesn't this also require runtime context or am i wrong? if so, why it is a constant then, not a function? Michael "Stig S. Bakken" <[EMAIL PROTECTED]> schrieb im Newsbeitrag [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi, > > __FILE__ is compiled

Re: [PHP-DEV] feature request for __LINE__, __FILE__ andtrigger_error

Hi, you may be right, but this was only a suggestion. If you know a better way doing this, no problem. I thought of something like __FILE__ and __LINE__, because these constants are easy to use. If we have a function for this, not a constant, it's also ok for me. Michael "Stig S. Bakken" <[EMAI

Re: [PHP-DEV] feature request

Hi! Am Wed, 24 Apr 2002 22:15:19 +0200 schrieb Daniel Lorch <[EMAIL PROTECTED]>: > function line_count($string) { > return count(preg_split("/\r?\n/", $string)); > } Why not simply use a substr_count($string, "\n")? It works fine for me... cu, Roland Tapken -- Please reply to: [EMAIL PROTE

Re: [PHP-DEV] feature request

Hi, people fail to understand the reason why to "bloat" PHP with just another function which is really just a call to another function (e.g. preg_*() in PHP. As for parsing an ini file, this is certainly not true. Anyway. There were some discussions lately to implement

RE: [PHP-DEV] feature request

> Here I'm asking myself: what function would be easier for user to > create: counting spaces in a string or parsing the .ini file or touch > and chown? Parsing an INI file isn't difficult. It requires the same amount of knowledge to do as counting spaces or lines, albeit with a bunch more typi

Re: [PHP-DEV] feature request for __LINE__, __FILE__ andtrigger_error

Hi, __FILE__ is compiled into a constant string by Zend. You can think of it as equivalent of putting a string with the filename there instead. It is constant. __CFILE__ would require runtime context (which function called us), so it makes no sense as a constant. Derick's xdebug extension wil

RE: [PHP-DEV] feature request

> > Especially when you have such fancy buit-ins like "parse_ini"file" and > "pathinfo", and other built in unix commands like "touch", "chown", and > "chmod". Here I'm asking myself: what function would be easier for user to create: counting spaces in a string or parsing the .ini file or touch

Re: [PHP-DEV] feature request for __LINE__, __FILE__ and trigger_error

Addressed to: [EMAIL PROTECTED] [EMAIL PROTECTED] ** Reply to note from [EMAIL PROTECTED] Wed, 24 Apr 2002 21:06:41 +0200 (CEST) > > Hello Michael, > > I'm working (80% done) on an extension for this. It should be finished in > a few days. It doesn't feature the __C*__ things

Re: [PHP-DEV] feature request

> function line_count($string) { > return count(preg_split("/\r?\n/", $string)); > } > > function word_count($string) { > return count(preg_split("/\s+/", $string)); > } > > There will be a PEAR-string class, which includes functions similar to > this. I assigned it to me some days ago and I w

Re: [PHP-DEV] feature request

$wc = strlen(preg_replace('/\W*\w*/', 'x', file_get_contents($file)); Look, no arrays! :-) - Stig On Wed, 2002-04-24 at 20:20, Nikolai Devereaux wrote: > It would be great if there was a function in the filesystem family similar > to the unix command "wc". It'd be nice to not have to write si

Re: [PHP-DEV] feature request

Hi, > It would be great if there was a function in the filesystem family similar > to the unix command "wc". It'd be nice to not have to write simple wrappers > around system calls or creating arrays to get the number of words or lines > in a file. function line_count($string) { return count(

Re: [PHP-DEV] feature request for __LINE__, __FILE__ and trigger_error

an additional thought: if __CFILE__ and __CLINE__ are used outside of a function/method, both should be NULL. and trigger_error should only overwrite its __FILE__ and __LINE__ settings, if they are NOT NULL. And if one of the __FILE__ , __LINE parameters of trigger_error is NOT NULL, both have to

Re: [PHP-DEV] feature request for __LINE__, __FILE__ and trigger_error

wow...your fast! :) thanx..that would be really great! Michael <[EMAIL PROTECTED]> schrieb im Newsbeitrag [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hello Michael, > > I'm working (80% done) on an extension for this. It should be finished in > a few days. It doesn't feature the __C*__ things

Re: [PHP-DEV] feature request for __LINE__, __FILE__ and trigger_error

Hello Michael, I'm working (80% done) on an extension for this. It should be finished in a few days. It doesn't feature the __C*__ things yet, but I can add a function for that too. I'll keep you posted, Derick On Wed, 24 Apr 2002, Michael Virnstein wrote: > It would be really useful for wr

Re: [PHP-DEV] Feature request: anonymous usage of returned values

This isn't planned for Engine 2 but you could use: list($year) = localtime($time); Andi At 03:17 20/04/2002 +0200, Markus Fischer wrote: > I've brought this up on the Zend Engine2 list a while ago. > The result was that it is not planned to support > dereferencing of arrays from

Re: [PHP-DEV] Feature request: anonymous usage of returned values

I've brought this up on the Zend Engine2 list a while ago. The result was that it is not planned to support dereferencing of arrays from e.g. return value on the fly. - Markus On Fri, Apr 19, 2002 at 07:26:26PM -0500, Derek Moore wrote : > I've been playin' around with Horde and

Re: [PHP-DEV] Feature Request for pcre_match*()

Hello, can you please post a unified diff (diff -u)? That's much more readable. regards, Derick On Mon, 4 Mar 2002, 'Ricky' S Dhatt wrote: > Hi - > > I'd like to ask that the pcre_match*() functions be modified such that > they can also return position info on where the match(s) occured, akin

Re: [PHP-DEV] Feature Request: add HTML 4.01 support into DOMXML extension?

> Can you tell more on what that patch is about and it's availability? Look at http://rainbow.mimuw.edu.pl/~jkolakow/domxml/ Regards, Jaroslaw Kolakowski -- PHP Development Mailing List To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PR

Re: [PHP-DEV] Feature Request: add HTML 4.01 support into DOMXML extension?

Hi Jaroslaw! On Wed, 05 Dec 2001, Jaroslaw Kolakowski wrote: > > But, even if we don't agree with his opinion on templates, what about > > the features that libxml provides which are currently unused by PHP, > > including HTML 4.01-support (I don't know exactly what libxml can do)? > > Are the

Re: [PHP-DEV] Feature Request: add HTML 4.01 support into DOMXML extension?

> But, even if we don't agree with his opinion on templates, what about > the features that libxml provides which are currently unused by PHP, > including HTML 4.01-support (I don't know exactly what libxml can do)? > Are there any plans to make them accessible from PHP? It definately > would

Re: [PHP-DEV] Feature Request: add HTML 4.01 support into DOMXML extension?

On Wed, 05 Dec 2001, Alexander Wagner wrote: > But, even if we don't agree with his opinion on templates, what about > the features that libxml provides which are currently unused by PHP, > including HTML 4.01-support (I don't know exactly what libxml can do)? > Are there any plans to make them

Re: [PHP-DEV] Feature Request: add HTML 4.01 support into DOMXML extension?

Andrei Zmievski wrote: > > there's no point in using a home-brewn scripting language > > to do those tasks, is there? all the constructs are already part > > of the php language... Are you aware of the concept of "domain-specific languages"? There is a point. > Are you done? I'm definately with

Re: [PHP-DEV] Feature Request: add HTML 4.01 support into DOMXML extension?

On Wed, 05 Dec 2001, Lauri Liinat wrote: > > hi, > > has anybody ever thought about supporting HTML 4.01 in > the DOMXML extension as Gnome libxml supports it anyway? > > should be a relatively simple addon, yet extremely useful for > processing layout templates and finally killing the long thr

Re: [PHP-DEV] feature request

>That is the only thing that I see of any real use as well. I was just >humoring Andi and his idea that we would soon be requesting that feature of >knowing which one failed the test. I was really voting no for the original feature - just returning true or false - unless it can be shown (and imp

Re: [PHP-DEV] feature request

I think it makes sense to have empty() behave the same as isset() (they are brother functions). empty($a, $b, $c) would return 0 if non are empty and 1 if one of those variables is empty. Andi At 12:22 AM 3/20/2001 -0500, Jon Parise wrote: >On Mon, Mar 19, 2001 at 11:35:31PM +0200, Zeev Surask

Re: [PHP-DEV] feature request

On Mon, Mar 19, 2001 at 11:35:31PM +0200, Zeev Suraski wrote: > Fact is, using isset() with multiple arguments is much more necessary in > real world than other is_*() functions. isset() is very often used to > validate user input. Then should the same argument be applied to empty(), too? Fo

Re: [PHP-DEV] feature request

On Mon, Mar 19, 2001 at 11:27:09PM +0200, Zeev Suraski wrote: > What is iseverythingelse()? I don't think we have any other > iseverythingelse() function. I'd assume Lars is referring to the is_{type} functions: http://www.php.net/manual/en/ref.var.php -- Jon Parise ([EMAIL PROTECTED])

Re: [PHP-DEV] feature request

Zeev said: >Define 'change their behavior' though? 'change their behavior' === 'change their behavior' in a subtle way :) > Almost all SQL functions take an >optional argument which is the link id. That is by design, and doesn't >really mean anything here, I'm not saying it does mean anything

Re: [PHP-DEV] feature request

Zeev Suraski writes: > What is iseverythingelse()? I don't think we have any other > iseverythingelse() function. > > The fact isset() is a language construct does make a serious > difference. It already is very different from functions, and not in its > underlying implementation but its sem

RE: [PHP-DEV] feature request

I might consider using it like if (isSet($a, $b) && is_int($a, >$b)). > >-Chris > > > -Original Message- > > From: Phil Driscoll [mailto:[EMAIL PROTECTED]] > > Sent: Monday, 19 March, 2001 2-11 pM > > To: Chris Newbill; Zeev Suraski; Andi Gutmans

RE: [PHP-DEV] feature request

Andi Gutmans; [EMAIL PROTECTED] > Cc: PHP DEV > Subject: Re: [PHP-DEV] feature request > > > Andi said: > > >isset() is not an internal function but a language construct. I > disagree on > >the "using additional arguments for other stuff part". It's o

Re: [PHP-DEV] feature request

At 23:10 19/3/2001, Phil Driscoll wrote: >Andi said: > > >isset() is not an internal function but a language construct. I disagree on > >the "using additional arguments for other stuff part". It's often very > >weird that functions behave differently according to the way they are > >called > >I've

Re: [PHP-DEV] feature request

What is iseverythingelse()? I don't think we have any other iseverythingelse() function. The fact isset() is a language construct does make a serious difference. It already is very different from functions, and not in its underlying implementation but its semantics. Zeev At 23:21 19/3/2001

Re: [PHP-DEV] feature request

Jason Greene writes: > > Generally using functions for two different purposes is a bad idea, but > > enhancing functions with additional arguments that extend its functionality > > is not too bad. In this case, adding n arguments is perhaps the extension > > that makes the most sense for isset

Re: [PHP-DEV] feature request

> Generally using functions for two different purposes is a bad idea, but > enhancing functions with additional arguments that extend its functionality > is not too bad. In this case, adding n arguments is perhaps the extension > that makes the most sense for isset(), so we should go with it.

Re: [PHP-DEV] feature request

Andi said: >isset() is not an internal function but a language construct. I disagree on >the "using additional arguments for other stuff part". It's often very >weird that functions behave differently according to the way they are >called I've just done a quick count of the php functions which t

RE: [PHP-DEV] feature request

> From: Andi Gutmans [mailto:[EMAIL PROTECTED]] > Sent: Monday, 19 March, 2001 1-12 pM > To: Jason Greene; Phil Driscoll; Chris Newbill; Zeev Suraski > Cc: PHP DEV > Subject: Re: [PHP-DEV] feature request > > > Ugh, that's exactly what I didn't want to get into. If yo

Re: [PHP-DEV] feature request

At 22:41 19/3/2001, Jason Greene wrote: >I don't, but I could see that viewpoint where Phil is coming from when he >talks about the fact >that functions can end up with 2 different goals, and then when we want to >enhance them >we end up with multiple behaviors in a single function and way too m

Re: [PHP-DEV] feature request

quot;Phil Driscoll" <[EMAIL PROTECTED]>; "Chris Newbill" <[EMAIL PROTECTED]>; "Andi Gutmans" <[EMAIL PROTECTED]>; "PHP DEV" <[EMAIL PROTECTED]> Sent: Monday, March 19, 2001 2:26 PM Subject: Re: [PHP-DEV] feature request > I don't

Re: [PHP-DEV] feature request

"Zeev Suraski" ><[EMAIL PROTECTED]>; "Andi Gutmans" <[EMAIL PROTECTED]> >Cc: "PHP DEV" <[EMAIL PROTECTED]> >Sent: Monday, March 19, 2001 1:58 PM >Subject: Re: [PHP-DEV] feature request > > > > My earlier post to the

Re: [PHP-DEV] feature request

EMAIL PROTECTED]>; "Zeev Suraski" <[EMAIL PROTECTED]> Cc: "PHP DEV" <[EMAIL PROTECTED]> Sent: Monday, March 19, 2001 2:11 PM Subject: Re: [PHP-DEV] feature request > Ugh, that's exactly what I didn't want to get into. If you want an array of > resul

Re: [PHP-DEV] feature request

wbill" <[EMAIL PROTECTED]>; "Zeev Suraski" ><[EMAIL PROTECTED]>; "Andi Gutmans" <[EMAIL PROTECTED]> >Cc: "PHP DEV" <[EMAIL PROTECTED]> >Sent: Monday, March 19, 2001 1:58 PM >Subject: Re: [PHP-DEV] feature request > > &g

Re: [PHP-DEV] feature request

: "Chris Newbill" <[EMAIL PROTECTED]>; "Zeev Suraski" <[EMAIL PROTECTED]>; "Andi Gutmans" <[EMAIL PROTECTED]> Cc: "PHP DEV" <[EMAIL PROTECTED]> Sent: Monday, March 19, 2001 1:58 PM Subject: Re: [PHP-DEV] feature request > My earlier po

Re: [PHP-DEV] feature request

At 07:58 PM 3/19/2001 +, Phil Driscoll wrote: >My earlier post to the list doesn't seem to have arrived yet, so here it is >again. You'll note from the posting that I'm not keen on the patch staying >in. There are considerable efforts being made by several of us on the QA >team trying to make

Re: [PHP-DEV] feature request

My earlier post to the list doesn't seem to have arrived yet, so here it is again. You'll note from the posting that I'm not keen on the patch staying in. There are considerable efforts being made by several of us on the QA team trying to make the language more orthogonal, and this kind of ad hoc

RE: [PHP-DEV] feature request

March, 2001 7-04 aM > > To: Phil Driscoll > > Cc: Chris Newbill; Andi Gutmans; PHP DEV > > Subject: Re: [PHP-DEV] feature request > > > > > > Phil is right. The only thing that may be both useful and > > practical would > > be isset() on multiple

RE: [PHP-DEV] feature request

al Message- > > From: Zeev Suraski [mailto:[EMAIL PROTECTED]] > > Sent: Monday, 19 March, 2001 7-04 aM > > To: Phil Driscoll > > Cc: Chris Newbill; Andi Gutmans; PHP DEV > > Subject: Re: [PHP-DEV] feature request > > > > > > Phil is right. The only

RE: [PHP-DEV] feature request

19 March, 2001 7-04 aM > To: Phil Driscoll > Cc: Chris Newbill; Andi Gutmans; PHP DEV > Subject: Re: [PHP-DEV] feature request > > > Phil is right. The only thing that may be both useful and > practical would > be isset() on multiple variables, returning either true or false

Re: [PHP-DEV] feature request

Phil is right. The only thing that may be both useful and practical would be isset() on multiple variables, returning either true or false. Zeev At 11:31 19/3/2001, Phil Driscoll wrote: > >$a = 1; > >$b = 2; > >$d = 4; > > > >$play_nice = isSet($a, $b, $c, $d); > > > >if (!$play_nice) { > >

RE: [PHP-DEV] feature request

t;that sure about this approach, seems like a hack, but the >I-don't-care-which-one-isn't-set approach seems fine to me. > >Maybe a poll? > >(X) Extend the isset() and empty() functions to encompass multiple > variables as one inclusive logic test. >( ) Don't t

Re: [PHP-DEV] feature request

>$a = 1; >$b = 2; >$d = 4; > >$play_nice = isSet($a, $b, $c, $d); > >if (!$play_nice) { >print "The variable missing is in position "; >print ($play_nice*-1); >} > >And it would print 3, in which case we would know $c is not set. I'm not >that sure about this approach, seems like a hack,

RE: [PHP-DEV] feature request

sset() and empty() functions to encompass multiple variables as one inclusive logic test. ( ) Don't touch my beloved functionality vile creatures! -Chris > From: Andi Gutmans [mailto:[EMAIL PROTECTED]] > Subject: RE: [PHP-DEV] feature request > > > It should be possible to

  1   2   >