Walter,

   Do you plan to add the ability of adding methods to an existing class, from another module?

   This ties to the issues raised at http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt and the fact that some languages/systems have had this capability for years (Smalltalk, for example, and more recently Ruby) with very beneficial results.

   Thanks,

marcio

Marcio wrote:
> Walter,
> 
>    Do you plan to add the ability of adding methods to an existing class, from another module?
> 
>    This ties to the issues raised at http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt and the fact that some languages/systems have had this capability for years (Smalltalk, for example, and more recently Ruby) with very beneficial results.
> 

Smalltalk and Ruby are both dynamically typed languages.  D is statically typed -- that is the type of everything must be known at compile-time, and in particular what methods are present must be known.    AFIK, in D, like in C++, someobject.foo() either fails to compile, or it successully calls foo() at runtime.  There is no runtime check to see if the method exists or not before calling it.  What you're asking for is a really big fundamental change to what D is.

That said, it might be nice for some aspects of dynamic typing to be built in to the language.  From what I gather, that's one of the strengths of Objective-C, and what makes it a good language for writing GUIs.

So the first step would be to ask if D is going to gain support for basic dynamic method calling, THEN you can ask the question of whether or not adding dynamic methods to existing classes will be allowed.  But I guess if you have dynamic methods, then adding them to classes a la Smalltalk is really not a big deal.  Just a matter of putting another pointer in the class's dynamic method dict.

--bb

Bill Baxter wrote:
> Marcio wrote:
>> Walter,
>>
>>    Do you plan to add the ability of adding methods to an existing class, from another module?
>>
>>    This ties to the issues raised at http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt and the fact that some languages/systems have had this capability for years (Smalltalk, for example, and more recently Ruby) with very beneficial results.
>>
> 
> Smalltalk and Ruby are both dynamically typed languages.  D is statically typed -- that is the type of everything must be known at compile-time, and in particular what methods are present must be known.    AFIK, in D, like in C++, someobject.foo() either fails to compile, or it successully calls foo() at runtime.  There is no runtime check to see if the method exists or not before calling it.  What you're asking for is a really big fundamental change to what D is.

Not really. It is possible to extend a type without the need for runtime checks. C# 3.0 has that feature and it is called extension methods.
Here is a little example:

static class Program
{
    static void Main(string[] args)
    {
        string s = "Hello, world";
        s.Print();
    }

    static void Print(this string s)
    {
        Console.WriteLine(s);
    }
}

There is nothing dynamic about that.

Actually D already has a feature to add methods to array types and it is
only a natural extension to allow it for other types.
The only thing compiler would have to do is for every
a.method(b);
check if there exists method(a,b); and translate the code to that.

This is how it works for arrays and it is one inconsistency just begging  to be resolved (and not my removing this feature, but by extending it to other types).

Ivan Senji wrote:
> Bill Baxter wrote:
> 
>> Marcio wrote:
>>
>>> Walter,
>>>
>>>    Do you plan to add the ability of adding methods to an existing class, from another module?

>> compile, or it successully calls foo() at runtime.  There is no runtime check to see if the method exists or not before calling it.  What you're asking for is a really big fundamental change to what D is.
> 
> 
> Not really. It is possible to extend a type without the need for runtime checks. C# 3.0 has that feature and it is called extension methods.
> Here is a little example:
> 
> static class Program
> {
>     static void Main(string[] args)
>     {
>         string s = "Hello, world";
>         s.Print();
>     }
> 
>     static void Print(this string s)
>     {
>         Console.WriteLine(s);
>     }
> }
> 
> There is nothing dynamic about that.

I see. Is that little bit of syntactic sugar all the original poster was asking for?  And was that also all Tim Sweeny was asking for in the referenced presentation?   That means you can only add non-virtual methods, right?

--bb

