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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 KalowskyI'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 http://www.php.net/
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

?php
include('stopwatch.inc');
$SW = new StopWatch;
for ($i=0;$i50;$i++)
str_replace('abcdefgh', 'def', 
'fkjdals;fjdsakl;fjdsakl;fjdskl;fadabcdefghfdsafdsafdsa');
$SW-Stop();

for ($i=0;$i50;$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 http://www.php.net/
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

 ?php
 include('stopwatch.inc');
 $SW = new StopWatch;
 for ($i=0;$i50;$i++)
 str_replace('abcdefgh', 'def',
 'fkjdals;fjdsakl;fjdsakl;fjdskl;fadabcdefghfdsafdsafdsa');
 $SW-Stop();

 for ($i=0;$i50;$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 http://www.php.net/
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
?php
$input[] = array('hfdhffndfafjdfjasfjas;fjdas;fjdsafjas;fjas', 'das', '1234');
$input[] = array('Used the form above or our advanced search page to make sure 
nobody has reported the bug already.', 'or', 'OR');
$input[] = array('Once you\'ve double-checked that the bug you\'ve found 
hasn\'t already been reported, and that you have collected all the information you 
need to file an excellent bug report, you can do so on our bug reporting page.', 
'XYS', '1234');
$input[] = array('dfkfjgjdsgjdgfd', 'dfkfjgjdsgjdgfd', '13243');
$input[] = array('xif pleh ot tnaw lliw enoemos taht gub a troper ot woh no 
spit ruo daeR', 'Read our tips on how to report a bug that someone will want to help 
fix', '13243');

function getmicrotime()
{
list($usec, $sec) = explode( ,microtime());
return ((float)$usec + (float)$sec);
}   

$start = getmicrotime();

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

$end = getmicrotime();

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

foreach($input as $key = $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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

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 http://www.php.net/
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:

 ?php

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

 ?php

 $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 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: 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:
 
  ?php
 
  $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 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: 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:
  
   ?php
  
   $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

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 http://www.php.net/
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 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 http://www.php.net/
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.

[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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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: [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 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

[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 http://www.php.net/
 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 http://www.php.net/
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 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

-- 
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 http://www.php.net/
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 http://www.php.net/
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 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: [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 http://www.php.net/
 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 http://www.php.net/
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 http://www.php.net/
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 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 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,
 
 Loud cheer!!!
 
 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 http://www.php.net/
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 http://www.php.net/
 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 http://www.php.net/
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 http://www.php.net/
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 http://www.php.net/
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 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 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 http://www.php.net/
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 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 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 http://www.php.net/
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 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 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 http://www.php.net/
 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 http://www.php.net/
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 http://www.php.net/
  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 http://www.php.net/
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 http://www.php.net/
  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 http://www.php.net/
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 http://www.php.net/
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 21'`;
 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 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

[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_inifile and
pathinfo, and other built in unix commands like touch, chown, and
chmod.

Nik



-- 
PHP Development Mailing List http://www.php.net/
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,

Loud cheer!!!


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


Rick

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

-- 
PHP Development Mailing List http://www.php.net/
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_inifile 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 http://www.php.net/
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 http://www.php.net/
   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 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

[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 http://www.php.net/
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 http://www.php.net/
  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 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: 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 http://www.php.net/
 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 http://www.php.net/
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 diffbut I'd
 regard this as proof-of-concept code since I did it in a hurry (so maybe
 it can make 420?) 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
 valuesI'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 http://wwwphpnet/
To unsubscribe, visit: http://wwwphpnet/unsubphp

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 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: 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 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: 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 ?= $var ? and
 if i wanted to roll out a table row, i would do that with
 ? while(...) { ?tr . /tr? }?, 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 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: 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 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: 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 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: 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 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]

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]

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

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

[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

[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

[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

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

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]

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

[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

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

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

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

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

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

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.

-Chris

 From: Gavin Sherry [mailto:[EMAIL PROTECTED]]

 Cameron,

 On Mon, 19 Mar 2001, Cameron wrote:

  would be nice if isset would act the same as unset, being able to feed
  it more than 1 var at a time
 
  ie. if ( isset ( $blah1, $blah2 ) ) { blah blah }

 This is probably a bad idea since isset() needs to return true or false
 for each argument it receives. (Any other mode of operation is too
 complicated).

 This means that you need to return the values for each variable as an
 array and that each value from the array needs to be tested. This results
 in more typing than you would previously have been doing and is more
 computationally intensive.

 I suggest just stick with the current implementation.

 Gavin


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

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]

Re: [PHP-DEV] feature request

[Cameron]

personally all i want is isset(blah,blah,blah)

im dealing with 18 items from a form here and im getting sick of typing them all
;)

im not too worried about which one isnt set because i just display a not all
fields filled in and use a javascript back button. simple?

thats all i want but if you start adding this to one of these types of functions
you will probably want to add it to empty() and so on ?


Cameron

Andi Gutmans wrote:

 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]


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

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]