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

[Ilia A.]

> 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 algorithm (I may say so, I wrote it years ago)
>
> - allows us to combine multiple patterns into one search (I
>   have not studied that part of the paper yet). This would
>   enable us to optimize the case where you pass arrays to
>   str_replace.  Instead of scanning the "haystack" one time
>   per replacement text, we would scan it only once.

Even if the compiling step of the BNDM were to be cached (like the compiled 
pcre regex) in many cases it would still be slower then php_memnstr(). I've 
run a series of tests using a simple BNDM implementation (roughly based on 
your original) and while it is faster in some cases in many cases it is not. 
When the search string is short (<=5 characters) or when it is found near the 
start of the input string regular memnstr search often proves to be faster 
often by fairly significant margin. For refenrece sake I am attaching my BNDM 
& php_memnstr() test sources that I've used.

Ilia
#include 
#include 

#define NED "Dynamic_DBnested.sql"
#define STR "cvs: pear /Tree/docs Dynamic_DBnested.php Dynamic_DBnested.sql 
Memory_DBnested.php Memory_DBsimple.php Memory_XML.php config.xml 
/Tree/docs/TreeEditor config.xml index.php index.tpl mysql_db.sql treeClass.php 
/Tree/docs/TreeEditor/tmp .htaccess /Tree/docs/TreeView index.php index.tpl 
/Tree/docs/TreeView/tmp .htaccess"

/*
 * BNDM algorithm implementation
 * based on sample code by Sascha Schumann 
(http://www.mail-archive.com/dev@httpd.apache.org/msg00939.html)
 */

typedef struct {
unsigned int T[256];
unsigned int x;
} bndm_t;

inline static void bndm_compile(bndm_t *t, char *str, int str_len)
{
size_t p;
register unsigned int s = 1;

t->x = 1 << (str_len-1);
memset(t->T, 0, sizeof(unsigned int) * 256);
  
for (p = str_len - 1; p > 0; p--) { 
t->T[(int) str[p]] |= s;
s <<= 1;
}
t->T[(int) str[p]] |= s;

return;
}

static inline char *bndm (char *haystack, int haystack_len, char *needle, int 
needle_len, bndm_t *t)
{
size_t p, j, e;
register unsigned int b;

p = 0;
while (p + needle_len <= haystack_len) {
b = -1;
e = needle_len;
j = needle_len - 1;
do {
if ((b &= t->T[ haystack[p + j] ]) == 0) {
break;
}
if ((b & t->x) != 0) {
if (j == 0) {
return (haystack + p);
}
e = j;
}
j--;
b <<= 1;
} while (b != 0);
p += e;
}

return NULL;
}

int main()
{
int n = 500;
char *d;
bndm_t foo;

bndm_compile(&foo, NED, sizeof(NED)-1);
 
while (n--) {
if (!(d = bndm(STR, sizeof(STR)-1, NED, sizeof(NED)-1, &foo))) {
break;
}
}
printf("matched on: %s\n", d);
 
return 0;
}

#include 
#include 

#define PAT "Dynamic_DBnested.sql"
#define STR "cvs: pear /Tree/docs Dynamic_DBnested.php Dynamic_DBnested.sql 
Memory_DBnested.php Memory_DBsimple.php Memory_XML.php config.xml 
/Tree/docs/TreeEditor config.xml index.php index.tpl mysql_db.sql treeClass.php 
/Tree/docs/TreeEditor/tmp .htaccess /Tree/docs/TreeView index.php index.tpl 
/Tree/docs/TreeView/tmp .htaccess"

static inline char *php_memnstr(char *haystack, char *needle, int needle_len, char 
*end)
{
char *p = haystack;
char ne = needle[needle_len-1];

end -= needle_len;

while (p <= end) {
if ((p = memchr(p, *needle, (end-p+1))) && ne == p[needle_len-1]) {
if (!memcmp(needle, p, needle_len-1)) {
return p;
}
}

if (p == NULL) {
return NULL;
}

p++;
}

return NULL;
}

int main()
{
int n = 500;
char *d;
 
while (n--) {
if (!(d = php_memnstr(STR, PAT, sizeof(PAT)-1, STR + sizeof(STR)-1))) {
break;
}
}
printf("matched on: %s\n", d);
  

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

[Sascha Schumann]

> 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.net, and in IRC) to
> say this should go in.

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 algorithm (I may say so, I wrote it years ago)

- allows us to combine multiple patterns into one search (I
  have not studied that part of the paper yet). This would
  enable us to optimize the case where you pass arrays to
  str_replace.  Instead of scanning the "haystack" one time
  per replacement text, we would scan it only once.

- Sascha

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Sara Golemon]

> 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 bugs.php.net, and in IRC) to
say this should go in.

I'm on my way home now, If I havn't heard a showstopper in the next 4-5
hours, I'll go ahead and apply it.

-Pollita






-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Marcus Börger]

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.


+1 (It is not so important if we know how to emulate this one. It's about our
usesers..we should not leave the focus on the users.)

marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Edin Kadribasic]

> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Sara Golemon]

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 what the resulting string.c looks like:

http://169.229.139.97/test/string-4.c

Yes the patch is getting larger, but the resulting codebase is shrinking...

-Pollita




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stephen Thorne]

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 used
> 'small' strings, since that is what I imagine is most common usage of the
> function.
>
> Ilia

Large html files might be another good test. As I've often seen crude template 
created with str_replace.

I'm having fun actually getting round to investigating this. I've always just 
believed what the manual says "if you don't need the power of regex, use 
str_replace instead".

I wonder if we should include ereg in our benchmarks too..

Regards
Stephen Thorne.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Ilia A.]

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 imagine is most common usage of the 
function.

Ilia
 $val) {
$input[$key][1] = '!' . $val[1] . '!';
}

$start = getmicrotime();

for ($i = 0; $i < 10; $i++) {
foreach($input as $ent) {
preg_replace($ent[1], $ent[2], $ent[0]);
}
}

$end = getmicrotime();

echo "preg_replace took: ".($end - $start)."\n";

foreach($input as $key => $val) {
$input[$key][1] .= 'i';
}

$start = getmicrotime();

for ($i = 0; $i < 10; $i++) {
foreach($input as $ent) {
preg_replace($ent[1], $ent[2], $ent[0]);
}
}

$end = getmicrotime();

echo "preg_replace(i) took: ".($end - $start)."\n";
?>

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stephen Thorne]

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 thought. Probably deserves a better comparison tho. From these 
results I'll probably stop yelling at people for using preg_replace when 
str_replace will do.

Regards
Stephen Thorne.

On Thu, 30 Jan 2003 08:50, Stephen Thorne wrote:
> 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 case sensitivity is added
> > to the mix I believe the speed difference would be minimal. I've done
> > some benchmarks and the speed difference between str_replace() and
> > preg_replace() is only about 1/2 second in across 10 executions (5
> > replaces per instance). Another .6 of a second is added when
> > preg_replace() is used with 'i' flag which makes it case insensitive. I
> > have not benchmarked the stri_replace code but I imagine it would be in
> > the same ballpark, meaning that we are adding a fairly large chunk of
> > code for performance benefit of a 1 microsecond (1 millionth of a second)
> > per instance.
> >
> > Ilia
>
> Lies, damn lies and statistics.
>
> You say the difference is only 1/2 second accross 10 executions, but
> that means nothing unless you put it in context of how long the 10
> executions took. 1/2 second could mean 90% difference or 1% differene.
>
> I wrote a very unscientific script to do a simple benchmark
>
>  include('stopwatch.inc');
> $SW = new StopWatch;
> for ($i=0;$i<50;$i++)
> str_replace('abcdefgh', 'def',
> 'fkjdals;fjdsakl;fjdsakl;fjdskl;fadabcdefghfdsafdsafdsa');
> $SW->Stop();
>
> for ($i=0;$i<50;$i++)
> preg_replace('/abcdefgh/', 'def',
> 'fkjdals;fjdsakl;fjdsakl;fjdskl;fadabcdefghfdsafdsafdsa');
> $SW->Stop();
> ?>
>
> I did quite a few runs and picked the upper and lower end of the results to
> paste here
>
> Biggest difference
> Total Time: 00:00:03.00
> Total Time: 00:00:08.90
>
> Smallest difference
> Total Time: 00:00:03.12
> Total Time: 00:00:06.94
>
> Bearing in mind this is on a pre-working-hours quad hyperthreaded 1.4ghz
> xeon box. So I've got a cpu just about all to myself here.
>
> Regards,
> Stephen Thorne.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stephen Thorne]

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 case sensitivity is added
> to the mix I believe the speed difference would be minimal. I've done some
> benchmarks and the speed difference between str_replace() and
> preg_replace() is only about 1/2 second in across 10 executions (5
> replaces per instance). Another .6 of a second is added when preg_replace()
> is used with 'i' flag which makes it case insensitive. I have not
> benchmarked the stri_replace code but I imagine it would be in the same
> ballpark, meaning that we are adding a fairly large chunk of code for
> performance benefit of a 1 microsecond (1 millionth of a second) per
> instance.
>
> Ilia

Lies, damn lies and statistics.

You say the difference is only 1/2 second accross 10 executions, but that 
means nothing unless you put it in context of how long the 10 executions 
took. 1/2 second could mean 90% difference or 1% differene.

I wrote a very unscientific script to do a simple benchmark

Stop();

for ($i=0;$i<50;$i++)
preg_replace('/abcdefgh/', 'def', 
'fkjdals;fjdsakl;fjdsakl;fjdskl;fadabcdefghfdsafdsafdsa');
$SW->Stop();
?>

I did quite a few runs and picked the upper and lower end of the results to 
paste here 

Biggest difference
Total Time: 00:00:03.00
Total Time: 00:00:08.90

Smallest difference
Total Time: 00:00:03.12
Total Time: 00:00:06.94

Bearing in mind this is on a pre-working-hours quad hyperthreaded 1.4ghz xeon 
box. So I've got a cpu just about all to myself here.

Regards,
Stephen Thorne.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Dan Kalowsky]

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 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 the speed difference would be minimal.
> >
> 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?)
>
> The parameter accepting still needs to be fixed though, I copied most of
> the str_ireplace code from str_replace and forgot to clean that section up
> and make it nicer.  I'll save that for *if* a quorum can be reached to
> include it at all.
>
> 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.
>
> -Pollita
>
>
>
>
>

>---<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springsteen

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Sara Golemon]

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 it wasn't documented yet.
>
>The BM algorithm is outdated and can savely be dropped.
>
>- Sascha
>
That simplifies implementation then :)  Here's a patch that takes out
the boyer implementation and cleans up the parameter accepting in both
str_replace and str_ireplace.  It also avoids the _ex business since
replace_in_subject is a static method which is only called by
str_replace str_ireplace anyway.  I also reduced php_str_to_str back to
a single implementation by passing the case_sensitivity parameter to it,
but since it's a PHPAPI function I also renamed it *_ex and created a
passthrough for BC.

http://169.229.139.97/test/str_ireplace.diff-3.txt

The "large chunk of added code" is getting diminishingly smaller...
though I suppose str_replace and str_ireplace could be turned into
passthrough wrappers for a unified version, but that's probably going
further than necessary.

-Pollita




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Shane Caraveo]

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 believe the speed difference would be minimal. I've done some 
benchmarks and the speed difference between str_replace() and preg_replace() 
is only about 1/2 second in across 10 executions (5 replaces per 
instance). Another .6 of a second is added when preg_replace() is used with 
'i' flag which makes it case insensitive. I have not benchmarked the 
stri_replace code but I imagine it would be in the same ballpark, meaning 
that we are adding a fairly large chunk of code for performance benefit of a 
1 microsecond (1 millionth of a second) per instance.

