"Pavel Minayev" <evilone@omen.ru> ha scritto nel messaggio news:a4c0oi$1efk$1@digitaldaemon.com...
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C697B1B.1B10E356@deming-os.org...
>
> > You could simply define that for built-in types :+: is exactly
equivalent
> to
> > +    Or am I missing the point here?
>
> What about the ":+-*/:" operator, then? =)

I think you're missing the point. They are talking about needing a lexical
sign when
using an overloaded operator. So, in this view, every operator can be
overloaded,
but you must write something like :operator: (or something else) to state
lexically
that you are using an overloaded operator.
No new operators can be "created" on the fly in this schema.

Ciao

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:a4do8b$279j$1@digitaldaemon.com...

> I think you're missing the point. They are talking about needing a lexical
> sign when
> using an overloaded operator. So, in this view, every operator can be
> overloaded,
> but you must write something like :operator: (or something else) to state
> lexically
> that you are using an overloaded operator.
> No new operators can be "created" on the fly in this schema.

Then I don't see much reason in adding something to state an overloaded
operator explicitly. In most cases, I don't really care. I use + to
add vectors just as I would add ints, and I'm pretty happy with that.
If it is built-in, fine. If it is provided by some module, I should
be able to use it as if it was built-in.

Just my POV...

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a4dutu$2avp$1@digitaldaemon.com...
> "Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:a4do8b$279j$1@digitaldaemon.com...
>
> > I think you're missing the point. They are talking about needing a
lexical
> > sign when
> > using an overloaded operator. So, in this view, every operator can be
> > overloaded,
> > but you must write something like :operator: (or something else) to
state
> > lexically
> > that you are using an overloaded operator.
> > No new operators can be "created" on the fly in this schema.
>
> Then I don't see much reason in adding something to state an overloaded
> operator explicitly. In most cases, I don't really care. I use + to
> add vectors just as I would add ints, and I'm pretty happy with that.
> If it is built-in, fine. If it is provided by some module, I should
> be able to use it as if it was built-in.
>
> Just my POV...
>

Totally agreed.
If the lexical sign was standard, like it was *always* :op:, I could
live with it. I wouldn't like it however, it just looks confusing.

"OddesE" <OddesE_XYZ@hotmail.com> schrieb im Newsbeitrag news:a3uudo$2amb$1@digitaldaemon.com...
> "D" <s_nudds@hotmail.com> wrote in message news:a3r33g$28jj$1@digitaldaemon.com...
> >
> > OddesE <OddesE_XYZ@hotmail.com> wrote in message news:a3ph43$61j$1@digitaldaemon.com...
> > > Consider this pieces of code:
> > >
> > > define op var1 ** var3 = MyClass::Multiply(Var1,Var3)
> > > define op var1. *+ var3 = MyClass::Add(Var1.Var3)
> > > define op var1 #* var3 = MyClass::Multiply(Var1,Var3)
> > > define op var1. #+ var3 = MyClass::Add(Var1.Var3)
> > > define op var1 $* var3 = MyClass::Multiply(Var1,Var3)
> > > define op var1. $+ var3 = MyClass::Add(Var1.Var3)
> > > define op var1 @* var3 = MyClass::Multiply(Var1,Var3)
> > > define op var1. @+ var3 = MyClass::Add(Var1.Var3)
> > > define op var1 &* var3 = MyClass::Multiply(Var1,Var3)
> > > define op var1. &+ var3 = MyClass::Add(Var1.Var3)
> > >
> > > MyClass::result =  Var1 *+ Var1 ** Var3
> > > MyClass::result =  Var1 #+ Var1 #* Var3
> > > MyClass::result =  Var1 $+ Var1 $* Var3
> > > MyClass::result =  Var1 @+ Var1 @* Var3
> > > MyClass::result =  Var1 &+ Var1 &* Var3
> >
> > Yup I do see difficulty with your code.   It's difficult to read because
> you
> > have
> > chosen to define the same function for multiply and add a total of 5
> times.
> >
>
> I actually did not do that. 5 other programmers did that. Some of them
> were on other teams, others were with other companies that we use
> libraries of. All these declarations were in different files and were part
> of different libraries. Unfortunately they all do the same thing, they all
> add two strings. All these programmers noticed the lack of string support
> in language X but, since it did include adding new operators, they
> invented one of their own. Unfortunately I have to memorize them all,
> or find different libraries.

