August 21, 2004 Re: the $ token | ||||
---|---|---|---|---|
| ||||
Posted in reply to h3r3tic | "h3r3tic" <h3r3tic@dev.null> wrote in message news:cg63u0$v8v$1@digitaldaemon.com... > Matthew wrote: > > You could swritef(), which would be clear, and would probably be less abusive to the heap to boot! > > but it's still so C-ish. being able to do "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP. Ah yes, but I think it's been suggested previously many times that the infix string concatenation operator should automatically call toString() on any of its arguments that are not already strings, prior to concatenation. Hence: Object person = new Person("Walter", "Bright"); long factor = 20; "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal man"; would cause the call of std.string.toString(long) and Person.toString(), so we'd get: "The IQ of Walter Bright is 20 times that of mortal man": Although I'm one of those that consistently opposes the overloading of << and >>, this is a different case, since every Object has the facility to toString() itself, and the built-ins are already covered. It wouldn't work for structs, but then that's a good thing anyway. For enums, you would provide a suitable toString() in the same module as the enum, and the compiler would use that. btw, if I'm wrong in saying it's been suggested before, I suggest it now. |
August 21, 2004 Re: the $ token | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | The problems with that particular approach are twofold: 1) enforcing the binding of Phobos via std.string.toString(). There's a few issues with doing that, but it's perhaps a matter of personal taste rather than technicalities such as namespace pollution (which std.* is terribly good at). 2) more importantly: it doesn't work for unicode strings, because providing a "dchar toString()" in each class is not covariant with the "char toString()" living in the root Object. I wish there was an nice, clean, elegant solution to this ... "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg65e6$100p$1@digitaldaemon.com... > > "h3r3tic" <h3r3tic@dev.null> wrote in message news:cg63u0$v8v$1@digitaldaemon.com... > > Matthew wrote: > > > You could swritef(), which would be clear, and would probably be less abusive to the heap to boot! > > > > but it's still so C-ish. being able to do "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP. > > Ah yes, but I think it's been suggested previously many times that the infix string concatenation operator should > automatically call toString() on any of its arguments that are not already strings, prior to concatenation. Hence: > > Object person = new Person("Walter", "Bright"); > long factor = 20; > > "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal man"; > > would cause the call of std.string.toString(long) and Person.toString(), so we'd get: > > "The IQ of Walter Bright is 20 times that of mortal man": > > Although I'm one of those that consistently opposes the overloading of << and >>, this is a different case, since every > Object has the facility to toString() itself, and the built-ins are already covered. It wouldn't work for structs, but > then that's a good thing anyway. For enums, you would provide a suitable toString() in the same module as the enum, and > the compiler would use that. > > btw, if I'm wrong in saying it's been suggested before, I suggest it now. > > > |
August 21, 2004 Re: the $ token | ||||
---|---|---|---|---|
| ||||
Posted in reply to antiAlias | "antiAlias" <fu@bar.com> wrote in message news:cg68tk$11on$1@digitaldaemon.com... > The problems with that particular approach are twofold: > > 1) enforcing the binding of Phobos via std.string.toString(). There's a few > issues with doing that, but it's perhaps a matter of personal taste rather > than technicalities such as namespace pollution (which std.* is terribly > good at). > > 2) more importantly: it doesn't work for unicode strings, because providing > a "dchar toString()" in each class is not covariant with the "char > toString()" living in the root Object. I wish there was an nice, clean, > elegant solution to this ... Doh! Yes, silly me and my anglophoneaphiling. I'm sure there's an elegant solution out there worth having though. It'd make things much simpler in many ways. It'd also make D amenable to the Fast String Concatenation technique (which a certain mouthy pommie invented ...). > > > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg65e6$100p$1@digitaldaemon.com... > > > > "h3r3tic" <h3r3tic@dev.null> wrote in message > news:cg63u0$v8v$1@digitaldaemon.com... > > > Matthew wrote: > > > > You could swritef(), which would be clear, and would probably be less > abusive to the heap to boot! > > > > > > but it's still so C-ish. being able to do "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP. > > > > Ah yes, but I think it's been suggested previously many times that the > infix string concatenation operator should > > automatically call toString() on any of its arguments that are not already > strings, prior to concatenation. Hence: > > > > Object person = new Person("Walter", "Bright"); > > long factor = 20; > > > > "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal man"; > > > > would cause the call of std.string.toString(long) and Person.toString(), > so we'd get: > > > > "The IQ of Walter Bright is 20 times that of mortal man": > > > > Although I'm one of those that consistently opposes the overloading of << > and >>, this is a different case, since every > > Object has the facility to toString() itself, and the built-ins are > already covered. It wouldn't work for structs, but > > then that's a good thing anyway. For enums, you would provide a suitable > toString() in the same module as the enum, and > > the compiler would use that. > > > > btw, if I'm wrong in saying it's been suggested before, I suggest it now. > > > > > > > > |
August 21, 2004 Re: the $ token | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | Agreed. I'd really like to see automatic conversion through an operator. The tricky part is dealing with optional format-specifiers: think of dates, for example. How does one pass a format-specifier to the opString() method, while doing this: Date date = new Date (milliseconds_since_1970); char[] string = "The date is " ~ date; And what about floating-point? Perhaps you have to set the format in advance ? Java only has one char type, so they can get away with this more easily. What does C# do? "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg69c1$120n$1@digitaldaemon.com... > > "antiAlias" <fu@bar.com> wrote in message news:cg68tk$11on$1@digitaldaemon.com... > > The problems with that particular approach are twofold: > > > > 1) enforcing the binding of Phobos via std.string.toString(). There's a few > > issues with doing that, but it's perhaps a matter of personal taste rather > > than technicalities such as namespace pollution (which std.* is terribly > > good at). > > > > 2) more importantly: it doesn't work for unicode strings, because providing > > a "dchar toString()" in each class is not covariant with the "char > > toString()" living in the root Object. I wish there was an nice, clean, > > elegant solution to this ... > > Doh! Yes, silly me and my anglophoneaphiling. > > I'm sure there's an elegant solution out there worth having though. It'd make things much simpler in many ways. It'd > also make D amenable to the Fast String Concatenation technique (which a certain mouthy pommie invented ...). > > > > > > > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg65e6$100p$1@digitaldaemon.com... > > > > > > "h3r3tic" <h3r3tic@dev.null> wrote in message > > news:cg63u0$v8v$1@digitaldaemon.com... > > > > Matthew wrote: > > > > > You could swritef(), which would be clear, and would probably be less > > abusive to the heap to boot! > > > > > > > > but it's still so C-ish. being able to do "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP. > > > > > > Ah yes, but I think it's been suggested previously many times that the > > infix string concatenation operator should > > > automatically call toString() on any of its arguments that are not already > > strings, prior to concatenation. Hence: > > > > > > Object person = new Person("Walter", "Bright"); > > > long factor = 20; > > > > > > "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal man"; > > > > > > would cause the call of std.string.toString(long) and Person.toString(), > > so we'd get: > > > > > > "The IQ of Walter Bright is 20 times that of mortal man": > > > > > > Although I'm one of those that consistently opposes the overloading of << > > and >>, this is a different case, since every > > > Object has the facility to toString() itself, and the built-ins are > > already covered. It wouldn't work for structs, but > > > then that's a good thing anyway. For enums, you would provide a suitable > > toString() in the same module as the enum, and > > > the compiler would use that. > > > > > > btw, if I'm wrong in saying it's been suggested before, I suggest it now. > > > > > > > > > > > > > > > |
August 21, 2004 Re: the $ token | ||||
---|---|---|---|---|
| ||||
Posted in reply to antiAlias | "antiAlias" <fu@bar.com> wrote in message news:cg68tk$11on$1@digitaldaemon.com... > The problems with that particular approach are twofold: > > 1) enforcing the binding of Phobos via std.string.toString(). There's a few > issues with doing that, but it's perhaps a matter of personal taste rather > than technicalities such as namespace pollution (which std.* is terribly > good at). > > 2) more importantly: it doesn't work for unicode strings, because providing > a "dchar toString()" in each class is not covariant with the "char > toString()" living in the root Object. I wish there was an nice, clean, > elegant solution to this ... Easy(-ish). It takes its lead from the leftmost concatenation thingy. In abscense of a leading string, it assumes char[]. Of course, this still requires use of argument-based string-type deduction, as in char[] toString(int , char[]); dchar[] toString(int, dchar[]); but I reckon that facility is going to be needed anyway. > > > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg65e6$100p$1@digitaldaemon.com... > > > > "h3r3tic" <h3r3tic@dev.null> wrote in message > news:cg63u0$v8v$1@digitaldaemon.com... > > > Matthew wrote: > > > > You could swritef(), which would be clear, and would probably be less > abusive to the heap to boot! > > > > > > but it's still so C-ish. being able to do "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP. > > > > Ah yes, but I think it's been suggested previously many times that the > infix string concatenation operator should > > automatically call toString() on any of its arguments that are not already > strings, prior to concatenation. Hence: > > > > Object person = new Person("Walter", "Bright"); > > long factor = 20; > > > > "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal man"; > > > > would cause the call of std.string.toString(long) and Person.toString(), > so we'd get: > > > > "The IQ of Walter Bright is 20 times that of mortal man": > > > > Although I'm one of those that consistently opposes the overloading of << > and >>, this is a different case, since every > > Object has the facility to toString() itself, and the built-ins are > already covered. It wouldn't work for structs, but > > then that's a good thing anyway. For enums, you would provide a suitable > toString() in the same module as the enum, and > > the compiler would use that. > > > > btw, if I'm wrong in saying it's been suggested before, I suggest it now. > > > > > > > > |
August 21, 2004 Re: the $ token | ||||
---|---|---|---|---|
| ||||
Posted in reply to h3r3tic | h3r3tic wrote:
> disclaimer: sorry if it has been mentioned before
>
>
> how about adapting the $ token to convert anything to a string ? like
>
> int foo = 5;
> char[] bar = $foo;
>
> // bar == "5"
>
> i dont think this would be a large problem to implement whilst BASIC dudes would instantly know it's sth bout strings :] in BASIC you read a$ as 'a string'.
>
> that's my vote in the $ war ;]
I think $ should be left unused. Metaprogramming tools like Lex, Yacc, SWIG, and ANTLR frequently receive code snippets which are injected into their output. They give special meaning to $ because C doesn't.
Assigning meaning to $ would make using these tools in conjunction with D more cumbersome.
-- andy
|
August 21, 2004 What does covariant mean? (was: the $ token) | ||||
---|---|---|---|---|
| ||||
Posted in reply to antiAlias | In article <cg68tk$11on$1@digitaldaemon.com>, antiAlias says... >providing >a "dchar toString()" in each class is not covariant with the "char >toString()" living in the root Object. What does covariant mean exactly? |
August 21, 2004 Re: What does covariant mean? (was: the $ token) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Batman | "Batman" <Batman_member@pathlink.com> wrote in message news:cg6pcs$1cch$1@digitaldaemon.com... > In article <cg68tk$11on$1@digitaldaemon.com>, antiAlias says... > > >providing > >a "dchar toString()" in each class is not covariant with the "char > >toString()" living in the root Object. > > What does covariant mean exactly? Well, I won't profer a definition of the word, but it is usually used in software engineering to describe the following condition class B {} class D : public B {} class X { virtual B clone(); } class Y : public X { virtual D clone(); } Because D is (publicly) derived from B, it is legitimate for Y's overload of X's clone() method to return D instead of B. This is because inheritance is an "Is-A" relationship. Hence, any D is-a B. Since X's clone() requires a B, Y's clone() can return a D, because a D is-a B. Make sense? (I hope so, 'cos that's my top shelf explanation. You'll have to hope for other posts if not. <G>) |
August 21, 2004 Re: the $ token | ||||
---|---|---|---|---|
| ||||
Posted in reply to antiAlias | "antiAlias" <fu@bar.com> wrote in message news:cg6ccg$139m$1@digitaldaemon.com... > Agreed. I'd really like to see automatic conversion through an operator. The tricky part is dealing with optional format-specifiers: think of dates, for example. How does one pass a format-specifier to the opString() method, while doing this: > > Date date = new Date (milliseconds_since_1970); > > char[] string = "The date is " ~ date; > > And what about floating-point? > > Perhaps you have to set the format in advance ? No. If people want formatting, they can use sprintf() or swritef(). I only think this is workable if the compiler *only* interprets ~ as a call to toString(), which it will either pick if up from the current module or the module of the convertee type or std.string, in that order. I'll turn into an opponent of this idea if we start to move towards an IOStreams kind of thing, with all that hideous setw() manipulator crap. > Java only has one char type, so they can get away with this more easily. What does C# do? IIRC, it calls the ToString() method. I think there's also IFormatter stuff, but it's been a long time since I had a play, and even then it wasn't that interesting. ;) > > > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg69c1$120n$1@digitaldaemon.com... > > > > "antiAlias" <fu@bar.com> wrote in message > news:cg68tk$11on$1@digitaldaemon.com... > > > The problems with that particular approach are twofold: > > > > > > 1) enforcing the binding of Phobos via std.string.toString(). There's a > few > > > issues with doing that, but it's perhaps a matter of personal taste > rather > > > than technicalities such as namespace pollution (which std.* is terribly > > > good at). > > > > > > 2) more importantly: it doesn't work for unicode strings, because > providing > > > a "dchar toString()" in each class is not covariant with the "char > > > toString()" living in the root Object. I wish there was an nice, clean, > > > elegant solution to this ... > > > > Doh! Yes, silly me and my anglophoneaphiling. > > > > I'm sure there's an elegant solution out there worth having though. It'd > make things much simpler in many ways. It'd > > also make D amenable to the Fast String Concatenation technique (which a > certain mouthy pommie invented ...). > > > > > > > > > > > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg65e6$100p$1@digitaldaemon.com... > > > > > > > > "h3r3tic" <h3r3tic@dev.null> wrote in message > > > news:cg63u0$v8v$1@digitaldaemon.com... > > > > > Matthew wrote: > > > > > > You could swritef(), which would be clear, and would probably be > less > > > abusive to the heap to boot! > > > > > > > > > > but it's still so C-ish. being able to do "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP. > > > > > > > > Ah yes, but I think it's been suggested previously many times that the > > > infix string concatenation operator should > > > > automatically call toString() on any of its arguments that are not > already > > > strings, prior to concatenation. Hence: > > > > > > > > Object person = new Person("Walter", "Bright"); > > > > long factor = 20; > > > > > > > > "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal > man"; > > > > > > > > would cause the call of std.string.toString(long) and > Person.toString(), > > > so we'd get: > > > > > > > > "The IQ of Walter Bright is 20 times that of mortal man": > > > > > > > > Although I'm one of those that consistently opposes the overloading of > << > > > and >>, this is a different case, since every > > > > Object has the facility to toString() itself, and the built-ins are > > > already covered. It wouldn't work for structs, but > > > > then that's a good thing anyway. For enums, you would provide a > suitable > > > toString() in the same module as the enum, and > > > > the compiler would use that. > > > > > > > > btw, if I'm wrong in saying it's been suggested before, I suggest it > now. > > > > > > > > > > > > > > > > > > > > > > > > |
August 21, 2004 Re: the $ token | ||||
---|---|---|---|---|
| ||||
Posted in reply to antiAlias | antiAlias wrote:
> Agreed. I'd really like to see automatic conversion through an operator. The
> tricky part is dealing with optional format-specifiers: think of dates, for
> example. How does one pass a format-specifier to the opString() method,
> while doing this:
>
> Date date = new Date (milliseconds_since_1970);
>
> char[] string = "The date is " ~ date;
>
> And what about floating-point?
>
> Perhaps you have to set the format in advance ?
>
> Java only has one char type, so they can get away with this more easily.
> What does C# do?
C# "primitive" types aren't. They still inherit Object. The runtime just optimizes them a bit differently when possible. :)
(everything has a ToString method: ints, strings, arrays, even pointers)
-- andy
|
Copyright © 1999-2021 by the D Language Foundation