Ilia


What's the benchmark code?  How is the benchmark difference on large 
text (ie. 100K of text) vs. small text (1K or smaller)?

Shane


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Sascha Schumann]

> 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 outdated and can savely be dropped.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Sascha Schumann]

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

http://www.mail-archive.com/dev@httpd.apache.org/msg00939.html

The above paper also discusses extending the algorithm to
cover character classes (case insensitivity).

(*) I had incorporated it into PHP, if I had found a way to
nicely offset the compilation step.  This proved to be the
major obstacle for small sets.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Sara Golemon]

>> 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 the speed difference would be minimal.
>
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?)

The parameter accepting still needs to be fixed though, I copied most of
the str_ireplace code from str_replace and forgot to clean that section up
and make it nicer.  I'll save that for *if* a quorum can be reached to
include it at all.

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.

-Pollita




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Ilia A.]

> 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 the speed difference would be minimal. I've done some 
benchmarks and the speed difference between str_replace() and preg_replace() 
is only about 1/2 second in across 10 executions (5 replaces per 
instance). Another .6 of a second is added when preg_replace() is used with 
'i' flag which makes it case insensitive. I have not benchmarked the 
stri_replace code but I imagine it would be in the same ballpark, meaning 
that we are adding a fairly large chunk of code for performance benefit of a 
1 microsecond (1 millionth of a second) per instance.

Ilia

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Shane Caraveo]

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 avoids creating php_memnstri by simply
searching through a copy of haystack which is strtolowered against a
strtolowered version of needle (no need to copy that part).

http://169.229.139.97/test/str_ireplace.diff-2.txt

Should be quicker and cleaner at the cost of a small malloc in the
estrndup call.



I still don;t see no real use for this function, you can easily do this 
with eregi_replace() or preg_replace().

Derick

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.

Shane



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Derick Rethans]

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 creating php_memnstri by simply
> searching through a copy of haystack which is strtolowered against a
> strtolowered version of needle (no need to copy that part).
> 
> http://169.229.139.97/test/str_ireplace.diff-2.txt
> 
> Should be quicker and cleaner at the cost of a small malloc in the
> estrndup call.

I still don;t see no real use for this function, you can easily do this 
with eregi_replace() or preg_replace().

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Sara Golemon]

> 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 of haystack which is strtolowered against a
strtolowered version of needle (no need to copy that part).

http://169.229.139.97/test/str_ireplace.diff-2.txt

Should be quicker and cleaner at the cost of a small malloc in the
estrndup call.

-Pollita



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Andrey Hristov]

 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 implementation of the class is.
AFAIK there won't be 4.4.0 but 5.0.0 after 4.3.0 and also new code won't be
introduced in 4.3.x
only bugfixes (if anyone has objections please correct me). Therefore in
php5 there will be similar functionality.

Regards,
Andrey

- Original Message -
From: "Brian T. Allen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 13, 2003 10:21 PM
Subject: [PHP-DEV] Feature Request: Auto Include a Function


> Hi,
>
> Please accept my apologies in advance if this is not the correct place
> for this request.
>
> This may exist, but I haven't been able to find it, and I think it would
> be REALLY helpful and convenient.
>
> The idea is this:
>
> When you write a script and call a function:
>
> 
> $whatever = previously_uncalled_function("one","two");
>
> ?>
>
> PHP could automatically look for a file named
> "previously_uncalled_function" in your /include/functions/ (or whatever)
> directory.
>
> This would eliminate a LOT of include() and require() calls (or at least
> make them automatic) in a script.  The function would only get read in
> if it was used.  Functions could still be explicitly included or
> required as they currently are.
>
> I *think* the overhead would be about the same as the initial include()
> or require() call would have been.
>
> This would be very convenient.  When you create a new function you drop
> it in that directory (with a very specific, unique name, of course), and
> it can immediately be called anywhere in the site.  And, you only incur
> the disk IO to read it when its used for the first time in a script.
>
> The 3 things I want to avoid are:
>
> 1)  Explicitly including every function, every time it's needed.
> 2)  Disk IO of including a function when it's not needed.
> 3)  Taking the easy route and including a file with a bunch of functions
> when most won't get called.
>
> Does this already exist, or is this a good idea (if not, any reasons
> why)?  I personally would love to see it implemented if it isn't
> already.
>
> One possibility for implementation is just prior to the "undeclared
> function" error message, try to auto include the function prior to
> generating the error message.
>
> Thanks,
> Brian Allen
> [EMAIL PROTECTED]
>
>
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Derick Rethans]

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
> 2) If the function doesn't exist check the hash file and include it
> 3) If it's not in the hash file search for it, include it, then hash it
> 4) If it can't be found issue an error message

quoting G.S.:

"i think php should be smart enough to recognize my typos and
 then include the appropriate library for any function call I make.  
 Unless I include it from two places, in which case it should always
 choose the file on the left."

"Oh, and I just realized that in some countries code inclusion is right
 handed (britain, singapore, australia and brunei I believe).  Do you
 think you could incorporate LOCALE support into the auto-includer to
 appropriately choose the right file except in non-leftist countries?"

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Sterling Hughes]

Hi Brian,

thanks for your comments, I'll be working on this, expect an
implementation sometime in the near future, and structure your code
accordingly!

-Sterling

On Mon, 2003-01-13 at 17:01, Brian T. Allen wrote:
> > 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 use it 12 hours a day in my work.
> 
> 
> > 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.
> 
> 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
> 2) If the function doesn't exist check the hash file and include it
> 3) If it's not in the hash file search for it, include it, then hash it
> 4) If it can't be found issue an error message
> 
> If there we're no subdirectories there would be no more overhead than
> for a file_exists() call.
> 
> 
> > Also what happens if you spell a function wrong, OR it finds 
> > 2 functions
> > with the same name in different .php files.
> 
> If you spell a function wrong it isn't going to work either way, and I
> think it's a good idea to have your function names be unique within a
> give site.
> 
> 
> > I don't think its got any real advantage over the fact that 
> > it just lets you
> > be lazy. It wouldn't be any quicker in any way.
> 
> One mans laziness is another mans efficiency. If we were after 100%
> performance we'd all be programming in machine lanquage.  But that fact
> is I personally use PHP over other solutions because it's easier to
> develop in.
> 
> Given the chance I'll sacrifice a little (in this case very little)
> performance to speed up and simplify development.  At $50 an hour and 8
> hours per day, ~my~ CPU cycles are worth $8,000 per month.  I pay $100 a
> month for a server with the majority of CPU cycles going to waste.
> Personally I'd rather optimize the $8,000 rather than the $100.
> 
> Not everyone is in my shoes, but adding this won't effect them.  The
> little bit of overhead to automatically include functions is ONLY
> incurred if the function isn't included to begin with.  So existing
> scripts and programming styles won't be affected at all.
> 
> But I think it would simplify things a LOT on a big site with lots of
> functions.
> 
> > If this was a compilable language then sure it would of been 
> > nice, like C
> > does searching through .h files, but since its not I don't 
> > think its a good
> > idea.
> > 
> > Andrew
> 
> Thanks for the reply!
> 
> Brian
> 
> 
> > - Original Message -
> > From: "Brian T. Allen" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, January 13, 2003 8:21 PM
> > Subject: [PHP-DEV] Feature Request: Auto Include a Function
> > 
> > 
> > > Hi,
> > >
> > > Please accept my apologies in advance if this is not the 
> > correct place
> > > for this request.
> > >
> > > This may exist, but I haven't been able to find it, and I 
> > think it would
> > > be REALLY helpful and convenient.
> > >
> > > The idea is this:
> > >
> > > When you write a script and call a function:
> > >
> > >  > >
> > > $whatever = previously_uncalled_function("one","two");
> > >
> > > ?>
> > >
> > > PHP could automatically look for a file named
> > > "previously_uncalled_function" in your /include/functions/ 
> > (or whatever)
> > > directory.
> > >
> > > This would eliminate a LOT of include() and require() calls 
> > (or at least
> > > make them automatic) in a script.  The function would only 
> > get read in
> > > if it was used.  Functions could still be explicitly included or
> > > required as they currently are.
> > >
> > > I *think* the overhead would be about the same as the 
> > initial include()
> > > or requi

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

[Brian T. Allen]

> 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 use it 12 hours a day in my work.


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

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
2) If the function doesn't exist check the hash file and include it
3) If it's not in the hash file search for it, include it, then hash it
4) If it can't be found issue an error message

If there we're no subdirectories there would be no more overhead than
for a file_exists() call.


> Also what happens if you spell a function wrong, OR it finds 
> 2 functions
> with the same name in different .php files.

If you spell a function wrong it isn't going to work either way, and I
think it's a good idea to have your function names be unique within a
give site.


> I don't think its got any real advantage over the fact that 
> it just lets you
> be lazy. It wouldn't be any quicker in any way.

One mans laziness is another mans efficiency. If we were after 100%
performance we'd all be programming in machine lanquage.  But that fact
is I personally use PHP over other solutions because it's easier to
develop in.

Given the chance I'll sacrifice a little (in this case very little)
performance to speed up and simplify development.  At $50 an hour and 8
hours per day, ~my~ CPU cycles are worth $8,000 per month.  I pay $100 a
month for a server with the majority of CPU cycles going to waste.
Personally I'd rather optimize the $8,000 rather than the $100.

Not everyone is in my shoes, but adding this won't effect them.  The
little bit of overhead to automatically include functions is ONLY
incurred if the function isn't included to begin with.  So existing
scripts and programming styles won't be affected at all.

But I think it would simplify things a LOT on a big site with lots of
functions.

> If this was a compilable language then sure it would of been 
> nice, like C
> does searching through .h files, but since its not I don't 
> think its a good
> idea.
> 
> Andrew

Thanks for the reply!

Brian


