I have an idea that would add the 'syntax' of functions for simple types, structs ect.. Basicly the compiler could interpret

somestruct.someFunction(x,y,z);

as realy being the static function...

someFunction(inout somestruct,x,y,z);

i know this how OO works behind the scenes anyway but doing this would require very little effort and you could use it to add functions to simple types aswell. So you could do...

float x;
x.Sqrt();

would be prototyped as

void Sqrt(inout float x);

Isn't it already there? I thought it was, but now i browsed through the manual and didn't find it.

Anti-magic. :(

It would be also cool, for example, for struct methods to have definitions like:

MyStruct.MyMethod(int a, b) {/* do something*/}

which would be an equivalent of:

MyStruct__mangle__MyMethod(inout MySruct self, int a,b) {}

(I am used to call "self" what you call "this")

So that additional methods can be defined in further modules. For example, have separate units for sprites, effects, and such, all working on the same structs.

While such a feature would be safe for structs (simply 2 names would collide and produce a link error), if used for classes this needs a mechanism to resolve conflicts. For example, not to let the method work neither on ascendants, nor on descendants. One can come up with a less agressive system though.

-i.

chris wrote:
> I have an idea that would add the 'syntax' of functions for simple types,
> structs ect.. Basicly the compiler could interpret
> 
> somestruct.someFunction(x,y,z);
> 
> as realy being the static function...
> 
> someFunction(inout somestruct,x,y,z);
> 
> i know this how OO works behind the scenes anyway but doing this would
> require very little effort and you could use it to add functions to simple
> types aswell. So you could do...
> 
> float x;
> x.Sqrt();
> 
> would be prototyped as
> 
> void Sqrt(inout float x);
> 
> 

"chris" <kjbeak@yahoo.co.uk> writes:

> I have an idea that would add the 'syntax' of functions for simple types, structs ect.. Basicly the compiler could interpret
>
> somestruct.someFunction(x,y,z);
>
> as realy being the static function...
>
> someFunction(inout somestruct,x,y,z);

At least it would make it clear (to a C++/D/object-oriented language newbie) how non-dynamic member functions work.

Another use I can think of is to provide a default implementation, if there is no specialized method in the class that you want to change (yet):

// module1.d
class SomeWidget
{
  void init();
  int size_x;
  int size_y;

  // stuff
}

Now, suppose that you want to put a method resize() in SomeWidget, but you can't change the code because all changes must pass some QA procedure or something, or it's your client's code and you have no access to it.  Yet you expect it eventually to change.

Now if external methods were possible, we can work around the situation so that it looks like if you actually have the method inside SomeWidget:

// module2.d -- introduces an "external method", or external member // function

void SomeWidget.resize(inout SomeWidget this, int new_size_x, int
     new_size_y)
{
  this->size_x = new_size_x;
  this->size_y = new_size_y;
}

And then you can use SomeWidget as if it had that method:
// anothermodule.d
...
// this piece of code uses modules 1 and 2
void f(SomeWidget w)
{
  w.resize(150, 250);
}

Note that this doesn't add any functionality to the language, just syntactic sugar similar to function overloading.  Yeah, we know, "Syntactic sugar causes the cancer of semicolon", as goes the old pun by Dijkstra, but sometimes that sugar hits the spot.  Particularly in generic programming, where you could do something like, for the lack of a better example:

template TMathematicalStuff(T)
{
  T sum(Containers(T).List list) {
    T result = T.zero();
    for (x in list) {
      result += x;
    }
  }

  T multiply(Containers(T).List list) {
    T result = T.identity();
    for (x in list) {
      result *= x;
    }
  }
}

And then you could define external zero() and identity() methods for
those types which don't have one. If you like.

Of course, you could solve the problem by using template traits a la STL, which I find to be rather unelegant workaround.

One possible reason still to include external methods/functions would be possible introduction of multimethods, which would need the syntax

method(inout Class1 this1, inout Class2 this2, inout Class3 this3, ...);

anyway.  Or at least we would need some kind of uniform syntax for both method and function calls.  In CLOS, all kinds of operations -- functions, methods and multimethods, which are a special case of methods, are called with the same syntax: (operation-name arg1 arg2 arg3).  Of course, that's all dynamic and you can even add and redefine methods on the fly.  So we might not be wanting that.

(In the current case, all method calls could, for example, be translated to calls to a special method handler which looks up which method to call in some kind of table (IIRC, this approach has been taken by Cmm, which implements multimethods in C++).  Whenever a method is declared, it is added to this global table.)

I also thought of a funny syntax for multimethod calls (and even
declarations):

declaration:
(Object1, Object2).foo() {
  do something to object1 and object2;
}

call:
f()
{
  Object1 o1, Object2 o2;
  (o1, o2).foo();
}

This would seem to need tuples, though.

-Antti

at first I thought you wanted to expose the vtable too
obj.foo( bar ) is either obj_foo( obj, bar ) or obj.vtbl[obj_foo_index](
obj, bar )

but the idea of allowing a binding between a struct and a function;

lua has a nice syntax

obj.f( foo )  calls  obj_func( foo )
obj:f( foo ) calls   obj_func( obj, foo )

it might be nice to have

item.func( foo )  calls item.func( item, foo ) (func is a member of item) or
item.func( foo ) is func is static
item:func( foo )  calls func( item, foo ) (global func)

or even
item:obj.func( foo ) calls item.func( item, foo ) which is item.func( obj,
item, foo ) if func is a member func.

int add( int a, int b ) { return a+b; }
float add( float a, float b ) { return a+b; }
int x = 4, y = 6;
float fx = 1.0, fy = 7.8;
int z = x:add( y );  calls add( int, int )
float fz = fx:add( fy ); calls add( float, float )

Mike.

"chris" <kjbeak@yahoo.co.uk> wrote in message news:b0m43t$12m5$1@digitaldaemon.com...
> I have an idea that would add the 'syntax' of functions for simple types, structs ect.. Basicly the compiler could interpret
>
> somestruct.someFunction(x,y,z);
>
> as realy being the static function...
>
> someFunction(inout somestruct,x,y,z);
>
> i know this how OO works behind the scenes anyway but doing this would require very little effort and you could use it to add functions to simple types aswell. So you could do...
>
> float x;
> x.Sqrt();
>
> would be prototyped as
>
> void Sqrt(inout float x);
>