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

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
>

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

> 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

> 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

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

> 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) ?

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) ?

"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.

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