Hm. Without either operator overloading or adding new ops, I have seen this issue again.

There are plenty of functions meaning the same, but spelling different, even in a library from the same concern:

CArray::RemoveAll
CListCtrl::DeleteAllItems
CMap::RemoveAllItems  ( I believe? Couldn't remember)
...

These are exact the same problem if you have none of both, operator overloading or new operators (And the problem is worse, since "size" and "Size" are different things ;-)

There could be a
String::
  concatenate
  add
  concat
  cat

All with proper, logical meanings (and CaSEs).


> > Very poor programming practice.
> > Consider the equivalent defined only once....
> > define op var1 ** var3 = MyClass::Multiply(Var1,Var3)
> > define op var1. *+ var3 = MyClass::Add(Var1.Var3)
> >
>
> You try to convince hundreds of programmers to use your style...
> Math already has defined these operators, but no, you can't
> use those...Invent some of your own...

Maybe operator defining is just simple a step away from functional call to the infix-notation of functions. There were really times, I wanted to have something like:

midsum = a :avg: b :avg: c :avg: d;

instead of

midsum = a.avg(b.avg(c.avg(d)));



> > MyClass::result =  Var1 :+ Var1 :* Var3
> >
> > Yes, quite readable now that the purposeful obfuscation has been
removed.
>
> What does the : mean?
> Where is the standard? What prevents other companies from using
> entirely different standards? How am I supposed to remember all
> this? I am not as good as you at memorizing tables with useless data...

I agree with "D" (exept his name... "D"... can I call you troll? ;-).

It is surely a very very powerful feature, if you can completly hide a new datatype to the user, providing him with the same operators he always used. If they are implemented good, and no mistake is done, the user of your classes can become a very good feeling.

But this is not reality. Too much I saw bad implementations of operators, since someone either used them in different meaning.

---------------------------
1. Bad case:
Someone thinks it looks pretty:

As example I saw once the operator << overloaded in a stack- implementation to push something onto the stack and >> to pop something. The author was very proud of this nonsens:

p << 4;

Looks good, if you know that << is push, but is terrible, if you do not and think << has to be bitwise-shift-left or something like a stream-operator (you see, even in the C++-Standardlibrary there are an inconsistenz use of <<).

---------------------------
2. Bad case:
Someone misunderstood the real meaning of an operator:

The equality-operator is a big problem to overload (as stated
somewhere above). Should it equals to object identity or to
value identity?
Another big thing is operator new. Maybe 8 out of 10
implementations of this operator I saw turned out to have at
least one bug in them. It is powerful, but dangerous!


So I really do not recommend to allow operator overloading (although I use it really frequently in C++ ;-)


Now to adding new operators:
The point is, they cannot harm existing operators, so there could
no confusing things.

This meens, the user cannot be fooled to think, he does use
a built-in type but is using a class you support. This has dis- but
also has advantages.
But you can, if you do it right, give almost the feeling to the user,
that it is a built-in type. He only has to remember to add, e.g. a ":"
before the usual operators.

And second, you can define your shortcuts, for which they are no operator currently exist, as example to push to the stack, you could use

p <=- 2;  and  p -=> a

Looks pretty nice too, but cannot be mistaken with << and >>.



> Great, all these lists and tables. Let's name our variables var1, var2 and
> var3,
> then keep a list of what they mean.

This would be as stupid as defining :!2$-> of two strings to concatination. I think you can find bad variable names as you can find bad operator names.

Maybe it is easier to find bad variable names, but this doesn't affect the
thing,
that

a :+ b :+ c

is always more readable than

a.add(b.add(c))

(at last IMHO)



> > No standards are needed.   :V+ is a nice enough name for vector add.
>
> Your opinion. I don't agree. I still don't mean what the colon stands for. I could guess at the V, but I don't like guessing what code does, I like knowing so from experience and common sense.

Here I have to agree to Odysseus, err,  Odesse ;)
I think code conventions will do the thing, now or later.


> > Matrix multiplication might could be indicated by :M* or :MtxMul, or
> > whatever
> > name the programmer sees fit to use.
>
> Ah yes, :MtxMul...
> Starts to sound a lot like a regular function name doesn't it?
> What is the point?

The point (to me, at least) is the INFIX-NOTATION!
It is even much better to write

a add (b add c) mul d

Than

a.add(b.add(c).mul(d))

Maybe because I never coded in Lisp before, but I think many other coders will agree with me.


