D - feature concept : static passback
- Chris Sauls (36/36) Feb 16 2004 I don't really know if "static passback" is exactly the right name, but
- C (5/41) Feb 16 2004 Hmm this is a cool idea, if we could somehow apply it to modules also th...
- Chris Sauls (15/15) Feb 16 2004 Random thought... could the static passbacks for primitive types be
- Jeroen van Bemmel (10/17) Feb 16 2004 To me, this looks like a hack to make a static function that shouldn't h...
- Sam McCall (6/8) Feb 16 2004 Yeah, I don't seem to see the point either. If the syntax was changed to...
- Chris Sauls (26/48) Feb 17 2004 First off, bear in mind the examples I gave were from two other
- Jeroen van Bemmel (5/9) Feb 17 2004 me too, a solution here would be to treat "some text" as an (implicit)
- Chris Sauls (16/31) Feb 17 2004 Question is, how in D would one tell the compiler to check against a
- Jeroen van Bemmel (18/25) Feb 17 2004 If you mean: how would the compiler know that "some text" should be
- Sam McCall (11/20) Feb 17 2004 Isn't this how member functions work anyway? They're really just a
I don't really know if "static passback" is exactly the right name, but I think that's what we called it in the Lux docs... anyhow. In ColdC, the expression: ... "some text".left(72); ... Would be transformed into: ... $string.left("some text", 72); ... Where '$string' is of course ColdC's reference-by-name expression for objects... anyhow, to continue. In Lux, the expression: ... define struct myStruct { define static void func (myStruct foo) { // ... } } new myStruct { myVar; } myVar.func(); // <--- this expression here ... Would evaluate to: ... myStruct.func(myVar); ... So in other words, since there was no match for 'func()' in myStruct, it checked for 'static func(myStruct)' and used that. The basic rules we use in Lux is that any call on a structure, class, interface, or aspect which finds no match, first resolves to a static call with the instance as the first argument, and if /that/ doesn't match, then it throws an Exception. Is it possible to have something similar in D? And if there could be a way to implement the ColdC idea as well, that would be great for some of the libs, such as std.string, IMHO. - Chris S. - Invironz
Feb 16 2004
Hmm this is a cool idea, if we could somehow apply it to modules also that would be killer. C "Chris Sauls" <ibisbasenji yahoo.com> wrote in message news:c0rec0$o33$1 digitaldaemon.com...I don't really know if "static passback" is exactly the right name, but I think that's what we called it in the Lux docs... anyhow. In ColdC, the expression: ... "some text".left(72); ... Would be transformed into: ... $string.left("some text", 72); ... Where '$string' is of course ColdC's reference-by-name expression for objects... anyhow, to continue. In Lux, the expression: ... define struct myStruct { define static void func (myStruct foo) { // ... } } new myStruct { myVar; } myVar.func(); // <--- this expression here ... Would evaluate to: ... myStruct.func(myVar); ... So in other words, since there was no match for 'func()' in myStruct, it checked for 'static func(myStruct)' and used that. The basic rules we use in Lux is that any call on a structure, class, interface, or aspect which finds no match, first resolves to a static call with the instance as the first argument, and if /that/ doesn't match, then it throws an Exception. Is it possible to have something similar in D? And if there could be a way to implement the ColdC idea as well, that would be great for some of the libs, such as std.string, IMHO. - Chris S. - Invironz
Feb 16 2004
Random thought... could the static passbacks for primitive types be handled through a new use of keyword static? Ie: ... static(char[]) left(char[] foo, int len) { // ... } ... Which would instruct the compiler to make the following transformation: "abc".left(123) --> left("abc", 123) We could also have toString done thie way.. such as ' static(int) toString(int) { ... } ' to allow 123.toString() to work. And the static() construct could take multiple types, and maybe even be made generic somehow. - Chris S. - Invironz
Feb 16 2004
new myStruct { myVar; } myVar.func(); // <--- this expression here ... Would evaluate to: ... myStruct.func(myVar); ...To me, this looks like a hack to make a static function that shouldn't have been static in the first place, be used non-statically anyway. Conceptually, $string.left (your notation) _needs_ an object, it is defined in terms of an existing string (the leftmost n characters of string s, right?) Therefore, the mistake is to declare $string.left as being a static function, and the solution is to remove the 'static' keyword (and the string parameter) There might be other uses for this "de-staticalizing" in the context of aspects or interfaces but in case of the $string.left example it seems wrong
Feb 16 2004
To me, this looks like a hack to make a static function that shouldn't have been static in the first place, be used non-statically anyway.Yeah, I don't seem to see the point either. If the syntax was changed to somthing like static string string.left(string str, int num) then it could be used to add members to a class. Don't know how workable this is though. Sam
Feb 16 2004
First off, bear in mind the examples I gave were from two other platforms, both pretty not-D-like... in fact, to be all technical, my ColdC example: "some text".left(72); would actually transform to: toobj('string).left("some text", 72); since ColdC uses the symbol-name of the data type to go looking for the appropriate method to call, aka, it calls the method on an object with the same name as the data type, or else throws an error if there is no such object. The basic idea, though, is to attach type-specific libraries to their boxes... in a string library, for instance, one could define a string class, and then define the library methods (justification, searches, etc) as static but access them from the instance, passing the instance automatically as the first argument. Which isn't that big a deal by itself, except I'd like to see a way of attaching them to primitives as well. I'll admit, its sort of a sugar. But I kind of like: "some text".left(72) a little better than: String.left("some text", 72) although its certainly not a big deal by itself if the string is already in a variable, a la: String var = new String("some text"); var.left(72); Jeroen van Bemmel wrote:new myStruct { myVar; } myVar.func(); // <--- this expression here ... Would evaluate to: ... myStruct.func(myVar); ...To me, this looks like a hack to make a static function that shouldn't have been static in the first place, be used non-statically anyway. Conceptually, $string.left (your notation) _needs_ an object, it is defined in terms of an existing string (the leftmost n characters of string s, right?) Therefore, the mistake is to declare $string.left as being a static function, and the solution is to remove the 'static' keyword (and the string parameter) There might be other uses for this "de-staticalizing" in the context of aspects or interfaces but in case of the $string.left example it seems wrong
Feb 17 2004
I'll admit, its sort of a sugar. But I kind of like: "some text".left(72) a little better than: String.left("some text", 72)me too, a solution here would be to treat "some text" as an (implicit) string object itself. So instead of doing toobj('string).left("some text", 72); why not do toobj("some text").left(72) ?
Feb 17 2004
Question is, how in D would one tell the compiler to check against a particular class/module for calls on primitives. In ColdC its not a problem, because its taken care of by the driver program (usually the 'Genesis' driver written by Brandon Gillespie), so it happens automatically... in a fully native platform like D we'd need a way of drawing the compiler's attention. I personally would like something like: static(char[]) char[] left(char[] text, int len) { ... } or like: pass(char[]) char[] left(char[] text, int len) { ... } I suppose they could be attached to a class as a whole, and they'd probably be {}'able like most of the attributes. Wonder if this would really be useful... maybe I ought to make an actual proposal... :) - Chris S. - Invironz Jeroen van Bemmel wrote:I'll admit, its sort of a sugar. But I kind of like: "some text".left(72) a little better than: String.left("some text", 72)me too, a solution here would be to treat "some text" as an (implicit) string object itself. So instead of doing toobj('string).left("some text", 72); why not do toobj("some text").left(72) ?
Feb 17 2004
"Chris Sauls" <ibisbasenji yahoo.com> wrote in message news:c0tr0c$1jn4$1 digitaldaemon.com...Question is, how in D would one tell the compiler to check against a particular class/module for calls on primitives.If you mean: how would the compiler know that "some text" should be implicitly considered as a member of class 'string', my answer would be: by convention The number of different literal tokens is very limited, ie ".." -> string 'a' -> char 1234 -> integer 12.35 -> float true -> boolean so that would not be such a big deal. In other words, hardcode this into the compiler. One might argue that this is not very generic and rather arbitrary; my reply would be that you cannot have everything flexible, since then you don't have anything solid. I once tried to design a language where everything was flexible, including the definition of lexical tokens. I ended up needing conventions for this ...In ColdC its not a problem, because its taken care of by the driver program (usually the 'Genesis' driver written by Brandon Gillespie), so it happens automatically... in a fully native platform like D we'd need a way of drawing the compiler's attention.
Feb 17 2004
Chris Sauls wrote:The basic idea, though, is to attach type-specific libraries to their boxes... in a string library, for instance, one could define a string class, and then define the library methods (justification, searches, etc) as static but access them from the instance, passing the instance automatically as the first argument. Which isn't that big a deal by itself, except I'd like to see a way of attaching them to primitives as well.Isn't this how member functions work anyway? They're really just a static virtual function with an implicit parameter: the "this" reference.I'll admit, its sort of a sugar. But I kind of like: "some text".left(72)But if you already _have_ a String class, then why define that function like static String left(String s,int i) rather than String left(int i) ? It seems that the only case it actually helps is with primitives, in which case the suitable functions could be added to the language, or to a "magic" part of phobos. Sam
Feb 17 2004