Bill Baxter skrev:
> Marcio wrote:
>> Walter,
>>
>>    Do you plan to add the ability of adding methods to an existing class, from another module?
>>
>>    This ties to the issues raised at http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt and the fact that some languages/systems have had this capability for years (Smalltalk, for example, and more recently Ruby) with very beneficial results.
>>
> 
> Smalltalk and Ruby are both dynamically typed languages.  D is statically typed -- that is the type of everything must be known at compile-time, and in particular what methods are present must be known.    AFIK, in D, like in C++, someobject.foo() either fails to compile, or it successully calls foo() at runtime.  There is no runtime check to see if the method exists or not before calling it.  What you're asking for is a really big fundamental change to what D is.
> 
> That said, it might be nice for some aspects of dynamic typing to be built in to the language.  From what I gather, that's one of the strengths of Objective-C, and what makes it a good language for writing GUIs.
> 
In my humble opinion it rocks for writing GUIs. And key value coding, binding, and much more that reduce code for managing data and UI sync is not only less code, but in most cases no code at all, is as I can see it not practically possible without the dynamix message dispatch of Objective-C.

Now taking the whole step to Objective-C's lever would be a major task, but some run-time info, and possibility to at runtime change the virtual methods table would be nice.

I dunno how this could work internally, probably linked list of many virtual method tables for each class, allowing "extensions" to add batches of new methods.

// Original class
class Foo {
  void doStuff() { writeln("some stuff"); }
}

// New extension to class, added method will be added to all
// subclasses as well, only methods, not instance variables
// can be added.
class Foo (myextension) {
  void doOtherStuff(int a) { writeln("some other stuff:", a); }
}

// And in semi action.
Foo foo = new Foo();
if (foo.respondsTo(doOtherStuff(int)) {
  foo.doOtherStuff(42);
}


But looking at it, I think it would probably be much easier to just create Objective-D. The Objective part of Objective-C is very small, and could be made as a preprocessor for D to start with, that is exactly what was done for Objective-C once upon a time.

The idea of Objective-D intrigues me :). I love Objective-C, but hate the C parts...

> So the first step would be to ask if D is going to gain support for basic dynamic method calling, THEN you can ask the question of whether or not adding dynamic methods to existing classes will be allowed.  But I guess if you have dynamic methods, then adding them to classes a la Smalltalk is really not a big deal.  Just a matter of putting another pointer in the class's dynamic method dict.
> 
Unfortunately I do not think it is just that easy, what D, C++, Java, etc call OOP is really just syntactic sugar for having functions pointers in your structs, and then some fluff. It is not really encapsulation, as the caller always needs to know how to call each method, often by knowing the exact offset of a methods function pointer in a table.

What smalltalk (And Objective-C) does is taking that responsibility away from the caller, and instead let the called object be responsible for figuring out where the actual implementation is.

As methods could be added by from many modules, and in an undetermined order, there is no way to know the exact offset of your added function pointer. And you must take the Smalltalk route and actually look up the method for each call (And cache the lookups for speed).

As Objective-C does it this method call:
[myObject doSomething:42]; // Think of it as myObject.doSomething(42);
Is in reality rewritten as this:
objc_msgSend(myObject, "doSomething:", 42);
This is not quite true as the C-string "doSomething:" is also guaranteed to only exist once in each running process. But in short that is what it does.
The function objc_msgSend() will then look up the correct method implementation for the method specified in argument 2, for the class of the object instance specified in argument 1. If a implementation is found this is called with the rest of the arguments, if not the method for handling unimplemented methods is called, an error raised, or simply do nothing.

Hard to describe in text, maybe this one http://tinyurl.com/kojmm does a better job. But in the end it is just a few simple parts, that makes it very flexible and powerful. Claiming you know OOP unless you have seen the Smalltalk school, is like claiming you know of large cities without having seen New York ;).

// Fredrik Olsson

Bill Baxter wrote:
> Marcio wrote:
>> Walter,
>>
>>    Do you plan to add the ability of adding methods to an existing class, from another module?
>>
>>    This ties to the issues raised at http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt and the fact that some languages/systems have had this capability for years (Smalltalk, for example, and more recently Ruby) with very beneficial results.
>>
> 
> Smalltalk and Ruby are both dynamically typed languages.  D is statically typed -- that is the type of everything must be known at compile-time, and in particular what methods are present must be known.    AFIK, in D, like in C++, someobject.foo() either fails to compile, or it successully calls foo() at runtime.  There is no runtime check to see if the method exists or not before calling it.  What you're asking for is a really big fundamental change to what D is.