> >   Primarily because as you yoursef showed in another thread,
> > they aer forced to by the limited number of existing operators.
> >
>
> Yes, but why replace the existing ones with substitutes that do exactly the same, such as :V+ ?

Because they cannot be confused with ordinary once. I think
this is a really important face (and THE fact, that Walter did not
include operator overloading in the draft)


> > Odesse writes:
> > > Who keeps me from doing this:
> > >
> > > define op var1 .* var3 = MyClass::Add (Var1,Var3)
> > > define op var1. .+ var3 = MyClass::Multiply (Var1.Var3)
> > >
> > > MyClass::result =  Var1 .+ Var1 .* Var3
> >
> > Absolutely nothing.  Do you regularly program in that manner?
>
> I don't, but you keep saying that programmers are clueless and do such things. I am asking you how your method prevents this.

It prevent this not.
But overloading did not prevent the user from
Foo Foo::operator+(Foo f)
{  return value * f.value; }

The exception is, that you see, that the operator .+ is user-defined
(note the point before the +) and you do not see that same from
operator+, if not explicit looking at the types.
So you generally do not expect a problem.


> > 1. Existing operators do not change their meaning and therefore
> >     all lines containing existing operators can be taken at face value
> >     rather than being suspect of hiding some unsuspected behaviour.
> >
>
> With operator overloading (if used right) they don't change their
> meaning either. + means to add something. You are just changing
> the something you want to add.
> You could define operator+ to multiply it's parameters ofcourse,
> but you could do that using any of the constructs we are talking
> about.

For operator+ it might be clear. But as example operator<<.
Is it a shift-left or a output-into-stream?  Such operators already
received more than one meaning, and it will become more (as I showed
above on "stack push")...


> > 2. There is a 1:1 relationship between operator and function which
enables
> >     the programmer to use a simple operator table to figure out what a
> > specific
> >     equation means
>
> I don't like those tables, and with normal operators you don't need them, you already know what + means.

What means equal to you? bitwise equal or object identity (e.g. it IS the
same reference)?

As example to the impact: If you say bitwise, you are not Java-conform. Java-coder expect this to be equality of object identity.


> > 3. I recommend that all new operators have the same precedence. Hence
> > there
> >     is no confusion in the order of operations, and no unnatural
> > consequences to
> >    what would otherwise be automatic reordering.

Hm, I disagree. What is the disadvantage to intreduce precedence-values? E.g. they range from 0 to 100?


> A yes:
>
> Assuming a class int64 with operators defined for adding and multiplication:
>
> int64 a, b, c;
>
> a := a :+ b :* c;
>
> Now you will get different results then you would expect from plus and multiply operations... It just doesn't make sense that all math knowledge becomes invalid when using operators.

Odesse is right.


> > 4. New operators would provide visual cues that readily distinguish them
> > from
> >     existing operators, thereby allowing the programmer to readily
> > identify
> > new program
> >     behaviour.
>
> The behaviour for + is not new, it is still adding two entities. You are just allowing new types to be added.

This the last time I will write this: It is not clear. Maybe in most cases
for +.
But not for all other operators. Not enough, you did not expect errors
in +, because you are fooled that + is build-in. But they can be errors in
operator+



> > Yet the first equal under your regime of operator overloading would have
a
> > meaning that is entirely
> > different than the second equal symbol,.
>
> Right, entirely different. No relation whatsoever. Are you kidding me? I am assigning one variable to another, since when does the assignment of objects of a class have nothing in commom with assigning integers or floats? Should we also use different operators for addition of all basic types? The have "nothing in common" after all...

Assignment is not that basic:
If you have a class with a pointer in it, would you copy the simple pointer,
so that both classes refer to the same object or would you also copy the
data behind the pointer? This is a common problem, you cannot decide
generally. It make even be true, that you need both behaviour in the same
programm.

Some coder build then member functions like .clone().

Some do not.

You do not surely know, what the class is doing you use if you call operator=...


> > Odesse writes:
> > > You still didn't say that
> > >
> > > MyClass result.Assign(MyClass::.Add (Var1, MyClass::Multiply (Var1,
> > Var3)));
> > >
> > > is more readable than
> > >
> > > MyClass result = Var1 + Var1 * Var3;
> > >
> > > probably because it just isn't.
> >
> > Yes, the first statement is more readable than the second because in the case of the second statement we are not told what + and * do.
>
> Yes we are, by our math teachers when we go to school.
> You know what plus is supposed to do. You also know what Add()
> is supposed to do. If they really do it is a different matter.
> If you can't grasp what + is supposed to do, why would Add()
> be more clear? I don't know what
>
> House1 = House2 + House3;
>
> is supposed to do, but then again I don't know what
>
> House1.Assign (House::Add (House2, House3));
>
> is supposed to do either. Do you? Maybe add the windows
> in the house?

