On Fri, Aug 12, 2005 at 08:45:07AM +0000, Mikhael Goikhman wrote:
> On 11 Aug 2005 09:21:41 +0200, Rafal Bisingier wrote:
> > 
> > On Thu, Aug 11, 2005 at 05:09:26PM +1000, Cameron Simpson wrote:
> > > On 09Aug2005 11:16, Mikhael Goikhman <[EMAIL PROTECTED]> wrote:
> > > | On 09 Aug 2005 08:47:10 +0200, Rafal Bisingier wrote:
> > > | > I personaly don't like perl's string operators (eq, ne, etc.)
> > > | 
> > > | Is it because of "perl" or because of "eq", "ne" names? These names are
> > > | also tcl's expr operators, and you may find them in the test(1) man 
> > > page.
> > > 
> > > Where they are conveniently swapped in application. The "-lt" etc are
> > > numeric operators in test(1), because = and != are already taken for
> > > lexical comparison.
> > 
> > That's another reason to not use this silly notation... ;-)
> 
> I am not sure whether this discussion is technical still. If you perform
> a Google search for '"programming language" eq ne le lt ge gt' you will
> find a dozen or two of languages.

I know about it. I had to learn in the past about 10 different
programming languages, but I still think this kind of operators makes
only a mess. ;-)

> People use these names and know what they mean.

My point is not the problem with the meaning (at least not the biggest
one), but difficulty in telling apart operators from compared values
(eg. a comparision like this "equal ne notequal" instead of this
"equal != notequal"). This is only my point of view, but I will defend
it as long as I can... ;-)

> If we are to have two sets of comparison operators (that your
> patch seems to do), then using different names would be silly. :)

I don't need 2 sets of operators. I make it this way because it was
simple to do, nothing more. I needed only the integer part.
But I can disagree than with 2 sets of operators it'd be extremely silly
to use different names (inventing a wheel for the second time was not my
point). ;-)

> In any way, I am against to start to add the elements of a scripting
> language (inlcuding string and integer concepts) before 2.6 is out.
> There are already several ways to achieve what this Compare patch does.
> Additionally, I didn't hear users requesting this functionality. It seems
> you don't need it yourself, you wrote:
> 
> > I need a tool to check if some settings was set before and act
> > acordingly (eg. I need to check if a variable was set before, to not
> > overwrite it, or check the value of a variable and load apropriate
> > config file).
> 
> I.e. you need something like these Test conditions:
> 
>   (IsEnvSet var_name)
> 
> that is false if the value is unset or "", or/and (case insensitive):
> 
>   (MatchEnv var_name pattern)
> 
> I am not against adding one or another such condition.

Well, I tried to make it as flexible as I can, but maybe that was not
the best idea ;-) Your solution is equaly good for me and if it makes
into fvwm, then it would be even better. ;-)

-- 
Rafal Bisingier

Attachment: pgpHi2eSyKxR2.pgp
Description: PGP signature

Reply via email to