I know I'm going to get shot for this but...

Why don't we just byte the bullet and allow the opCat to be used, eg

steram.writeLine("Fred was here in: " ~ date ~ ". He has been here " ~ n ~ "
times before.");

Don't hit me too hard.


"Vathix" <vathix@dprogramming.com> wrote in message news:c5rhae$1eek$1@digitaldaemon.com...
> Operators << and >> are for shifting, overloading opCall("like")("this")
> is ugly to me :P and hard to type. So I have yet another idea for
> type-safe variable arguments. Here's the idea in code:
>
>
> class Foo
> {
>     char[] buf;
>     void opStream(char[] x) { buf ~= x; }
>     void opStream(char x) { buf ~= x; }
>     void opStream(Object o) { buf ~= o.toString(); }
>     char[] toString() { return buf; }
> }
>
>
> int main()
> {
>     Foo foo;
>     foo$("this calls", " opStream for", " each parameter", '\n');
>     printf("Foo = '%.*s'\n", foo.toString());
>     return 0;
> }
>
>
> I just threw in the symbol $ so it doesn't conflict with opCall and so you can better understand what it's doing. opStream always has void return type and exactly one parameter. For input streams you could use out parameters.
>
>
> -- 
> Christopher E. Miller

> All right, good point.
> So
>     foo("hello"; " world");
> would be at least
>     foo("hello");
>     foo(" world");
> I like it..
> Sorry about my post.

Ack - I didn't mean to imply your idea was a bad one. I just don't think it
should be called "variable arguments". Whether a semi-colon or $ or
something else is used is somewhat secondary. Heck, back in Walter's
original thread there were probably other suggestions - well, those who
read closely can find I suggested the syntax foo[a,b,c]
 http://www.digitalmars.com/drn-bin/wwwnews?D/19001
So you see I think the general idea is just swell.

-Ben

Hi!

>I have proposed many ideas here for type safe variable arguments; this is another one. I called it opStream because most (all?) cases where you want variable arguments is to stream data into an object. I am proposing a friendlier syntax, because foo("this is")(" using opCall")(" and doesn't")(" look")(" too pretty"), and the C++ method of using << and >> is out of the question. I don't stand by my proposals 100%, I just say what is interesting to me and hope it is inspiring to improve anything.

I'm a C++ programmer interested in switching to D, however I dislike not having cin and cout in D.

I understand that the << and >> operators are out of question, but since D eliminated the need for a -> operator couldn't you just use <- and -> for streaming?

int i;
cin -> i;
cout <- "i is " <- i <- endl;

That would call cin.opStreamIn and cout.opStreamOut ... bad idea?

-Mike

After thinking a bit about it I came up with an extended solution. No opStream, but a new keyword ("streaming" or "multi" or whatever):

class bar
{

/* The "streaming" keyword (or "multi" or whatever) declares a property as
"streamable" */

streaming void foo1(int i) { /* ... */ }
streaming void foo1(char c) { /* ... */}

streaming void foo2(int i) { /* ... */}
streaming void foo2(char c) { /* ... */}

streaming int foo1() { return /* ... */}
streaming char foo1() { return /* ... */}

streaming int foo2() { return /* ... */}
streaming char foo2() { return /* ... */}

/* ... */

}

Later on:

bar b;
int i = 3;
char c = 'a'
b.foo1 <- i <- c; // calls void bar.foo1(i) and void bar.foo1(c)
b.foo2 -> i -> c; // calls int bar.foo2() and char bar.foo2()

Maybe you find that plausible in some way or the other, but I think that wouldn't be too bad :-)

-Mike

> I'm a C++ programmer interested in switching to D, however I dislike not having
> cin and cout in D.
> 
> I understand that the << and >> operators are out of question, but since D
> eliminated the need for a -> operator couldn't you just use <- and -> for
> streaming?
> 
> int i;
> cin -> i;
> cout <- "i is " <- i <- endl;
> 
> That would call cin.opStreamIn and cout.opStreamOut ... bad idea?
> 
> -Mike
> 
> 

<< and >> are not out of the question, just likely not preferred by some programmers (probably the reason this discussion doesn't explore them: they're looking for a better way).  The DSC.io project provides these C++-style stream operators as well as a different variation.  It's the programmers choice as to which to use in an application.  This very nicely implemented library is being discussed at www.dscource.org, and I believe is close to beta access so that others can play with it (I'm really, really hoping ;-) ).

> << and >> are not out of the question, just likely not preferred by some programmers (probably the reason this discussion doesn't explore them: they're looking for a better way).  The DSC.io project provides these C++-style stream operators as well as a different variation.  It's the programmers choice as to which to use in an application.  This very nicely implemented library is being discussed at www.dscource.org, and I believe is close to beta access so that others can play with it (I'm really, really hoping ;-) ).

Argh! I meant www.dsource.org, of course.

"John Reimer" <jjreimer@telus.net> wrote in message news:c6137v$vh9$1@digitaldaemon.com...
>
> > I'm a C++ programmer interested in switching to D, however I dislike not
having
> > cin and cout in D.
> >
> > I understand that the << and >> operators are out of question, but since
D
> > eliminated the need for a -> operator couldn't you just use <- and ->
for
> > streaming?
> >
> > int i;
> > cin -> i;
> > cout <- "i is " <- i <- endl;
> >
> > That would call cin.opStreamIn and cout.opStreamOut ... bad idea?
> >
> > -Mike
> >
> >
>
> << and >> are not out of the question, just likely not preferred by some

Yes they are (unfortunatelly) out of the questions because the order of
chained << or >> isn't defined :(

> programmers (probably the reason this discussion doesn't explore them: they're looking for a better way).  The DSC.io project provides these C++-style stream operators as well as a different variation.  It's the programmers choice as to which to use in an application.  This very nicely implemented library is being discussed at www.dscource.org, and I believe is close to beta access so that others can play with it (I'm really, really hoping ;-) ).

> 
> Yes they are (unfortunatelly) out of the questions because the order of
> chained << or >> isn't defined :(
> 

Are we talking about a different implementation?  I'm just saying that it must be possible to do in D.  Kris's DSC.io library does this

Stdout << x << "this is a test" << y << Stdout.newline;

... and it works flawlessly.

Am I missing something?

John Reimer wrote:

>>
>> Yes they are (unfortunatelly) out of the questions because the order of
>> chained << or >> isn't defined :(
>>
> 
> Are we talking about a different implementation?  I'm just saying that it must be possible to do in D.  Kris's DSC.io library does this
> 
> Stdout << x << "this is a test" << y << Stdout.newline;
> 
> ... and it works flawlessly.
> 
> Am I missing something?

Sorry, where x and y are int or some other numerical type.

"John Reimer" <jjreimer@telus.net> wrote in message news:c616ir$16o5$2@digitaldaemon.com...
> John Reimer wrote:
>
> >>
> >> Yes they are (unfortunatelly) out of the questions because the order of
> >> chained << or >> isn't defined :(
> >>
> >
> > Are we talking about a different implementation?  I'm just saying that it must be possible to do in D.  Kris's DSC.io library does this
> >
> > Stdout << x << "this is a test" << y << Stdout.newline;
> >
> > ... and it works flawlessly.
> >
> > Am I missing something?
>
> Sorry, where x and y are int or some other numerical type.

I have also written a class that can be used like that (i will have to check
it
out to see how it works for classes)

But the problem is that someone on this newsgroup said that the order of execution of chained << is implementation specific and code shouldn't be written that depends on this order.

I'm not sure if this is true but it is what i read!