> - Original Message -
> From: "Brian T. Allen" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, January 13, 2003 8:21 PM
> Subject: [PHP-DEV] Feature Request: Auto Include a Function
> 
> 
> > Hi,
> >
> > Please accept my apologies in advance if this is not the 
> correct place
> > for this request.
> >
> > This may exist, but I haven't been able to find it, and I 
> think it would
> > be REALLY helpful and convenient.
> >
> > The idea is this:
> >
> > When you write a script and call a function:
> >
> >  >
> > $whatever = previously_uncalled_function("one","two");
> >
> > ?>
> >
> > PHP could automatically look for a file named
> > "previously_uncalled_function" in your /include/functions/ 
> (or whatever)
> > directory.
> >
> > This would eliminate a LOT of include() and require() calls 
> (or at least
> > make them automatic) in a script.  The function would only 
> get read in
> > if it was used.  Functions could still be explicitly included or
> > required as they currently are.
> >
> > I *think* the overhead would be about the same as the 
> initial include()
> > or require() call would have been.
> >
> > This would be very convenient.  When you create a new 
> function you drop
> > it in that directory (with a very specific, unique name, of 
> course), and
> > it can immediately be called anywhere in the site.  And, 
> you only incur
> > the disk IO to read it when its used for the first time in a script.
> >
> > The 3 things I want to avoid are:
> >
> > 1)  Explicitly including every function, every time it's needed.
> > 2)  Disk IO of including a function when it's not needed.
> > 3)  Taking the easy route and including a file with a bunch 
> of functions
> > when most won't get called.
> >
> > Does this already exist, or is this a good idea (if not, an

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

[Andrew Brampton]

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 happens if you spell a function wrong, OR it finds 2 functions
with the same name in different .php files.

I don't think its got any real advantage over the fact that it just lets you
be lazy. It wouldn't be any quicker in any way.

If this was a compilable language then sure it would of been nice, like C
does searching through .h files, but since its not I don't think its a good
idea.

Andrew
- Original Message -
From: "Brian T. Allen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 13, 2003 8:21 PM
Subject: [PHP-DEV] Feature Request: Auto Include a Function


> Hi,
>
> Please accept my apologies in advance if this is not the correct place
> for this request.
>
> This may exist, but I haven't been able to find it, and I think it would
> be REALLY helpful and convenient.
>
> The idea is this:
>
> When you write a script and call a function:
>
> 
> $whatever = previously_uncalled_function("one","two");
>
> ?>
>
> PHP could automatically look for a file named
> "previously_uncalled_function" in your /include/functions/ (or whatever)
> directory.
>
> This would eliminate a LOT of include() and require() calls (or at least
> make them automatic) in a script.  The function would only get read in
> if it was used.  Functions could still be explicitly included or
> required as they currently are.
>
> I *think* the overhead would be about the same as the initial include()
> or require() call would have been.
>
> This would be very convenient.  When you create a new function you drop
> it in that directory (with a very specific, unique name, of course), and
> it can immediately be called anywhere in the site.  And, you only incur
> the disk IO to read it when its used for the first time in a script.
>
> The 3 things I want to avoid are:
>
> 1)  Explicitly including every function, every time it's needed.
> 2)  Disk IO of including a function when it's not needed.
> 3)  Taking the easy route and including a file with a bunch of functions
> when most won't get called.
>
> Does this already exist, or is this a good idea (if not, any reasons
> why)?  I personally would love to see it implemented if it isn't
> already.
>
> One possibility for implementation is just prior to the "undeclared
> function" error message, try to auto include the function prior to
> generating the error message.
>
> Thanks,
> Brian Allen
> [EMAIL PROTECTED]
>
>
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Andi Gutmans]

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 can't
>express how anxiously I've been waiting for the class model to be reworked.
>Great job!
>
>I would, however, like to see a couple of simple additions to the planned
>release (if these are already coming, then I just haven't seen is talked
>about anywhere).  I would love to have "method" as an alias for "function"
>and "member" as an alias for "var".  These could be just plain aliases, but
>it would be nice if these aliases were only valid within a class definition.
>
>I would love to hear peoples thoughts on this one.  Where I work, the kind of
>software we write on PHP,  it only makes sense to use objects.  However, we
>do mix in plain functions liberally when there is no need for the features of
>an object.  I've worked this way with PHP ever since 4.0.0 was released.
>--
>Sincerely,
>Lamont R. Peterson <[EMAIL PROTECTED]>
>801-580-7323 [cell]
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Lukas Smith]

I agree

Regards,
Lukas Smith
[EMAIL PROTECTED]
___
 DybNet Internet Solutions GbR
 Reuchlinstr. 10-11
 Gebäude 4 1.OG Raum 6 (4.1.6)
 10553 Berlin
 Germany
 Tel. : +49 30 83 22 50 00
 Fax  : +49 30 83 22 50 07
 www.dybnet.de [EMAIL PROTECTED]

> -Original Message-
> 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
> 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 adds yet another type of
declaration
> that
> someone would have to learn to debug code that used the 'method'
> declaration
> instead of the 'function' declaration.
> 
> From a semantic point of view, using 'function' visually demarcates
the
> beginning
> of an series of operations. As such, scrolling through a class with
many
> 'method's
> interspersed with 'function' declarations can get messy.
> 
> If on the other hand, 'method' had some specific meaning outside of
the
> class
> context, it would make sense to incorporate it into the lexer.
> 
> The same argument applies to the use of 'member'. These are semantic
> constructs,
> not syntactic constructs, and as such only have value when there is
> additional
> meaning inherent in their use.
> 
> Syntactic constructs for an ubiquitous language like PHP should be
simple
> and
> uniform with little or no gobbledygook like some other languages which
> shall remain
> nameless (and no I'm not thinking of smalltalk.).
> 
> PHP should look like PHP. PHP should not look like smalltalk. It's
like
> saying we
> should all write C++ in Delphi or write Perl in Python.
> 
> Let's keep it simple and stick with the 'function' and 'var'
declarations
> unless
> there is a need for a separate syntactic construct that has value
outside
> of a
> class context.
> 
> My two cents.
> 
> Any other takers?
> 
> Shamim Islam
> BA BSc
> 
> Lamont R. Peterson ([EMAIL PROTECTED]) 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!
> >
> >I would, however, like to see a couple of simple additions to the
planned
> >release (if these are already coming, then I just haven't seen is
talked
> >about anywhere).  I would love to have "method" as an alias for
> "function"
> >and "member" as an alias for "var".  These could be just plain
aliases,
> but
> >it would be nice if these aliases were only valid within a class
> definition.
> >
> >I would love to hear peoples thoughts on this one.  Where I work, the
> kind of
> >software we write on PHP,  it only makes sense to use objects.
However,
> we
> >do mix in plain functions liberally when there is no need for the
> features of
> >an object.  I've worked this way with PHP ever since 4.0.0 was
released.
> >
> >
> 
> 
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Shamim Islam]

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 adds yet another type of declaration that
someone would have to learn to debug code that used the 'method' declaration
instead of the 'function' declaration.

>From a semantic point of view, using 'function' visually demarcates the beginning
of an series of operations. As such, scrolling through a class with many 'method's
interspersed with 'function' declarations can get messy.

If on the other hand, 'method' had some specific meaning outside of the class
context, it would make sense to incorporate it into the lexer.

The same argument applies to the use of 'member'. These are semantic constructs,
not syntactic constructs, and as such only have value when there is additional
meaning inherent in their use.

Syntactic constructs for an ubiquitous language like PHP should be simple and
uniform with little or no gobbledygook like some other languages which shall remain
nameless (and no I'm not thinking of smalltalk.).

PHP should look like PHP. PHP should not look like smalltalk. It's like saying we
should all write C++ in Delphi or write Perl in Python.

Let's keep it simple and stick with the 'function' and 'var' declarations unless
there is a need for a separate syntactic construct that has value outside of a
class context.

My two cents.

Any other takers?

Shamim Islam
BA BSc

Lamont R. Peterson ([EMAIL PROTECTED]) 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!
>
>I would, however, like to see a couple of simple additions to the planned
>release (if these are already coming, then I just haven't seen is talked
>about anywhere).  I would love to have "method" as an alias for "function"
>and "member" as an alias for "var".  These could be just plain aliases, but
>it would be nice if these aliases were only valid within a class definition.
>
>I would love to hear peoples thoughts on this one.  Where I work, the kind of
>software we write on PHP,  it only makes sense to use objects.  However, we
>do mix in plain functions liberally when there is no need for the features of
>an object.  I've worked this way with PHP ever since 4.0.0 was released.
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Sascha Cunz]

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

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.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Pierre-Alain Joye]

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.

[Sebastian Bergmann]

"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 List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Lamont R. Peterson]

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 PROTECTED] wrote:
> Uhm... 4.3.0 will not ship with Zend 2.0, that will b ethe honour of PHP
> 5.0.0.

From www.php.net:
"[30-Jun-2002]  The second alpha release of PHP w/Zend Engine 2 is now 
available.  It is based on the current PHP 4 CVS (4.3.0-dev) and includes the 
new scripting engine which greatly improces the object model..."

Re-reading this announcement in the light of your comment above, I can see 
that this does not state that PHP 4.3.0 will be with Zend 2.0.  However, I 
haven't seen on www.php.net nor www.zend.com anything that ever even mentions 
PHP 5.0.0.

I've hunted down everything I could find to read (including some PDF files) 
about the objects (and other things) in Zend 2.0. If there is such 
information in these public places, please, tell me where I can read it.

> What is the reasoning to add aliases? IMO it just pollutes the language.

I would have to agree; IMO, PHP is riddled with such aliases.  However, I can 
fully understand & appreciate how and why most of them have come to be.

I suggest them as aliases for thwo reasons:  1)  I don't see any true 
functionality differences needed; and 2) I don't want peoples classes written 
with "var" & "function" to melt down when they move their code to PHP on Zend 
2.0.
-- 
Sincerely,
Lamont R. Peterson <[EMAIL PROTECTED]>
801-580-7323 [cell]

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[derick]

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 PHP 
5.0.0.

> I would, however, like to see a couple of simple additions to the planned 
> release (if these are already coming, then I just haven't seen is talked 
> about anywhere).  I would love to have "method" as an alias for "function" 
> and "member" as an alias for "var".  These could be just plain aliases, but 
> it would be nice if these aliases were only valid within a class definition.
>
> I would love to hear peoples thoughts on this one.  Where I work, the kind of 
> software we write on PHP,  it only makes sense to use objects.  However, we 
> do mix in plain functions liberally when there is no need for the features of 
> an object.  I've worked this way with PHP ever since 4.0.0 was released.

What is the reasoning to add aliases? IMO it just pollutes the language.

regards,
Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Shane Caraveo]

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 
resolved to any local namespace. Directory junctions provide a very 
powerful tool for system administrators, but are not generally 
deployed—they can only be created with the Linkd.exe tool in the Windows 
2000 Resource Kit. Because NTFS directory junctions can be used to make 
the storage namespace span volumes, they may present new subtleties for 
application developers.

A key phrase here, 'local namespace'.  Basicly, they ARE symlinks for 
directories.

http://www.winnetmag.com/Articles/Index.cfm?ArticleID=8321
http://www.microsoft.com/windows2000/techinfo/howitworks/fileandprint/stordev.asp
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction

And if someone was really wanting symlinks for files, Reparse Points 
could be used to implement a file system filter that implements them.

Shane


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Timo Weingärtner]

you're right, it could be a problem when they are targetted at files, but
why can't you just include a check on the target, if it is a directory or
not, just like it is done in the code by Mark Russinovich? I think that will
prevent such bugos entries. Of course we will also have to check, 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 fact they're directory junctions is pretty important here, since
they do NOT work like symlinks.  They work similarly to symlinks if you use
them on directories, but they were created for a different purpose
altogether.  They were created to give Windows users something similar to
the ability to mount a filesystem into a directory, instead of a different
volume (e.g., mount a filesystem into C:\Documents and Settings, instead of
D:\).
As far as I know you cannot use them to create symlinks for files, which
means they're not equivalent of UNIX symlinks at all.  What happens when
you use your functions on files?  My guess is that they create bogus
entries.

Zeev

At 12:30 PM 7/7/2002, Timo Weingärtner wrote:
>As I said they are directory junctions, but they work like symlinks. I
>wanted to ask if you could include it in one of the next versions of PHP,
>because I don't know much about programming in C. In the meantime I wrote a
>PHP script that executes the tool mentioned below and processes the output,
>but that's not very fast. I think it should be faster if the required code
>would be included in PHP itself. I know that 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
>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, 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 a tool that can create, read and delete such junctions.
> >Is there are posiibility to include that code into php so that it
supports
> >it in realpath(), symlink(), linkinfo(), readlink(), filetype(),
is_link(),
> >stat(), lstat()?
> >The complete source code can be found at:
> >http://www.sysinternals.com/files/jnctnsrc.zip
> >
> >
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Zeev Suraski]