Yeah. operator overloading can be REAL powerful. I like it. It is good. But only as long as you use it right. I think this weapon is much too powerful.

New operators don't have some of the problems of overloading, or at least the user is aware, that there might be Problems.


> > Odesse writes:
> > > And clearly no one can now the meaning of .+ and .*
> >
> > Since there is a 1:1 correspondance of  label and funtion, you consult
> > your
> > opcode table.
>
> Great all these tables.

Hm. I would not think that .+ is a multiplication. It looks somelike a addition. I recognized this without a table...



> > You can not do this with + and * since there are no visual clues that +
> and
> > * are
> > doing anything outside their ordinary meaning.
> >
> > a = b + c
> > d = e + f
> >
> > In your inferior system of operator overloading the first example above
> may
> > be
> > doing a simple addition,. while the second could be adding a graphic to
a
> > web page an
> > uploading the result to a server.
> >
> > Quite foolish.
>
> It could also format your harddisk. But so could your :+ operator.

Yes, but those could NOT the build-in + operator for build-in types. And thats the point the troll wanted to make.


> There are some visual cues that the operator is overloaded, because the parameters used with it are non-standard. The operator itself looks the same, but so it should. You are performing a standard operation with it, you are just performing it on non-standard parameters. Hence the visual cue should come from the parameters.

But you do not see that "a" is a class. It could be a integer?


> > > At least with normal operators I know what they usually do and have a reference in math or other languages to draw experience on.
> >
> >    And you can still use that by creating new operators with names
similar
> > to the existing operators.  :+ in place of + for example.
>
> They are confusing. Especially the fact that everyone can, and will,
define
> different operators to perform the same operation on the same types of variables (say vectors, strings, the boundschecked pointer you would like) is going to cause a lot of confusion.

This is right. One of the disadvantages of new operators.

But anyway, it is a disadvantage of functions too. Count how many similar functions there are to copy memory...


> >   But you have the advantage of creating new operators with more
> > appropriate labels as well
> >
> >   For example :dot or :cross for dot and cross products  If the colon
were
> > more visible
> > on this screen I would have used colon period, for dot product and colon
x
> > for cross product.
>
> ?
> You are already using the colon.
> :cross looks like a function, not an operator. What is the use of
operators
> if they have names? You might as well define :add instead of +. The idea behind operator overloading is to use the notation of the problem domain. If you are describing a mathematical addition you want to use the mathematical operator to describe that operation.

And infix. You cannot write infix-notation with function calling convention...



> > > > It depends on what A and B are.and what you are trying to do.
Perhaps
> > > > A
> > > > and
> > > > B are objects, the == syntax can have three equally appropriate
> > > > meanigns.
> > > > A
> > > > is numerically identical to B,  A is functionally identical to B, A
> > > > and
> > > > B
> > > > are the same object.
> > > >
> > > > With one equal sign, how do you intend to distingish between these
> > > > three
> > > > poetntial meanings?  How do you intend to implement more than one of
> > > > them
> > > > at
> > > > a time?
> > > >
> > > > I await your response.
> >
>
> To check if the objects were one and the same, you would compare the references, not the object they are pointing to.
>
> To check wheter the objects contain the same information you would check the objects themselves.

You only have one operator==. Maybe you decide, somehow, that equality
by value is what you mean. But somebody else (maybe a java-guru)
did expect this as the last thing in his mind. Who has right?

C++ recommends using compare by value, other similar languages does not.



> How do you do this in C/C++?
> You mean
>
> int a;
> int *pa
> int *pb;
>
> pa = &a;
> pb = &b;
>
> if (*pa == *pb)     // same number in instances of int
> if (pa == pb)         // same instance of int
>
> I don't see why operator overloading would make this more difficult.

Comparing the instances is much more faster than comparing the values. If you write a class which time is essential, you may want to compares it by instance (So you do not have to call operator= for each class member).

But maybe other users of your class expect it comparing by value?

Although in some languages, as I stated above, comparing by instance is the normal way, and using a .equals() is the unusual...

