On Tue, 14 Oct 2003, Rasmus Lerdorf wrote:
> You are pushing towards
>
> $_~=/^\.*?\$$/;
Oh, but Rasmus, you don't even need $_ here.. Simply /^\.*?\$$/; will
do. My Perl kungfu increases every day.
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
"Curt Zirzow" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> * Thus wrote David Sklar ([EMAIL PROTECTED]):
> > I was thinking about adding one or two regex-related features to the
engine:
> >
> > 1. "preg_case": this would behave just like case but instead of doing an
> > equality c
On Tue, Oct 14, 2003 at 11:44:07AM -0700, Rasmus Lerdorf wrote:
> We have enough operators folks. Regular expressions, especially since we
> have two different varieties of them, are confusing enough as they are.
> let's not add to the confusion by obfuscating the syntax around them.
Some of t
I suggest we wrap up this topic. As Rasmus said, I don't think there's a
chance we'd agree to implement such regex operators (wether the singular or
plural versions :)
Except for it pushing PHP in Perl's direction of being unreadable it
doesn't really give any added value. I don't see how it is
At 20:58 14/10/2003, George Schlossnagle wrote:
On Tuesday, October 14, 2003, at 02:44 PM, Rasmus Lerdorf wrote:
For example, what would =~ do when you build PHP without PCRE support?
Would it simply not work? Would it fall back to Posix-style regex?
Why
should PCRE-regex get an operator and Pos
netcat wrote:
i've started to play with a more general way to handle this:
switch(mixed data [, callback compare_function])
seems the sanest thing up until now.
slighly O.T.: would be and even better if lambda functions were
available here
http://php.net/create-function
--
Hartmut Holzgr
Warning: reply is O.T.
Adam Maccabee Trachtenberg wrote:
On 14 Oct 2003, Robert Cummings wrote:
Why would this make regular expressions more widespread? I would expect
that regular expressions are used wherever necessary and otherwise not
used, regardless of syntax. Or are you saying because
Hi,
correct me if I am wrong but yesterday I read in a book related to
Software Engineering
(something called like "Classical and Object Oriented Software
Engineering with examples in C++")
that there was decision that programming languages will be spelled
lowecase with the first character
in up
On Tuesday, October 14, 2003, at 02:44 PM, Rasmus Lerdorf wrote:
For example, what would =~ do when you build PHP without PCRE support?
Would it simply not work? Would it fall back to Posix-style regex?
Why
should PCRE-regex get an operator and Posix-style shouldn't? So we
need
two different
On Tue, 2003-10-14 at 14:48, George Schlossnagle wrote:
> On Tuesday, October 14, 2003, at 02:38 PM, Red Wingate wrote:
>
> > Why not just allow this as an optional feature, i don't see any
> > reasons to
> > keep this out as it doesn't affect any performace and can maybe help
> > some
> > old-
On Tuesday, October 14, 2003, at 02:38 PM, Red Wingate wrote:
Why not just allow this as an optional feature, i don't see any
reasons to
keep this out as it doesn't affect any performace and can maybe help
some
old-skewl PERL-Coders to convert over to PHP.
For god's sake people: it's 'Perl', n
Making it an "optional" feature wins the prize for today's worst idea.
So code written with this option turned on will not run on a server with
it turned off?
And telling people that they simply shouldn't use it if they don't like it
doesn't help anybody. If it is there, some people will use i
Why not just allow this as an optional feature, i don't see any reasons to
keep this out as it doesn't affect any performace and can maybe help some
old-skewl PERL-Coders to convert over to PHP.
One of the best features of PERL is the tight connection between regular
expressions and the scripting-
On 14 Oct 2003, Robert Cummings wrote:
> Why would this make regular expressions more widespread? I would expect
> that regular expressions are used wherever necessary and otherwise not
> used, regardless of syntax. Or are you saying because regex matching is
> invoked via a function that you don'
>> My motivation for this operator is to encourage regular expression
>> use as part of the core toolbox of PHP programmers. I think,
>> especially in a web context, where so much work has to do with data
>> validation and manipulation, that this is a reasonable goal. The
>> features that the preg_
Hartmut Holzgraefe wrote:
David Sklar wrote:
I was thinking about adding one or two regex-related features to the
engine:
1. "preg_case": this would behave just like case but instead of doing an
equality comparison, would match against a regular expression, e.g.
switch($data) {
preg_case '/^
On Tue, 14 Oct 2003, David Sklar wrote:
> On Tuesday, October 14, 2003 1:10 PM, mailto:[EMAIL PROTECTED] wrote:
>
> > You are pushing towards
> >
> > $_~=/^\.*?\$$/;
> >
> > This is not human-readable code and one of the basic characteristics
> > that sets PHP apart from Perl.
>
> Actually, I'm
On October 14, 2003 02:14 pm, David Sklar wrote:
> if (! ($_REQUEST['email'] =~ '/[EMAIL PROTECTED]@([-a-z0-9]+\.)+[a-z]{2,}$/i')) {
>$form->addError('Please enter a valid e-mail address.');
> }
Why not use PERL if you are looking for this sort of functionality? As
indicated by other develope
On Tue, 2003-10-14 at 14:14, David Sklar wrote:
> On Tuesday, October 14, 2003 1:10 PM, mailto:[EMAIL PROTECTED] wrote:
>
> > You are pushing towards
> >
> > $_~=/^\.*?\$$/;
> >
> > This is not human-readable code and one of the basic characteristics
> > that sets PHP apart from Perl.
>
> Actua
On Tuesday, October 14, 2003 1:10 PM, mailto:[EMAIL PROTECTED] wrote:
> You are pushing towards
>
> $_~=/^\.*?\$$/;
>
> This is not human-readable code and one of the basic characteristics
> that sets PHP apart from Perl.
Actually, I'm pushing towards
if (! ($_REQUEST['email'] =~ '/[EMAIL PROT
On Tue, 14 Oct 2003, David Sklar wrote:
> On Tuesday, October 14, 2003 11:18 AM, mailto:[EMAIL PROTECTED] wrote:
>
> > Right, and as George's example already works I see no point in adding
> > more 'magic' operators that look like Perl to me.
>
> What about a match operator? I realize that simil
On Tue, 2003-10-14 at 13:02, David Sklar wrote:
> On Tuesday, October 14, 2003 11:18 AM, mailto:[EMAIL PROTECTED] wrote:
>
> > Right, and as George's example already works I see no point in adding
> > more 'magic' operators that look like Perl to me.
>
> What about a match operator? I realize tha
On Tuesday, October 14, 2003 11:18 AM, mailto:[EMAIL PROTECTED] wrote:
> Right, and as George's example already works I see no point in adding
> more 'magic' operators that look like Perl to me.
What about a match operator? I realize that similar functionality can be
achieved with preg_match(), b
On Tue, 14 Oct 2003, Curt Zirzow wrote:
> This should also be BC if you just pass one string.
http://docs.php.net/en/function.preg-grep.html
we already have that too.
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read the future by ex
* Thus wrote David Sklar ([EMAIL PROTECTED]):
> I was thinking about adding one or two regex-related features to the engine:
>
> 1. "preg_case": this would behave just like case but instead of doing an
> equality comparison, would match against a regular expression, e.g.
>
> switch($data) {
>
David Sklar wrote:
One thing that I suppose you get by using "case preg_match()" like George
does below (as opposed to my preg_case operator or Hartmut's callback) is
you can deal with arbitrary arguments to the preg_match() (or other)
function -- storing captured subpatterns from the regex, for ex
On Tue, 14 Oct 2003, David Sklar wrote:
> One thing that I suppose you get by using "case preg_match()" like George
> does below (as opposed to my preg_case operator or Hartmut's callback) is
> you can deal with arbitrary arguments to the preg_match() (or other)
> function -- storing captured subp
One thing that I suppose you get by using "case preg_match()" like George
does below (as opposed to my preg_case operator or Hartmut's callback) is
you can deal with arbitrary arguments to the preg_match() (or other)
function -- storing captured subpatterns from the regex, for example.
David
On
Aesthetics aside, how is that different in effect from:
switch(true) {
case preg_match('/foo.*?bar/i', $data):
/** stuff **/
break;
case preg_match('/baz/', $data);
/** other stuff **/
break;
default:
break;
}
?
On Tuesday, October 14, 2003, at 10:58 AM, Andrey H
David Sklar wrote:
I was thinking about adding one or two regex-related features to the engine:
1. "preg_case": this would behave just like case but instead of doing an
equality comparison, would match against a regular expression, e.g.
switch($data) {
preg_case '/^\d{5}(-\d{4})?$/':
pri
Hi David,
2 weeks ago Hartmut Holzgraefe had similar idea :
switch ($data, "preg_match") {
case '/foo.*?bar/i' : /* computation here */
break;
}
The second argument is a callback.
Andrey
David Sklar wrote:
I was thinking about adding one or two regex-related features to the engine:
1.
I was thinking about adding one or two regex-related features to the engine:
1. "preg_case": this would behave just like case but instead of doing an
equality comparison, would match against a regular expression, e.g.
switch($data) {
preg_case '/^\d{5}(-\d{4})?$/':
print "US Postal Code
32 matches
Mail list logo