Again, the fact they're directory junctions is pretty important here, since 
they do NOT work like symlinks.  They work similarly to symlinks if you use 
them on directories, but they were created for a different purpose 
altogether.  They were created to give Windows users something similar to 
the ability to mount a filesystem into a directory, instead of a different 
volume (e.g., mount a filesystem into C:\Documents and Settings, instead of 
D:\).
As far as I know you cannot use them to create symlinks for files, which 
means they're not equivalent of UNIX symlinks at all.  What happens when 
you use your functions on files?  My guess is that they create bogus entries.

Zeev

At 12:30 PM 7/7/2002, Timo Weingärtner wrote:
>As I said they are directory junctions, but they work like symlinks. I
>wanted to ask if you could include it in one of the next versions of PHP,
>because I don't know much about programming in C. In the meantime I wrote a
>PHP script that executes the tool mentioned below and processes the output,
>but that's not very fast. I think it should be faster if the required code
>would be included in PHP itself. I know that 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
>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, 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 a tool that can create, read and delete such junctions.
> >Is there are posiibility to include that code into php so that it supports
> >it in realpath(), symlink(), linkinfo(), readlink(), filetype(), is_link(),
> >stat(), lstat()?
> >The complete source code can be found at:
> >http://www.sysinternals.com/files/jnctnsrc.zip
> >
> >
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Timo Weingärtner]

As I said they are directory junctions, but they work like symlinks. I
wanted to ask if you could include it in one of the next versions of PHP,
because I don't know much about programming in C. In the meantime I wrote a
PHP script that executes the tool mentioned below and processes the output,
but that's not very fast. I think it should be faster if the required code
would be included in PHP itself. I know that 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
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, 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 a tool that can create, read and delete such junctions.
>Is there are posiibility to include that code into php so that it supports
>it in realpath(), symlink(), linkinfo(), readlink(), filetype(), is_link(),
>stat(), lstat()?
>The complete source code can be found at:
>http://www.sysinternals.com/files/jnctnsrc.zip
>
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Zeev Suraski]

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 a tool that can create, read and delete such junctions.
>Is there are posiibility to include that code into php so that it supports
>it in realpath(), symlink(), linkinfo(), readlink(), filetype(), is_link(),
>stat(), lstat()?
>The complete source code can be found at:
>http://www.sysinternals.com/files/jnctnsrc.zip
>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] feature request

[Stig S. Bakken]

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
> the argv[0] so that the name that appears in a 'ps' can be changed.
> 
> The reason is simple, as many people do, I usually have php call a
> shell script or a perl script on the system for some tasks, this is done
> after an authentication and having the command line passed to the
> shell is even worse than having no authentication at all. Is there a
> particular reason why it was not implemented ?
> 
> -- veins
> a bofh said: I too can bore you with useless encrypted keys...
> "? ssa ruoy pu ti evohs dna yek pgp ruoy ekat uoy t'nod yhw"
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
-- 
Stig Sæther Bakken, Fast Search & Transfer ASA, Trondheim, Norway
http://pear.php.net/wishlist.php/ssb


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Steve Meyers]

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 -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
>> 
>> ./configure --with-mysql=/usr --with-pgsql --enable-ftp --with-ldap
>> --with-gmp --disable-pear --enable-shmop --enable-apc
>> --with-apache=/usr/local/src/apache_1.3.24 --enable-track-vars
>> --with-msession
>> 
>> I tried it with 4.1.2, and since that didn't work, I tried 4.2.1RC1, with
>> the same result.  I'm also using mod_ssl, if that matters.
>> 
>> Do you need a backtrace of it?  If so, how do I do that?
>> 
>> 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
>> > 
>> > On Sat, May 04, 2002 at 11:08:52AM +0200, Michael Virnstein wrote :
>> >> Hi!
>> >> 
>> >> What really would be useful for the session module,
>> >> is a grouping mechanism for sessions, so i can set up
>> >> variable scopes and share variables among different
>> >> session:
>> >> every session has private variables. that's the way it
>> >> works now. i can register a variable to a session
>> >> and there's no way to share them with other sessions
>> >> with the standard php features. but what if i could set
>> >> up session groups, each with a own set of local variables.
>> >> i could register my session to the desired groups, and
>> >> gain access to their local variables. I could set up as many
>> >> session groups as I want to. This would be the most flexible
>> >> solution imo.
>> >> 
>> >> Regards Michael
>> >> 
>> >> 
>> >> 
>> >> --
>> >> PHP Development Mailing List 
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> > 
>> 
>> 
>> --
>> PHP Development Mailing List 
>> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Sebastian Bergmann]

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://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Markus Fischer]

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
> 
> ./configure --with-mysql=/usr --with-pgsql --enable-ftp --with-ldap 
> --with-gmp --disable-pear --enable-shmop --enable-apc 
> --with-apache=/usr/local/src/apache_1.3.24 --enable-track-vars 
> --with-msession
> 
> I tried it with 4.1.2, and since that didn't work, I tried 4.2.1RC1, with 
> the same result.  I'm also using mod_ssl, if that matters.
> 
> Do you need a backtrace of it?  If so, how do I do that?
> 
> 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
> > 
> > On Sat, May 04, 2002 at 11:08:52AM +0200, Michael Virnstein wrote :
> >> Hi!
> >> 
> >> What really would be useful for the session module,
> >> is a grouping mechanism for sessions, so i can set up
> >> variable scopes and share variables among different
> >> session:
> >> every session has private variables. that's the way it
> >> works now. i can register a variable to a session
> >> and there's no way to share them with other sessions
> >> with the standard php features. but what if i could set
> >> up session groups, each with a own set of local variables.
> >> i could register my session to the desired groups, and
> >> gain access to their local variables. I could set up as many
> >> session groups as I want to. This would be the most flexible
> >> solution imo.
> >> 
> >> Regards Michael
> >> 
> >> 
> >> 
> >> --
> >> PHP Development Mailing List 
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
"Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Steve Meyers]

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=/usr/local/src/apache_1.3.24 --enable-track-vars 
--with-msession

I tried it with 4.1.2, and since that didn't work, I tried 4.2.1RC1, with 
the same result.  I'm also using mod_ssl, if that matters.

Do you need a backtrace of it?  If so, how do I do that?

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
> 
> On Sat, May 04, 2002 at 11:08:52AM +0200, Michael Virnstein wrote :
>> Hi!
>> 
>> What really would be useful for the session module,
>> is a grouping mechanism for sessions, so i can set up
>> variable scopes and share variables among different
>> session:
>> every session has private variables. that's the way it
>> works now. i can register a variable to a session
>> and there's no way to share them with other sessions
>> with the standard php features. but what if i could set
>> up session groups, each with a own set of local variables.
>> i could register my session to the desired groups, and
>> gain access to their local variables. I could set up as many
>> session groups as I want to. This would be the most flexible
>> solution imo.
>> 
>> Regards Michael
>> 
>> 
>> 
>> --
>> PHP Development Mailing List 
>> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Yasuo Ohgaki]

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 session_pgsql or srm if you need application
level variables for sevral servers.

For session_pgsql, you need serializable transaction
isolation if you need strict consistency. Serializable
tranzaction isolation would be bottle neck of
performance, so use it with caution.

--
Yasuo Ohgaki




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Markus Fischer]

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 be useful for the session module,
> is a grouping mechanism for sessions, so i can set up
> variable scopes and share variables among different
> session:
> every session has private variables. that's the way it
> works now. i can register a variable to a session
> and there's no way to share them with other sessions
> with the standard php features. but what if i could set
> up session groups, each with a own set of local variables.
> i could register my session to the desired groups, and
> gain access to their local variables. I could set up as many
> session groups as I want to. This would be the most flexible
> solution imo.
> 
> Regards Michael
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
"Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Robert Cummings]

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 array with the call stack for the current function
which includes the calling file, funcion and line number. Use a print_r()
on the results to get a better idea. Please don't flame me for not
releasing or following coding style.

Cheers,
Rob.
-

[EMAIL PROTECTED] wrote:
> 
> 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 yet, but I can add a
> > function for that too.
> >
> > I'll keep you posted,
> 
> 
> 
> Thanks, I've wished for this for a long time!

-- 
.-.
| Robert Cummings |
:-`.
| Webdeployer - Chief PHP and Java Programmer  |
:--:
| Mail  : mailto:[EMAIL PROTECTED] |
| Phone : (613) 731-4046 x.109 |
:--:
| Website : http://www.webmotion.com   |
| Fax : (613) 260-9545 |
`--'


ftrace.tar.gz
Description: GNU Zip compressed data

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Alan Knowles]

__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 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 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 will provide functions for this instead.
>>
>> - Stig
>>
>>On Wed, 2002-04-24 at 21:40, Michael Virnstein wrote:
>>
>>>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 be set.
>>>
>>>My 2 cents ;)
>>>That's how i would prefer it.
>>>
>>><[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 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 writing functions/Classes, if
>i were able to determine the __FILE__ and __LINE__ of the
>script, that is calling my function, without the need to send
>__FILE__ and __LINE__ as parameter to my function.
>E.g. __CFILE__ for calling script and __CLINE__ for line in the
>calling script would be really great.
>In addition it'll be useful, if I could use trigger_error in this
>
>>>manner.
>>>
>Most of the time i don't want to know, on which line my
>
>trigger_error
>
>call is located, but on which line in the script that called my
>
>>>function,
>>>
>the
>error occured. it'll be nice, if trigger_error could be extended, so
>
>it
>
>takes
>to more parameters, which overwrite the default __FILE__, __LINE__
>settings of trigger error.
>
>Example:
>
>function somefunction($array) {
>if (!is_array($array)) {
>trigger_error("Not an array", E_USER_ERROR, __CFILE__,
>
>>>__CLINE__);
>>>
>}
>// do something with the array
>}
>
>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>>---
>>
 Did I help you? Consider a gift:
  http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B

>>---
>>
  PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net

>>---
>>
>>>
>>>
>>>--
>>>PHP Development Mailing List 
>>>To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>
>
>




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Michael Virnstein]

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 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 will provide functions for this instead.
>
>  - Stig
>
> On Wed, 2002-04-24 at 21:40, Michael Virnstein wrote:
> > 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 be set.
> >
> > My 2 cents ;)
> > That's how i would prefer it.
> >
> > <[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 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 writing functions/Classes, if
> > > > i were able to determine the __FILE__ and __LINE__ of the
> > > > script, that is calling my function, without the need to send
> > > > __FILE__ and __LINE__ as parameter to my function.
> > > > E.g. __CFILE__ for calling script and __CLINE__ for line in the
> > > > calling script would be really great.
> > > > In addition it'll be useful, if I could use trigger_error in this
> > manner.
> > > > Most of the time i don't want to know, on which line my
trigger_error
> > > > call is located, but on which line in the script that called my
> > function,
> > > > the
> > > > error occured. it'll be nice, if trigger_error could be extended, so
it
> > > > takes
> > > > to more parameters, which overwrite the default __FILE__, __LINE__
> > > > settings of trigger error.
> > > >
> > > > Example:
> > > >
> > > > function somefunction($array) {
> > > > if (!is_array($array)) {
> > > > trigger_error("Not an array", E_USER_ERROR, __CFILE__,
> > __CLINE__);
> > > > }
> > > > // do something with the array
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List 
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > >
> >
> ---
> > >  Did I help you? Consider a gift:
> > >   http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
> >
> ---
> > >   PHP: Scripting the Web - [EMAIL PROTECTED]
> > > All your branches are belong to me!
> > > SRM: Script Running Machine - www.vl-srm.net
> >
> ---
> > >
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Michael Virnstein]

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" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 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 will provide functions for this instead.
>
>  - Stig
>
> On Wed, 2002-04-24 at 21:40, Michael Virnstein wrote:
> > 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 be set.
> >
> > My 2 cents ;)
> > That's how i would prefer it.
> >
> > <[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 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 writing functions/Classes, if
> > > > i were able to determine the __FILE__ and __LINE__ of the
> > > > script, that is calling my function, without the need to send
> > > > __FILE__ and __LINE__ as parameter to my function.
> > > > E.g. __CFILE__ for calling script and __CLINE__ for line in the
> > > > calling script would be really great.
> > > > In addition it'll be useful, if I could use trigger_error in this
> > manner.
> > > > Most of the time i don't want to know, on which line my
trigger_error
> > > > call is located, but on which line in the script that called my
> > function,
> > > > the
> > > > error occured. it'll be nice, if trigger_error could be extended, so
it
> > > > takes
> > > > to more parameters, which overwrite the default __FILE__, __LINE__
> > > > settings of trigger error.
> > > >
> > > > Example:
> > > >
> > > > function somefunction($array) {
> > > > if (!is_array($array)) {
> > > > trigger_error("Not an array", E_USER_ERROR, __CFILE__,
> > __CLINE__);
> > > > }
> > > > // do something with the array
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List 
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > >
> >
> ---
> > >  Did I help you? Consider a gift:
> > >   http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
> >
> ---
> > >   PHP: Scripting the Web - [EMAIL PROTECTED]
> > > All your branches are belong to me!
> > > SRM: Script Running Machine - www.vl-srm.net
> >
> ---
> > >
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] feature request

[Roland Tapken]

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 PROTECTED]
PGP Public Key: http://www.engter.de/~tapkenea/gnupg_roland.txt
  ~~~ I'm a signature-virus. Please copy me into your sig. ~~~

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] feature request