There are NO well-known standards uppon all operators.


>
> >
> >
> > Odesse writes:
> > > int A = 10;
> > > int B = 10;
> > > int C = 0;
> > >
> > > if (A == B)
> > >    C = A;
> > > B = 5;
> > >
> > > What value does C have?
> >
> > If this langauge allows all operators to be overloaded even for the base
> > types
> > then we do not know the answer because somewhere elsewhere in the
program
> > the operators may have hand their meaning altered.
> >
>
> No one is saying that operators should be overloaded for operations
> between base types, so we *do* know what value C has. You are
> avoiding the conclusion. If we compare objects we want to know if
> they contain the same information. If we want to know if two references
> point to the same object, we compare the references, not the objects
> themselves. These are two different operations on two different types,
> hence they yield two different results.

Logical ideas and abstracts may not be the reality. The operator overloading IS still a big pool of errors that do more harm than good.


Imi

--
Oh dear, its 4:30am, I hope my better side don't kill me for usenetting so long...

"Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a66n7e$1nne$1@digitaldaemon.com...

> So I really do not recommend to allow operator overloading (although I use it really frequently in C++ ;-)

Hey hey hey, stop!.. let it be there, just leave it to us gurus =)

> This meens, the user cannot be fooled to think, he does use
> a built-in type but is using a class you support. This has dis- but
> also has advantages.
> But you can, if you do it right, give almost the feeling to the user,
> that it is a built-in type. He only has to remember to add, e.g. a ":"
> before the usual operators.

But who'd stop some coder from overloading operator *+-/ then? And what would it mean? Your guess...

> a :+ b :+ c
>
> is always more readable than
>
> a.add(b.add(c))
>
> (at last IMHO)

And a ~ b ~ c would be even more readable, IMO.

> It is even much better to write
>
> a add (b add c) mul d
>
> Than
>
> a.add(b.add(c).mul(d))
>
> Maybe because I never coded in Lisp before, but I think many other coders will agree with me.

In general, I agree. So user-defined operators are great, but let's forbid them to be usual identifiers. So:

    Vector operator cross (Vector a, Vector b) { ... }
    a = b cross c;

> Because they cannot be confused with ordinary once. I think
> this is a really important face (and THE fact, that Walter did not
> include operator overloading in the draft)

In fact, the programmer very frequently doesn't care whether it is the "ordinary" operator or a user-defined... all he wants to know is that a + b will always add b to a, be they integers, vectors, matrices, or dates...

> For operator+ it might be clear. But as example operator<<.
> Is it a shift-left or a output-into-stream?  Such operators already
> received more than one meaning, and it will become more (as I showed
> above on "stack push")...

Walter clearly stated that, if operator overloading is to be implemented, things like using << for output will be strictly prohibited by him personally. I second that. =)


> This the last time I will write this: It is not clear. Maybe in most cases
> for +.
> But not for all other operators. Not enough, you did not expect errors
> in +, because you are fooled that + is build-in. But they can be errors in
> operator+

There can be errors in operator :+ as well.
Also, all operators have rather strict meaning. If only
we get the "input" and "output" operators in D, it would be great!

> You do not surely know, what the class is doing you use if you call operator=...

I suggest forbid overloading = at all. = should copy references, never objects.

"Pavel Minayev" <evilone@omen.ru> wrote in message
news:a66s4k$1ph2$1@digitaldaemon.com...
<SNIP>
> In general, I agree. So user-defined operators are great, but let's forbid them to be usual identifiers. So:
>
>     Vector operator cross (Vector a, Vector b) { ... }
>     a = b cross c;
>

I agree with this.


My standpoints in this discussion have become rather settled, and I am afraid I won't easily change them anymore, unless someone comes up with some really good and new argument.

1. I support operator overloading for standard operators.
    As to operators == and =, I agree that there could be
    ambiguity between comparing / assigning by reference
    or by value, but this could be resolved:

    MyClass a, b;

    *a = *b;
    if (*a == *b)     // By value
    a = b;
    if (a == b)         // by reference, or
    &a = &b;
    if (&a == &b);

    Whatever, essentially a notation that says by reference or by
    value is needed. Assignment by value means deep copy,
    otherwise destroying one object will render both invalid, not
    what you would expect in 99% of the cases.

    -, +, /, and * are usually well defined and all you  need.
    Operators such as new, delete and << and >> could
    be forbidden.

