From: hwrvo@kato.lahabra.chevron.com (W.R. Volz)
Newsgroups: comp.std.c++
Subject: Re: New operators wish list
Date: 21 Jul 92 16:18:10 GMT
Organization: Chevron Oil Field Research Company

In article <658@manutius.UUCP>, garyp@manutius.UUCP (Gary Powell) writes:
|> Ok, Ok Ok...lets cut the relgion and get to the meat of the matter.
|> 
|> It appears to me that there are a large number of folks who want the following
|> new operators added to the language.
|> 
|> 1) ||=
|> 
|>    where:  x ||= y   <==>  x = x || y
|> 
|>    Seems resonable as it matches all the "Blah"= operators.
|> 
|> 2) &&=
|> 
|>    where:  x &&= y   <==>  x = x && y
|> 
|>    Also seems reasonable for the same issue as #1.
|> 
|> 
|> 3) ===
|> 
|>    where x === y   <==> x = x == y
|> 
|>    I have more trouble looking at this one, but again it still fits the
|>    "blah"= operator rule.  So it maybe that I just haven't thought about
|>    it long enough. Anyway I recommend it.
|>   
|> 4) some set of chars yet to be determined which bind tighter than the * and /
|>    for which x power y  is x raised to the power of y.
|> 
|>    This seems reasonable but again has the problem of what do we do with
|>    the odd ball arguments of y and x?
|> 
|>    I recommend we define it as an operator but leave its implementation alone
|>    and let everyone overload it as they see fit. And I don't care which
|>    set or single character is chosen. My reasoning is that the current
|>    arguments don't seem to be converging.  Maybe someone else (I'm sure I'll
|>    see heat on this one.) would care to summarize the arguments on this.
|> 
|> 5) "."
|>    Lets add this.  I mean really, no one's code will break if we have it,
|>    the earth will not shake and the sky fall down.  If it turns out to be
|>    not as useful as Jim claims..so what?  We'll drop it from language "D"
|>    the next generation.
|> 
|> Any others I've missed???
|> 
|> Lets get on with it.  Like it or not many of us have to work with C++ even
|> though language "X" is better at some other task.  Lets add the features folks
|> clamor for.  IF they can make a convincing statement of "It won't break any
|> existing code. And it is possible for someone of resonable experience 
|> programming to use it without shooting themselves in the foot."
|> 
|> We still have a lot of other pressing problems, like how to incorporate 
|> persistance, and how to do good garbage collection, and how to at run time
|> create objects whose type isn't known until after the program is running.
|> 
|> 
|> BTW.
|>   Could you folks who want to argue language issues move your discussion over
|> to this group?  Then we can quit annoying the folks who want to compare
|> Borland to Mircosoft or ask the beginners questions. And I don't have
|> to read 100 or more messages to find the language issue ones.
|> 

Whoa. All of these are simply programmer convienences (sp?). I would rather
code a few more characters and be able to clearly read the code than save a few
bytes of disk space. If that many new operators are going to be added, 
why not just make it a rule for all binary operators? 

.i.e, x (op)= y;  <==>   x = x (op) y;

-- 

======================
Bill Volz
Chevron Oil Field Research Co.
Exploration Research/Geophysics Division.
P.O. Box 446, La Habra, CA 90633-0446
Phone: (310) 694-9340