[Markus Fischer]

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
something like word_count() and similar friends. Though I
don't remember what has happened, you might want to look it
up in the archive an join the discussion (It was just a week
ago or so I think).

- Markus

On Wed, Apr 24, 2002 at 10:03:48PM -0700, Nikolai Devereaux wrote : 
> 
> > 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
> typing.
> 
> I'm sorry if it sounds like I am whining, but I haven't heard any good
> reasons as to WHY word_count or line_count functions are NOT built in.  All
> I've heard is "Well, you can do it like this" or "You can do it like that".
> 
> I know that.  I wouldn't have posted some alternatives in my first post if I
> wanted people to tell me that it's possible to do otherwise.
> 
> If it's so easy to implement in PHP, it shouldn't be that hard to implement
> in C either, should it?
> 
> 
> Take care,
> 
> Nik
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
"Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] feature request

[Nikolai Devereaux]

> 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
typing.

I'm sorry if it sounds like I am whining, but I haven't heard any good
reasons as to WHY word_count or line_count functions are NOT built in.  All
I've heard is "Well, you can do it like this" or "You can do it like that".

I know that.  I wouldn't have posted some alternatives in my first post if I
wanted people to tell me that it's possible to do otherwise.

If it's so easy to implement in PHP, it shouldn't be that hard to implement
in C either, should it?


Take care,

Nik


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stig S. Bakken]

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 will provide functions for this instead.

 - Stig

On Wed, 2002-04-24 at 21:40, Michael Virnstein wrote:
> 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 be set.
> 
> My 2 cents ;)
> That's how i would prefer it.
> 
> <[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 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 writing functions/Classes, if
> > > i were able to determine the __FILE__ and __LINE__ of the
> > > script, that is calling my function, without the need to send
> > > __FILE__ and __LINE__ as parameter to my function.
> > > E.g. __CFILE__ for calling script and __CLINE__ for line in the
> > > calling script would be really great.
> > > In addition it'll be useful, if I could use trigger_error in this
> manner.
> > > Most of the time i don't want to know, on which line my trigger_error
> > > call is located, but on which line in the script that called my
> function,
> > > the
> > > error occured. it'll be nice, if trigger_error could be extended, so it
> > > takes
> > > to more parameters, which overwrite the default __FILE__, __LINE__
> > > settings of trigger error.
> > >
> > > Example:
> > >
> > > function somefunction($array) {
> > > if (!is_array($array)) {
> > > trigger_error("Not an array", E_USER_ERROR, __CFILE__,
> __CLINE__);
> > > }
> > > // do something with the array
> > > }
> > >
> > >
> > >
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
> > ---
> >  Did I help you? Consider a gift:
> >   http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
> > ---
> >   PHP: Scripting the Web - [EMAIL PROTECTED]
> > All your branches are belong to me!
> > SRM: Script Running Machine - www.vl-srm.net
> > ---
> >
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] feature request

[Maxim Maletsky \(PHPBeginner.com\)]

> 
> 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
and chown?



Sincerely,

Maxim Maletsky
Founder, Chief Developer

www.PHPBeginner.com   // where PHP Begins




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[php4]

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 yet, but I can add a 
> function for that too.
>   
> I'll keep you posted,




Thanks, I've wished for this for a long time!


Rick

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] feature request

[Nikolai Devereaux]

> 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 will be working on it as
> soon as I have some time left :)

Again, my issue is NOT that I don't know how to write word_count or
line_count functions, but that PHP doesn't offer this as a built in
function, and in my opinion it should.  Someone using PHP as a language
shouldn't have to write their own wrapper functions using regular
expressions or download PHPLIB, PEAR, or any other additional libraries to
do something so simple.

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".

Nik



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] feature request

[Stig S. Bakken]

$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 simple wrappers
> around system calls or creating arrays to get the number of words or lines
> in a file.
> 
> For example, to get the number of lines in a file, I have to do this:
> 
> // bash specific solution
> function lines($filename)
> {
> $wc = `bash -c 'wc -l $filename 2>&1'`;
> return (preg_match("|^\s+(\d+)\s+$filename\s*$|", $wc, $matches)?
> $matches[1] : 0;
> }
> 
> or this:
> // generic solution  (w/o error checks):
> function lines($filename)
> {
> return count(file($filename));
> }
> 
> 
> Take care,
> 
> Nik
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] feature request

[Daniel Lorch]

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(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 will be working on it as
soon as I have some time left :)

-daniel



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Michael Virnstein]

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 be set.

My 2 cents ;)
That's how i would prefer it.

<[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 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 writing functions/Classes, if
> > i were able to determine the __FILE__ and __LINE__ of the
> > script, that is calling my function, without the need to send
> > __FILE__ and __LINE__ as parameter to my function.
> > E.g. __CFILE__ for calling script and __CLINE__ for line in the
> > calling script would be really great.
> > In addition it'll be useful, if I could use trigger_error in this
manner.
> > Most of the time i don't want to know, on which line my trigger_error
> > call is located, but on which line in the script that called my
function,
> > the
> > error occured. it'll be nice, if trigger_error could be extended, so it
> > takes
> > to more parameters, which overwrite the default __FILE__, __LINE__
> > settings of trigger error.
> >
> > Example:
> >
> > function somefunction($array) {
> > if (!is_array($array)) {
> > trigger_error("Not an array", E_USER_ERROR, __CFILE__,
__CLINE__);
> > }
> > // do something with the array
> > }
> >
> >
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> ---
>  Did I help you? Consider a gift:
>   http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
> ---
>   PHP: Scripting the Web - [EMAIL PROTECTED]
> All your branches are belong to me!
> SRM: Script Running Machine - www.vl-srm.net
> ---
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Michael Virnstein]

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 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 writing functions/Classes, if
> > i were able to determine the __FILE__ and __LINE__ of the
> > script, that is calling my function, without the need to send
> > __FILE__ and __LINE__ as parameter to my function.
> > E.g. __CFILE__ for calling script and __CLINE__ for line in the
> > calling script would be really great.
> > In addition it'll be useful, if I could use trigger_error in this
manner.
> > Most of the time i don't want to know, on which line my trigger_error
> > call is located, but on which line in the script that called my
function,
> > the
> > error occured. it'll be nice, if trigger_error could be extended, so it
> > takes
> > to more parameters, which overwrite the default __FILE__, __LINE__
> > settings of trigger error.
> >
> > Example:
> >
> > function somefunction($array) {
> > if (!is_array($array)) {
> > trigger_error("Not an array", E_USER_ERROR, __CFILE__,
__CLINE__);
> > }
> > // do something with the array
> > }
> >
> >
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> ---
>  Did I help you? Consider a gift:
>   http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
> ---
>   PHP: Scripting the Web - [EMAIL PROTECTED]
> All your branches are belong to me!
> SRM: Script Running Machine - www.vl-srm.net
> ---
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[derick]

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 writing functions/Classes, if
> i were able to determine the __FILE__ and __LINE__ of the
> script, that is calling my function, without the need to send
> __FILE__ and __LINE__ as parameter to my function.
> E.g. __CFILE__ for calling script and __CLINE__ for line in the
> calling script would be really great.
> In addition it'll be useful, if I could use trigger_error in this manner.
> Most of the time i don't want to know, on which line my trigger_error
> call is located, but on which line in the script that called my function,
> the
> error occured. it'll be nice, if trigger_error could be extended, so it
> takes
> to more parameters, which overwrite the default __FILE__, __LINE__
> settings of trigger error.
> 
> Example:
> 
> function somefunction($array) {
> if (!is_array($array)) {
> trigger_error("Not an array", E_USER_ERROR, __CFILE__, __CLINE__);
> }
> // do something with the array
> }
> 
> 
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

---
 Did I help you? Consider a gift:
  http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