2. I support infix notation with precedence for arbitrary functions,
    this will allow for creating new operator-like behaviour and is
    all you need most of the time for special functions such as dot
    product and cross product. I agree with Pavel that normal
    function naming rules should be applied, I am against using
    :+: to add two entities, because it can, and will lead to hundreds
    of different versions of plus operators all doing the same but
    looking very different. Immanuel was saying in a previous post
    that this can also be done with normal functions, but that just
    proofes my point. :+: offers no significant advantages over add
    because there is no standard there either. Math however is as
    standard as standards get, and so is +. Please do not allow
    inventing arbitrary symbols using combinations of :, !, @, #, $,
    %, +, -, /, * etc. to define new operators, it will not make
    programming more easy at all!


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a68s84$872$1@digitaldaemon.com...

>     Whatever, essentially a notation that says by reference or by
>     value is needed. Assignment by value means deep copy,
>     otherwise destroying one object will render both invalid, not
>     what you would expect in 99% of the cases.

You don't actually "destroy" anything in D. Even operator
delete doesn't do that if it isn't safe, AFAIK - or am
I wrong, Walter?

>     -, +, /, and * are usually well defined and all you  need.
>     Operators such as new, delete and << and >> could
>     be forbidden.

I would leave << and >> there for things like bignum.
new and delete should be restricted.

Also, I'd add two more built-in operators, "in" and "out". These could be used for streams, stacks, queues, and anything similar that allows to put values in and take them out:

    int foo, bar;
    stdout out "Hello, world!\n" out "foo = " out foo out \n;
    stdin in foo in bar;

"OddesE" <OddesE_XYZ@hotmail.com> schrieb im Newsbeitrag news:a68s84$872$1@digitaldaemon.com...
>     Whatever, essentially a notation that says by reference or by
>     value is needed. Assignment by value means deep copy,
>     otherwise destroying one object will render both invalid, not
>     what you would expect in 99% of the cases.

Hm, I tend to have pointers in classes without the need to destroy them at ~this, because the main meaning of pointer is (for me), a reference to an object, the class did not own.


>     -, +, /, and * are usually well defined and all you  need.
>     Operators such as new, delete and << and >> could
>     be forbidden.

I agree. If D allows only to overload "safe" operators, maybe we
get some of the advantages together. Whoever, I recommend
to allow defining other infix-notation-operators, because this
can become VERY handy.
As example, I could not believe, that stream-output without infix
notation would let to any happy coder ;-)


Imi

"Immanuel Scholz" <digitals-mars@kutzsche.net> wrote in message news:a6a6n6$q8a$1@digitaldaemon.com...

> I agree. If D allows only to overload "safe" operators, maybe we
> get some of the advantages together. Whoever, I recommend
> to allow defining other infix-notation-operators, because this
> can become VERY handy.
> As example, I could not believe, that stream-output without infix
> notation would let to any happy coder ;-)

Well if D would support variants (or object packaging as seen in C#), and paramarrays, it could be done like in Pascal:

    stdout.print("Hello, world!", 666, 123.456);

But I guess operator overloading is a better solution. Some kind of operators, like "in" and "out" I've suggested in earlier post, or maybe something like <- and -> ?

    char[] name;
    stdin -> name;
    stdout <- "Hello, " <- name <- "!\n";

"Pavel Minayev" <evilone@omen.ru> schrieb im Newsbeitrag news:a6a95d$r51$1@digitaldaemon.com...
> "Immanuel Scholz" <digitals-mars@kutzsche.net> wrote in message news:a6a6n6$q8a$1@digitaldaemon.com...
>
> > I agree. If D allows only to overload "safe" operators, maybe we
> > get some of the advantages together. Whoever, I recommend
> > to allow defining other infix-notation-operators, because this
> > can become VERY handy.
> > As example, I could not believe, that stream-output without infix
> > notation would let to any happy coder ;-)
>
> Well if D would support variants (or object packaging as seen in C#), and paramarrays, it could be done like in Pascal:
>
>     stdout.print("Hello, world!", 666, 123.456);
>
> But I guess operator overloading is a better solution. Some kind of operators, like "in" and "out" I've suggested in earlier post, or maybe something like <- and -> ?
>
>     char[] name;
>     stdin -> name;
>     stdout <- "Hello, " <- name <- "!\n";

-> has a different meaning. Although it is not used in D, I prefer another symbol.

Maybe -=> or >>> ?