done
On Wed, 15 Oct 2003, Moriyoshi Koizumi wrote:
> It's just been confirmed he's qualified enough. Could anyone grant him a
> doc karma?
>
> Moriyoshi
>
>
> "Tadashi Jokagi" <[EMAIL PROTECTED]> wrote:
>
> > I want to help the English to Japanese translation of the manual of PHP.
> >
> > --
> >
It's just been confirmed he's qualified enough. Could anyone grant him a
doc karma?
Moriyoshi
"Tadashi Jokagi" <[EMAIL PROTECTED]> wrote:
> I want to help the English to Japanese translation of the manual of PHP.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe,
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
FYI, this should be fixed now. If anyone still bumps into weird performance
problems relating to the memory manager please let me know.
Andi
Date: Tue, 30 Sep 2003 21:21:38 +0800
From: Alan Knowles <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030911
To
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
Please don't reply to spam on the list :-)
My filters do a good job at getting rid of it, but you've just
sneaked the damned thing around the filter :-/
--Wez.
- Original Message -
From: "Dirkjan Ochtman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 14, 2003 11:12 A
Heh, let's visit them... Oh wait, that street doesn't exist!
No wonder they have "BS" in their zipcode.
Regards,
Manuzhai
"Francis Weeny" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
SUNSWEETWIN PROMO LOTTERY,THE NETHERLANDS.
ALFONSTRAAT B56,
1002 BS AMSTERDAM, THE NETHERLANDS.
T
31 matches
Mail list logo