---
  PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Andi Gutmans]

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 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 IMP lately...  And I've done a 
> lot of
> > PHP and Perl work in the past...  One of the things I really like about 
> PHP is
> > how it has most of the really cool features of Perl that I enjoy, but 
> lacks
> > some of the things that annoy me about Perl.
> >
> > I was making some modifications to IMP's configurations when I tried to 
> use a
> > feature of Perl that I thought for sure would have been carried over to 
> PHP.
> >
> > I'm not sure the exact vernacular to describe this feature, but Perl 
> allows
> > you to anonymously use whatever was returned by a function--e.g., $year =
> > (localtime($time))[5], so $year takes only the year value of the data 
> returned
> > by localtime() instead of the entire array.
> >
> > In IMP I was trying to do:
> >
> > $conf['spam']['email'] = 'postmaster@' . (posix_uname())['nodename'];
> >
> > But instead I have to do:
> >
> > $uname = posix_uname();
> > $conf['spam']['email'] = 'postmaster@' . $uname['nodename'];
> >
> >
> > I realize this is nitpicking a little bit, but being able to handle 
> returned
> > values in such a manner is quite, quite useful.  Or does PHP provide this
> > functionality through some other syntax?
> >
> > Anyways, I just thought I'd say somethin' about it.  Btw, please 
> reply-to-all,
> > as I'm not subscribed to this list.
> >
> > Okay, I'm done now,
> >
> > Derek
> >
> > [ derek p. moore ]---[ 
> http://hackunix.org/~derekm/pubkey.asc ]
> > [ [EMAIL PROTECTED] ][ bfd2 fad6 1014 
> 80c9 aaa8 ]
> > [ http://hackunix.org/~derekm/ ]---[ a4a0 f449 3461 
> a443 51b9 ]
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>--
>Please always Cc to me when replying to me on the lists.
>GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
>"Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Markus Fischer]

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 IMP lately...  And I've done a lot of 
> PHP and Perl work in the past...  One of the things I really like about PHP is 
> how it has most of the really cool features of Perl that I enjoy, but lacks 
> some of the things that annoy me about Perl.
> 
> I was making some modifications to IMP's configurations when I tried to use a 
> feature of Perl that I thought for sure would have been carried over to PHP.
> 
> I'm not sure the exact vernacular to describe this feature, but Perl allows 
> you to anonymously use whatever was returned by a function--e.g., $year = 
> (localtime($time))[5], so $year takes only the year value of the data returned 
> by localtime() instead of the entire array.
> 
> In IMP I was trying to do:
> 
> $conf['spam']['email'] = 'postmaster@' . (posix_uname())['nodename'];
> 
> But instead I have to do:
> 
> $uname = posix_uname();
> $conf['spam']['email'] = 'postmaster@' . $uname['nodename'];
> 
> 
> I realize this is nitpicking a little bit, but being able to handle returned 
> values in such a manner is quite, quite useful.  Or does PHP provide this 
> functionality through some other syntax?
> 
> Anyways, I just thought I'd say somethin' about it.  Btw, please reply-to-all, 
> as I'm not subscribed to this list.
> 
> Okay, I'm done now,
> 
> Derek
> 
> [ derek p. moore ]---[ http://hackunix.org/~derekm/pubkey.asc ]
> [ [EMAIL PROTECTED] ][ bfd2 fad6 1014 80c9 aaa8 ]
> [ http://hackunix.org/~derekm/ ]---[ a4a0 f449 3461 a443 51b9 ]
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
"Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[derick]

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 to
> Perl's pos(). I think this would be a very useful addition, plus it
> requires minimal code changes since the actual function, php_pcre_match()
> computes the values presently but just throws them away.
>
> I've modified my own build to do this, and I've attached a diff...but I'd
> regard this as proof-of-concept code since I did it in a hurry (so maybe
> it can make 4.2.0?) and I haven't coded in C since my university classes
> couple years back. It's actually kinda of embarassing, but heck I don't
> know any of you. =P.
>
> The only really difficulty would be deciding how to return the
> values...I've thought up a bunch of ways of implementing this
> other than the stupidly simple add another nested array I did, like use a
> resource, a new function, return a 2nd array, etc.
>
>
> --Ricky
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Jaroslaw Kolakowski]

> 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 PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[Teodor Cimpoesu]

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 there any plans to make them accessible from PHP? It definately 
> > would be nice.
> 
> It would be nice and it doesn't require much work. I am using PHP-4.0.6 with
> patch, that allows me to parse HTML documents into DOM objects and output
> DOM objects to HTML format. Besides I can use libxslt to process DOM objects
> via XSL stylesheets.  Now I am going to rewrite the new functions after last
> changes in the DOM XML extension - they will use these new pretty macros.
> 
Can you tell more on what that patch is about and it's availability?

-- teodor

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[Jaroslaw Kolakowski]

> 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 be nice.

It would be nice and it doesn't require much work. I am using PHP-4.0.6 with patch, 
that allows me to parse HTML documents into DOM objects and output DOM objects to HTML 
format. Besides I can use libxslt to process DOM objects via XSL stylesheets.
Now I am going to rewrite the new functions after last changes in the DOM XML 
extension - they will use these new pretty macros.

Regards,

Jaroslaw Kolakowski



--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[Andrei Zmievski]

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 accessible from PHP? It definately 
> would be nice.

Sure.

-Andrei
* Non-volatile, random-access, analog memory store... a book. *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[Alexander Wagner]

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 you here, Andrei.
Templates are simple but they aren't brain dead.

> *Plonk*.

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 be nice.

regards
Wagner

-- 
"Never attribute to malice what can as easily be the result of 
incompetence."

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[Andrei Zmievski]

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 thread
> of discussion on the brain-dead text-substituting templating
> engines. i think the text-substituting way of templating sucks
> because you basically invent a new way to mark up things,
> which is nonsense since html itself already is a markup language.
> now when you use your little text-substituting engine a bit in practice,
> you will eventually find that you need more than just text-substitutions
> and then you start inventing a whole new scripting language for rolling
> loops, etc, which is extra idiotic as php itself already is a scripting
> language, letting you do all that, and more. the only thing you have
> gained at the end is a relatively dumb monster which is slower,
> non-standard, lets you do less and does it all worse, no matter
> whether it is written in PHP, C or assembly. if i wanted to do
> any text substitutions, i would do that with  and
> if i wanted to roll out a table row, i would do that with
>  . , simple as that.
> 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 done?

*Plonk*.

-Andrei
* Ethernet n.: something used to catch the etherbunny. *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Phil Driscoll]

>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 implemented) that iswhatever(multiple
args) will work sensibly across the board, and that implementing
iswhatever(multiple args) does not waste the function namespace for a new
feature - e.g. loads of php functions take optional extra arguments to
modify their behaviour, but once iswhatever gained the multi argument
functionality described, it would be impossible to extend the functionality
in this way.

Cheers, and apologies for such a long sentence!
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Andi Gutmans]

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 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?
>
>For the record, I'm perfectly happy with things the way they are.  If
>I need to test the existence of two variables, I'm content doing so
>(verbosely) with two isset() calls.
>
>Admittedly, I don't see anything wrong or dangerous with extending
>isset() to test multiple variables, but I just hope this doesn't go
>too far into the syntactic sugar realm.
>
>--
>Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
>http://www.csh.rit.edu/~jon/  :  Computer Science House Member


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Jon Parise]

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?

For the record, I'm perfectly happy with things the way they are.  If
I need to test the existence of two variables, I'm content doing so
(verbosely) with two isset() calls.  

Admittedly, I don't see anything wrong or dangerous with extending
isset() to test multiple variables, but I just hope this doesn't go
too far into the syntactic sugar realm.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Jon Parise]

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])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Phil Driscoll]

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 here - I cannot think of a sensible
extra argument to modify isset. What I am saying is that if I were not in
the middle of building a ceiling for my bathroom, I'm sure I could find
either an existing issomething or ext_issomething function which already
uses an optional extra argument, or at least, could use one to good effect.
Torben has picked up on what I'm getting at - all 'is' functions should work
the same way - this (IMHO) is much more important than a bit of useful
ad-hoc functionality. If it turns out that we can do this trick to all 'is'
functions without any problems, then great - do it, but do it to all of
them.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Lars Torben Wilson]

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 semantics.
> 
> Zeev

If it can be changed like that and be safe and consistent then that's
great. If it makes people's lives better without confusion then that's
perfect. Just as long as it's been considered then I'm happy.

> At 23:21 19/3/2001, Lars Torben Wilson wrote:
> >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(), so we should go with 
> > it.  Keeping it
> > > > with one argument 'for future use' doesn't make much sense in my
> > > > opinion.  Not any more sense than saying the same thing about some new
> > > > argument someone might want to add to it in the future - why not keep it
> > > > clean and wait for a 'better' use?
> > > >
> > > > Zeev
> > >
> > > I agree, this is something thats had more thought put into it than it 
> > really needed.
> > > This functionality very much fits issets nature - something goes in and 
> > 0/1 comes
> > > out. There really is no reason to not implement the request.
> > >
> > > -Jason
> >
> >Well, Phil is right in that if isset() is changed then
> >iseverythingelse() also needs to be examined and if necessary and
> >possible changed to suit. Otherwise we'll be fielding questions about
> >'well it works this way for *this* function, why not this one?' for
> >years. The same question. Over and over and over. Because if the
> >language itself isn't consistent then no number of FAQs and manual
> >notes will prevent people from stubbing their toes.
> >
> >I think that too much thought has most definitely *not* been put into
> >this issue--the effect on the whole language needs to be considered,
> >not just isset(). Just IMHO, of course.
> >
> >
> >--
> >++
> >|Torben Wilson <[EMAIL PROTECTED]>Adcore Finland|
> >|http://www.coastnet.com/~torbenhttp://www.adcore.com|
> >|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
> >++
> 
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> 

-- 
++
|Torben Wilson <[EMAIL PROTECTED]>Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] feature request

[Zeev Suraski]

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.

Zeev

At 23:27 19/3/2001, Chris Newbill wrote:
>I agree Phil, that is the mature way to examine this.
>
>Except, I would be surprised if we _cannot_ apply the same reasoning to the
>other is_* functions, it's the exact same concept.  I'm just not familiar
>enough with the internal workings to conclude whether is_*($x, $y, $z) would
>be efficient or even used for that matter.
>
>Although 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; [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 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 take an optional
> > extra argument to change their behaviour, and I stopped when I
> > reached 100.
> >
> > Fair enough, isset is a language construct, but most of the other
> > isblahs/ext_isblahs are functions, however your average php
> > programmer won't
> > even know what this means, let alone be able to discriminate.
> >
> > My point is that if you are going to do it to isset, AND the
> > language is to
> > become more orthogonal then it MUST also be done to isanythingelse. I can
> > see that there are no nasty repercussions with using the technique for
> > isset, however there are many many isanythingelses and I'd be surprised if
> > we can apply the
> > reasoning across the board.
> >
> > I don't want to stifle innovation here, I just want us to think beyond the
> > immediate problem when the language gets extended.
> >
> > Cheers
> > --
> > Phil Driscoll
> > Dial Solutions
> > +44 (0)113 294 5112
> > http://www.dialsolutions.com
> > http://www.dtonline.org
> >
> >

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] feature request

[Chris Newbill]

I agree Phil, that is the mature way to examine this.

Except, I would be surprised if we _cannot_ apply the same reasoning to the
other is_* functions, it's the exact same concept.  I'm just not familiar
enough with the internal workings to conclude whether is_*($x, $y, $z) would
be efficient or even used for that matter.

Although 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; [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 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 take an optional
> extra argument to change their behaviour, and I stopped when I
> reached 100.
>
> Fair enough, isset is a language construct, but most of the other
> isblahs/ext_isblahs are functions, however your average php
> programmer won't
> even know what this means, let alone be able to discriminate.
>
> My point is that if you are going to do it to isset, AND the
> language is to
> become more orthogonal then it MUST also be done to isanythingelse. I can
> see that there are no nasty repercussions with using the technique for
> isset, however there are many many isanythingelses and I'd be surprised if
> we can apply the
> reasoning across the board.
>
> I don't want to stifle innovation here, I just want us to think beyond the
> immediate problem when the language gets extended.
>
> Cheers
> --
> Phil Driscoll
> Dial Solutions
> +44 (0)113 294 5112
> http://www.dialsolutions.com
> http://www.dtonline.org
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Zeev Suraski]

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 just done a quick count of the php functions which take an optional
>extra argument to change their behaviour, and I stopped when I reached 100.

Define 'change their behavior' though?  Almost all SQL functions take an 
optional argument which is the link id.  That is by design, and doesn't 
really mean anything here, and it's not really changing their behavior, but 
rather, giving more fine-grained arguments.  The number of functions that 
were added an extra argument after at a later stage (as opposed to their 
time of writing) is very small.  The number of functions that were added an 
extra argument that really changes their behavior is pretty much negligible 
IMHO.


>Fair enough, isset is a language construct, but most of the other
>isblahs/ext_isblahs are functions, however your average php programmer won't
>even know what this means, let alone be able to discriminate.

It doesn't really matter.  Let's say you suggested isset($var[, $reverse]) 
syntax, which will hint isset() whether to reverse its result or not.  Who 
says whether it's a good idea to 'waste' this 2nd argument on this 
purpose?  The way I see it, supporting more than one variable in isset() is 
very useful for users, and keeping it the way it was just to accommodate 
for possible extra arguments in the future that may or may not come doesn't 
make much sense and isn't justified.