No, I am asking for extending at compile-time. Example: You provide me with a library written in D, with full source, and my app can add methods to some of your classes. Then I compile the full source.

This is quite doable, even in D.

Adding methods at runtime is an issue if you allow plugins to be loaded from DLLs. If these plugins can add not only classes but also add methods to existing classes, then you need the functionality at runtime.

I am being modest in my request. Compile-time extension would be straightforward and very useful.

marcio

Bill Baxter wrote:
[...]
>> There is nothing dynamic about that.
> 
> I see. Is that little bit of syntactic sugar all the original poster was asking for?  And was that also all Tim Sweeny was asking for in the referenced presentation?   That means you can only add non-virtual methods, right?
> 


  The syntax could be C# 3.0's syntax or another. I care more about the feature itself.

  I want to be able to add virtual, instance methods, of course.

marcio

Marcio wrote:
> Bill Baxter wrote:
> 
>> Marcio wrote:
>>
>>> Walter,
>>>
>>>    Do you plan to add the ability of adding methods to an existing class, from another module?
>>>
>>>    This ties to the issues raised at http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt and the fact that some languages/systems have had this capability for years (Smalltalk, for example, and more recently Ruby) with very beneficial results.
>>>
>>
>> Smalltalk and Ruby are both dynamically typed languages.  D is statically typed -- that is the type of everything must be known at compile-time, and in particular what methods are present must be known.    AFIK, in D, like in C++, someobject.foo() either fails to compile, or it successully calls foo() at runtime.  There is no runtime check to see if the method exists or not before calling it.  What you're asking for is a really big fundamental change to what D is.
> 
> 
> 
> No, I am asking for extending at compile-time. Example: You provide me with a library written in D, with full source, and my app can add methods to some of your classes. Then I compile the full source.
> 
> This is quite doable, even in D.
> 
> Adding methods at runtime is an issue if you allow plugins to be loaded from DLLs. If these plugins can add not only classes but also add methods to existing classes, then you need the functionality at runtime.
> 
> I am being modest in my request. Compile-time extension would be straightforward and very useful.
> 
> marcio

There is a problem with this.

class Foo { }

static if (is(typeof(Foo.bar))) {
    const bool has_bar = true;
} else {
    const bool has_bar = false;
}

/+ Add a 'bar' member to Foo somehow +/

Does Foo have a 'bar' member or not? In order for has_bar to be true, the compiler would need to arbitrarily look ahead and see if class Foo is changed later. This may well be impossible.

If instead you want has_bar to evaluate to false (because the 'bar' member hasn't been added at the time the static if is evaluated), then this leads to any number of problems. The class is suddenly different at different points in the code. In a statically-typed language, this is wrong, wrong, wrong.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Marcio wrote:
> No, I am asking for extending at compile-time. Example: You provide me with a library written in D, with full source, and my app can add methods to some of your classes. Then I compile the full source.
> 
> This is quite doable, even in D.

It sure is. The fact that it isn't implemented is just another inconsistency in the language. I would even go so far and say it is a d1.0blocker (as all inconsistencies are).

Ivan Senji wrote:
> Marcio wrote:
> 
>> No, I am asking for extending at compile-time. Example: You provide me with a library written in D, with full source, and my app can add methods to some of your classes. Then I compile the full source.
>>
>> This is quite doable, even in D.
> 
> 
> It sure is. The fact that it isn't implemented is just another inconsistency in the language. I would even go so far and say it is a d1.0blocker (as all inconsistencies are).
> 

Okay... maybe I'm missing something here?  I was pretty sure we already do have this, in a little OOP concept called inheritance?  Given a library defining 'class Foo', if I need custom behavior, I simply define a 'class MyFoo:Foo' and voila!

Or is there some deeper concept that I'm overlooking entirely?

-- Chris Nicholson-Sauls