>My point is that if you are going to do it to isset, AND the language is to
>become more orthogonal then it MUST also be done to isanythingelse. I can
>see that there are no nasty repercussions with using the technique for
>isset, however there are many many isanythingelses and I'd be surprised if
>we can apply the
>reasoning across the board.

What do you mean by making the language orthogonal?  You mean consistent?

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Zeev Suraski]

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, Lars Torben Wilson wrote:
>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(), so we should go with 
> it.  Keeping it
> > > with one argument 'for future use' doesn't make much sense in my
> > > opinion.  Not any more sense than saying the same thing about some new
> > > argument someone might want to add to it in the future - why not keep it
> > > clean and wait for a 'better' use?
> > >
> > > Zeev
> >
> > I agree, this is something thats had more thought put into it than it 
> really needed.
> > This functionality very much fits issets nature - something goes in and 
> 0/1 comes
> > out. There really is no reason to not implement the request.
> >
> > -Jason
>
>Well, Phil is right in that if isset() is changed then
>iseverythingelse() also needs to be examined and if necessary and
>possible changed to suit. Otherwise we'll be fielding questions about
>'well it works this way for *this* function, why not this one?' for
>years. The same question. Over and over and over. Because if the
>language itself isn't consistent then no number of FAQs and manual
>notes will prevent people from stubbing their toes.
>
>I think that too much thought has most definitely *not* been put into
>this issue--the effect on the whole language needs to be considered,
>not just isset(). Just IMHO, of course.
>
>
>--
>++
>|Torben Wilson <[EMAIL PROTECTED]>Adcore Finland|
>|http://www.coastnet.com/~torbenhttp://www.adcore.com|
>|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
>++

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Lars Torben Wilson]

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(), so we should go with it.  Keeping it 
> > with one argument 'for future use' doesn't make much sense in my 
> > opinion.  Not any more sense than saying the same thing about some new 
> > argument someone might want to add to it in the future - why not keep it 
> > clean and wait for a 'better' use?
> > 
> > Zeev
> 
> I agree, this is something thats had more thought put into it than it really needed.
> This functionality very much fits issets nature - something goes in and 0/1 comes
> out. There really is no reason to not implement the request.
> 
> -Jason

Well, Phil is right in that if isset() is changed then
iseverythingelse() also needs to be examined and if necessary and
possible changed to suit. Otherwise we'll be fielding questions about
'well it works this way for *this* function, why not this one?' for
years. The same question. Over and over and over. Because if the
language itself isn't consistent then no number of FAQs and manual
notes will prevent people from stubbing their toes.

I think that too much thought has most definitely *not* been put into
this issue--the effect on the whole language needs to be considered,
not just isset(). Just IMHO, of course.


-- 
++
|Torben Wilson <[EMAIL PROTECTED]>Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Jason Greene]

> 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.  Keeping it 
> with one argument 'for future use' doesn't make much sense in my 
> opinion.  Not any more sense than saying the same thing about some new 
> argument someone might want to add to it in the future - why not keep it 
> clean and wait for a 'better' use?
> 
> Zeev

I agree, this is something thats had more thought put into it than it really needed.
This functionality very much fits issets nature - something goes in and 0/1 comes
out. There really is no reason to not implement the request.

-Jason




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Phil Driscoll]

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 take an optional
extra argument to change their behaviour, and I stopped when I reached 100.

Fair enough, isset is a language construct, but most of the other
isblahs/ext_isblahs are functions, however your average php programmer won't
even know what this means, let alone be able to discriminate.

My point is that if you are going to do it to isset, AND the language is to
become more orthogonal then it MUST also be done to isanythingelse. I can
see that there are no nasty repercussions with using the technique for
isset, however there are many many isanythingelses and I'd be surprised if
we can apply the
reasoning across the board.

I don't want to stifle innovation here, I just want us to think beyond the
immediate problem when the language gets extended.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] feature request

[Chris Newbill]

No doubt, clean code is king! And we don't want more work for Andi! :)

Basically I see this functionality as filling a niche and nothing more.
It's not a wonder-drug, it just makes certain situations a little more
readable/maintainable IMHO.

-Chris

> -Original Message-
> 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 you want
> an array of
> results you're better of doing a few if() statements. It's faster and
> writes much nicer code.
>
> Andi
>
> At 02:08 PM 3/19/2001 -0600, Jason Greene wrote:
> >Perhaps isset should be branched to form a separate function to handle
> >multi args,
> >we could offer things in the new function such as an optional argument
> >that passes back an array of results.
> >
> >-Jason
> >
> >- Original Message -
> >From: "Phil Driscoll" <[EMAIL PROTECTED]>
> >To: "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 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
> > > addition really doesn't help.
> > >
> > > 
> > > >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 implemented) that
> iswhatever(multiple
> > > args) will work sensibly across the board, and that implementing
> > > iswhatever(multiple args) does not waste the function
> namespace for a new
> > > feature - e.g. loads of php functions take optional extra arguments to
> > > modify their behaviour, but once iswhatever gained the multi argument
> > > functionality described, it would be impossible to extend the
> functionality
> > > in this way.
> > >
> > > Cheers, and apologies for such a long sentence
> > > 
> > > --
> > > Phil Driscoll
> > > Dial Solutions
> > > +44 (0)113 294 5112
> > > http://www.dialsolutions.com
> > > http://www.dtonline.org
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > To contact the list administrators, e-mail:
> [EMAIL PROTECTED]
> > >
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Zeev Suraski]

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 many 
>option flags.

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.  Keeping it 
with one argument 'for future use' doesn't make much sense in my 
opinion.  Not any more sense than saying the same thing about some new 
argument someone might want to add to it in the future - why not keep it 
clean and wait for a 'better' use?

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Jason Greene]

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 many option flags.

Thinking about it though, I can't think of anything in the multi-arg version that 
would really
need to be enhanced.  So, like I said, Im not objecting.  : )

-Jason


- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: "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 see the negative aspect of having it accept multiple variables.  Is
> there one?  If there isn't, then there's no need to invent a problem...
>
> Zeev
>
> At 22:08 19/3/2001, Jason Greene wrote:
> >Perhaps isset should be branched to form a separate function to handle
> >multi args,
> >we could offer things in the new function such as an optional argument
> >that passes back an array of results.
> >
> >-Jason
> >
> >- Original Message -
> >From: "Phil Driscoll" <[EMAIL PROTECTED]>
> >To: "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 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
> > > addition really doesn't help.
> > >
> > > 
> > > >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 implemented) that iswhatever(multiple
> > > args) will work sensibly across the board, and that implementing
> > > iswhatever(multiple args) does not waste the function namespace for a new
> > > feature - e.g. loads of php functions take optional extra arguments to
> > > modify their behaviour, but once iswhatever gained the multi argument
> > > functionality described, it would be impossible to extend the functionality
> > > in this way.
> > >
> > > Cheers, and apologies for such a long sentence
> > > 
> > > --
> > > Phil Driscoll
> > > Dial Solutions
> > > +44 (0)113 294 5112
> > > http://www.dialsolutions.com
> > > http://www.dtonline.org
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> > >
>
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Zeev Suraski]

I don't see the negative aspect of having it accept multiple variables.  Is 
there one?  If there isn't, then there's no need to invent a problem...

Zeev

At 22:08 19/3/2001, Jason Greene wrote:
>Perhaps isset should be branched to form a separate function to handle 
>multi args,
>we could offer things in the new function such as an optional argument 
>that passes back an array of results.
>
>-Jason
>
>- Original Message -
>From: "Phil Driscoll" <[EMAIL PROTECTED]>
>To: "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 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
> > addition really doesn't help.
> >
> > 
> > >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 implemented) that iswhatever(multiple
> > args) will work sensibly across the board, and that implementing
> > iswhatever(multiple args) does not waste the function namespace for a new
> > feature - e.g. loads of php functions take optional extra arguments to
> > modify their behaviour, but once iswhatever gained the multi argument
> > functionality described, it would be impossible to extend the functionality
> > in this way.
> >
> > Cheers, and apologies for such a long sentence
> > 
> > --
> > Phil Driscoll
> > Dial Solutions
> > +44 (0)113 294 5112
> > http://www.dialsolutions.com
> > http://www.dtonline.org
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Jason Greene]

After thinking about it more, it seems that in every scenario I could think of where 
you wanted an
array of results, you should not be using independent vars in the first place. It 
would seem much more reasonable
to use an array of combined values, and then parse those accordingly.

I don't have any objection with the isset function taking multi args.

-Jason

--- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>; "Phil Driscoll" <[EMAIL PROTECTED]>; "Chris 
Newbill" <[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
> results you're better of doing a few if() statements. It's faster and
> writes much nicer code.
>
> Andi
>
> At 02:08 PM 3/19/2001 -0600, Jason Greene wrote:
> >Perhaps isset should be branched to form a separate function to handle
> >multi args,
> >we could offer things in the new function such as an optional argument
> >that passes back an array of results.
> >
> >-Jason
> >
> >- Original Message -
> >From: "Phil Driscoll" <[EMAIL PROTECTED]>
> >To: "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 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
> > > addition really doesn't help.
> > >
> > > 
> > > >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 implemented) that iswhatever(multiple
> > > args) will work sensibly across the board, and that implementing
> > > iswhatever(multiple args) does not waste the function namespace for a new
> > > feature - e.g. loads of php functions take optional extra arguments to
> > > modify their behaviour, but once iswhatever gained the multi argument
> > > functionality described, it would be impossible to extend the functionality
> > > in this way.
> > >
> > > Cheers, and apologies for such a long sentence
> > > 
> > > --
> > > Phil Driscoll
> > > Dial Solutions
> > > +44 (0)113 294 5112
> > > http://www.dialsolutions.com
> > > http://www.dtonline.org
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> > >
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Andi Gutmans]

Ugh, that's exactly what I didn't want to get into. If you want an array of 
results you're better of doing a few if() statements. It's faster and 
writes much nicer code.

Andi

At 02:08 PM 3/19/2001 -0600, Jason Greene wrote:
>Perhaps isset should be branched to form a separate function to handle 
>multi args,
>we could offer things in the new function such as an optional argument 
>that passes back an array of results.
>
>-Jason
>
>- Original Message -
>From: "Phil Driscoll" <[EMAIL PROTECTED]>
>To: "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 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
> > addition really doesn't help.
> >
> > 
> > >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 implemented) that iswhatever(multiple
> > args) will work sensibly across the board, and that implementing
> > iswhatever(multiple args) does not waste the function namespace for a new
> > feature - e.g. loads of php functions take optional extra arguments to
> > modify their behaviour, but once iswhatever gained the multi argument
> > functionality described, it would be impossible to extend the functionality
> > in this way.
> >
> > Cheers, and apologies for such a long sentence
> > 
> > --
> > Phil Driscoll
> > Dial Solutions
> > +44 (0)113 294 5112
> > http://www.dialsolutions.com
> > http://www.dtonline.org
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Jason Greene]

Perhaps isset should be branched to form a separate function to handle multi args,
we could offer things in the new function such as an optional argument that passes 
back an array of results.

-Jason

- Original Message - 
From: "Phil Driscoll" <[EMAIL PROTECTED]>
To: "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 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
> addition really doesn't help.
> 
> 
> >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 implemented) that iswhatever(multiple
> args) will work sensibly across the board, and that implementing
> iswhatever(multiple args) does not waste the function namespace for a new
> feature - e.g. loads of php functions take optional extra arguments to
> modify their behaviour, but once iswhatever gained the multi argument
> functionality described, it would be impossible to extend the functionality
> in this way.
> 
> Cheers, and apologies for such a long sentence
> 
> --
> Phil Driscoll
> Dial Solutions
> +44 (0)113 294 5112
> http://www.dialsolutions.com
> http://www.dtonline.org
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Andi Gutmans]

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 the language more orthogonal, and this kind of ad hoc
>addition really doesn't help.

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.e., if they are passed a string vs. an array they behave 
differently. Very confusing IMO and I wouldn't want to see this kind of 
polymorphic functionality in basic language constructs.
If people are against this patch I don't mind taking it out.
Anyway, I think it's fine the way it is now and useful for people who I 
have seen that do a zillion of isset()'s one after each other, but I might 
be wrong.

Andi


>
> >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 implemented) that iswhatever(multiple
>args) will work sensibly across the board, and that implementing
>iswhatever(multiple args) does not waste the function namespace for a new
>feature - e.g. loads of php functions take optional extra arguments to
>modify their behaviour, but once iswhatever gained the multi argument
>functionality described, it would be impossible to extend the functionality
>in this way.
>
>Cheers, and apologies for such a long sentence
>
>--
>Phil Driscoll
>Dial Solutions
>+44 (0)113 294 5112
>http://www.dialsolutions.com
>http://www.dtonline.org
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Phil Driscoll]

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
addition really doesn't help.


>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 implemented) that iswhatever(multiple
args) will work sensibly across the board, and that implementing
iswhatever(multiple args) does not waste the function namespace for a new
feature - e.g. loads of php functions take optional extra arguments to
modify their behaviour, but once iswhatever gained the multi argument
functionality described, it would be impossible to extend the functionality
in this way.

Cheers, and apologies for such a long sentence

--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] feature request

[Andi Gutmans]

isset($var1, $var2,...) is in the CVS now.
If everyone is happy with it and doesn't want it to make coffee I think it 
should stay in.
If not we have lots of time to revert the patch before 4.0.6 :)

Andi

At 08:25 AM 3/19/2001 -0700, Chris Newbill wrote:
>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.
>
>-Chris
>
> > -Original 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 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) {
> > > >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,
> > >
> > >It is a hack - what if $a AND $c were unset. You really need to return an
> > >arbitrary length bitfield, with one bit for each arg. Then the
> > sensible name
> > >for the function would be isunset!
> > >That said, I think the whole idea is bad. I appreciate the
> > reduced number of
> > >keypresses involved, but I don't think that this is a feature
> > you can apply
> > >orthogonally to the rest of the language without serious
> > repercussions, and
> > >therefore it would not posses the desirable attribute that you
> > would be able
> > >to guess that isset worked this way.
> > >
> > >Hence my vote:
> > >
> > >  (X) don't make sweeping changes to language functionality without fully
> > >considering the repercussions.
> > >
> > >Cheers
> > >--
> > >Phil Driscoll
> > >Dial Solutions
> > >+44 (0)113 294 5112
> > >http://www.dialsolutions.com
> > >http://www.dtonline.org
> > >
> > >
> > >--
> > >PHP Development Mailing List <http://www.php.net/>
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] feature request

[Andi Gutmans]

:)

Andi

At 08:25 AM 3/19/2001 -0700, Chris Newbill wrote:
>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.
>
>-Chris
>
> > -Original 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 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) {
> > > >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,
> > >
> > >It is a hack - what if $a AND $c were unset. You really need to return an
> > >arbitrary length bitfield, with one bit for each arg. Then the
> > sensible name
> > >for the function would be isunset!
> > >That said, I think the whole idea is bad. I appreciate the
> > reduced number of
> > >keypresses involved, but I don't think that this is a feature
> > you can apply
> > >orthogonally to the rest of the language without serious
> > repercussions, and
> > >therefore it would not posses the desirable attribute that you
> > would be able
> > >to guess that isset worked this way.
> > >
> > >Hence my vote:
> > >
> > >  (X) don't make sweeping changes to language functionality without fully
> > >considering the repercussions.
> > >
> > >Cheers
> > >--
> > >Phil Driscoll
> > >Dial Solutions
> > >+44 (0)113 294 5112
> > >http://www.dialsolutions.com
> > >http://www.dtonline.org
> > >
> > >
> > >--
> > >PHP Development Mailing List <http://www.php.net/>
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] feature request

[Chris Newbill]

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.

-Chris

> -Original 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 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) {
> > >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,
> >
> >It is a hack - what if $a AND $c were unset. You really need to return an
> >arbitrary length bitfield, with one bit for each arg. Then the
> sensible name
> >for the function would be isunset!
> >That said, I think the whole idea is bad. I appreciate the
> reduced number of
> >keypresses involved, but I don't think that this is a feature
> you can apply
> >orthogonally to the rest of the language without serious
> repercussions, and
> >therefore it would not posses the desirable attribute that you
> would be able
> >to guess that isset worked this way.
> >
> >Hence my vote:
> >
> >  (X) don't make sweeping changes to language functionality without fully
> >considering the repercussions.
> >
> >Cheers
> >--
> >Phil Driscoll
> >Dial Solutions
> >+44 (0)113 294 5112
> >http://www.dialsolutions.com
> >http://www.dtonline.org
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Zeev Suraski]

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) {
> >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,
>
>It is a hack - what if $a AND $c were unset. You really need to return an
>arbitrary length bitfield, with one bit for each arg. Then the sensible name
>for the function would be isunset!
>That said, I think the whole idea is bad. I appreciate the reduced number of
>keypresses involved, but I don't think that this is a feature you can apply
>orthogonally to the rest of the language without serious repercussions, and
>therefore it would not posses the desirable attribute that you would be able
>to guess that isset worked this way.
>
>Hence my vote:
>
>  (X) don't make sweeping changes to language functionality without fully
>considering the repercussions.
>
>Cheers
>--
>Phil Driscoll
>Dial Solutions
>+44 (0)113 294 5112
>http://www.dialsolutions.com
>http://www.dtonline.org
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] feature request

[Zeev Suraski]

I don't think that in that context, that semantics makes much 
sense.  isset() for multiple variables as a 'all or nothing' checking 
method makes sense.  But if you want to know which variable failed, use 
multiple isset()'s.

As for negative numbers, they are and are to stay boolean true values.

Zeev

At 10:07 19/3/2001, Chris Newbill wrote:
>Oh come on Andi, are you telling me you can't do everything at once?
>
>Yes, I don't care about which one is the non-set variable.  I'd be glad to
>help on making this function work like that, but I'm afraid my C is rusty
>enough to require Tetanus shots for everyone involved. :) (Okay so it isn't
>really that bad.)
>
>Well, I remember reading that someone suggested making it so that any
>negative number was false.  So if that was the case and I did the following:
>
>$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, 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 touch my beloved functionality vile creatures!
>
>-Chris
>
> > From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> > Subject: RE: [PHP-DEV] feature request
> >
> >
> > It should be possible to do this. I'll look into it. But I also need to
> > think about how much sense it makes :)
> > Today you're asking for isset(...,...,...). Tomorrow you will ask to know
> > which one was not set if it failed.
> > So I hope what youreally want is only the first.
> >
> > Andi
> >
> > At 09:42 PM 3/18/2001 -0500, Mike Robinson wrote:
> > >Chris Newbill writes:
> > >
> > > > This would not be a bad idea IMHO and I would use it for some things.
> > > >
> > > > The functionality would be inclusive not exclusive.  So
> > > > isset($var1, $var2,
> > > > $var3) would only return true if $var1, $var2, and $var3 are
> > set and false
> > > > otherwise.
> > > >
> > > > So If I had a form passing $name, $email, $phone:
> > > >
> > > > example #1
> > > > if (isSet($name, $email, $phone))
> > > >// ALL GOOD
> > > >
> > > > Instead of
> > > >
> > > > example #2
> > > > if ((isSet($name)) &&
> > > > (isSet($email)) &&
> > > > (isSet($phone)))
> > > > // ALL GOOD
> > > >
> > > > Granted if one variable wasn't set, then you might run into some minor
> > > > issues if you want to figure out which one is not set.  But
> > that is the
> > > > developers choice. :)
> > > >
> > > > It wouldn't break existing functionality, seems simple enough
> > to implement
> > > > (although my karma is limited to doc's so someone else would have
> > > > to do it),
> > > > and would make some people happy.  That seems to be reason enough
> > > > to do it.
> > > >
> > > > Just my 2 cents.
> > >
> > >Ditto.
> > >It would be handy. If you are willing and able to do
> > >stuff like this, maybe a request for additional karma
> > >would be in order.
> > >
> > >Mike Robinson
> > >
> > >
> > >
> > >
> > >
> > >--
> > >PHP Development Mailing List <http://www.php.net/>
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Phil Driscoll]

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

It is a hack - what if $a AND $c were unset. You really need to return an
arbitrary length bitfield, with one bit for each arg. Then the sensible name
for the function would be isunset!
That said, I think the whole idea is bad. I appreciate the reduced number of
keypresses involved, but I don't think that this is a feature you can apply
orthogonally to the rest of the language without serious repercussions, and
therefore it would not posses the desirable attribute that you would be able
to guess that isset worked this way.

Hence my vote:

 (X) don't make sweeping changes to language functionality without fully
considering the repercussions.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] feature request

[Chris Newbill]

Oh come on Andi, are you telling me you can't do everything at once?

Yes, I don't care about which one is the non-set variable.  I'd be glad to
help on making this function work like that, but I'm afraid my C is rusty
enough to require Tetanus shots for everyone involved. :) (Okay so it isn't
really that bad.)

Well, I remember reading that someone suggested making it so that any
negative number was false.  So if that was the case and I did the following:

$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, 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 touch my beloved functionality vile creatures!

-Chris

> From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> Subject: RE: [PHP-DEV] feature request
>
>
> It should be possible to do this. I'll look into it. But I also need to
> think about how much sense it makes :)
> Today you're asking for isset(...,...,...). Tomorrow you will ask to know
> which one was not set if it failed.
> So I hope what youreally want is only the first.
>
> Andi
>
> At 09:42 PM 3/18/2001 -0500, Mike Robinson wrote:
> >Chris Newbill writes:
> >
> > > This would not be a bad idea IMHO and I would use it for some things.
> > >
> > > The functionality would be inclusive not exclusive.  So
> > > isset($var1, $var2,
> > > $var3) would only return true if $var1, $var2, and $var3 are
> set and false
> > > otherwise.
> > >
> > > So If I had a form passing $name, $email, $phone:
> > >
> > > example #1
> > > if (isSet($name, $email, $phone))
> > >// ALL GOOD
> > >
> > > Instead of
> > >
> > > example #2
> > > if ((isSet($name)) &&
> > > (isSet($email)) &&
> > > (isSet($phone)))
> > > // ALL GOOD
> > >
> > > Granted if one variable wasn't set, then you might run into some minor
> > > issues if you want to figure out which one is not set.  But
> that is the
> > > developers choice. :)
> > >
> > > It wouldn't break existing functionality, seems simple enough
> to implement
> > > (although my karma is limited to doc's so someone else would have
> > > to do it),
> > > and would make some people happy.  That seems to be reason enough
> > > to do it.
> > >
> > > Just my 2 cents.
> >
> >Ditto.
> >It would be handy. If you are willing and able to do
> >stuff like this, maybe a request for additional karma
> >would be in order.
> >
> >Mike Robinson
> >
> >
> >
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]