www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Walter: extend existing classes with new methods?

reply Marcio <mqmnews321 sglebs.com> writes:
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
Aug 27 2006
parent reply Bill Baxter <wbaxter gmail.com> writes:
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
Aug 30 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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).
Aug 31 2006
parent reply Bill Baxter <wbaxter gmail.com> writes:
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
Aug 31 2006
parent Marcio <mqmnews321 sglebs.com> writes:
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
Sep 03 2006
prev sibling next sibling parent Fredrik Olsson <peylow gmail.com> writes:
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.

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.
 

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
Aug 31 2006
prev sibling parent reply Marcio <mqmnews321 sglebs.com> writes:
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
Sep 03 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
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
Sep 03 2006
parent reply Marcio <mqmnews321 sglebs.com> writes:
    If I understood your argument correctly, you are saying that you 
can't have a compiler compile code for a class if the source is split 
across multiple source files? Because, after all, that's all we're 
talking about here. Class foo has some code in foo.d, some code in bar.d 
(it added methods to foo) and so on.

   Well, if we are going to use that argument, we might as well move 
back in time to the old days of Turbo Pascal 3.0. If you wanted to use a 
procedure Foo, it had to have already appeared in the source. So, for 
cases like recursive descendent parsers or recursive tree traversal you 
had to declare the function, and later have it appear again, with the 
body itself. This allowed you to have mutually recursive procedures. 
This was because the compiler couldn't do any look-ahead or 2-pass. Way 
to go, put the burden on the developer because of a compiler limitation. 
Fina when you have 64KB of RAM like the MSX I guess...

   I think compilers should serve developers, not the other way around.

   By the way, the reason Java source has so many "instanceof" is 
because it doesn't allow this type of extension. If the language allows 
extensions, you can easily code things with polymorphism by adding say 
isFoo to Object (return false) and overriding it in your Foo class 
(return true). No need for instanceof. You want to know if the object 
isFoo? Damn, just ask it. Use OO. This is a very common pattern of 
coding in systems like Smalltalk.

   I honestly believe that people who never used this feature in a 
language can't really grasp what they are missing. That's too bad. Just 
look at http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt  when he 
talks about frameworks, the need to extend base classes. To me that's a 
clear example of a problem that can be solved by this mechanism.

marcio


Kirk McDonald 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.

 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.

Sep 04 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Marcio wrote:
 
    If I understood your argument correctly, you are saying that you 
 can't have a compiler compile code for a class if the source is split 
 across multiple source files? Because, after all, that's all we're 
 talking about here. Class foo has some code in foo.d, some code in bar.d 
 (it added methods to foo) and so on.
 
   Well, if we are going to use that argument, we might as well move back 
 in time to the old days of Turbo Pascal 3.0. If you wanted to use a 
 procedure Foo, it had to have already appeared in the source. So, for 
 cases like recursive descendent parsers or recursive tree traversal you 
 had to declare the function, and later have it appear again, with the 
 body itself. This allowed you to have mutually recursive procedures. 
 This was because the compiler couldn't do any look-ahead or 2-pass. Way 
 to go, put the burden on the developer because of a compiler limitation. 
 Fina when you have 64KB of RAM like the MSX I guess...
 
   I think compilers should serve developers, not the other way around.
 
   By the way, the reason Java source has so many "instanceof" is because 
 it doesn't allow this type of extension. If the language allows 
 extensions, you can easily code things with polymorphism by adding say 
 isFoo to Object (return false) and overriding it in your Foo class 
 (return true). No need for instanceof. You want to know if the object 
 isFoo? Damn, just ask it. Use OO. This is a very common pattern of 
 coding in systems like Smalltalk.

Now I know I misunderstood you. Extension methods I was thinking of are like the ones in C#3.0 and they can only be static. I don't see how adding a nonstatic method should work. Static extension methods might not be as useful as nonstatic ones but it can be a nice feature.
Sep 04 2006
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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).
Sep 03 2006
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Sep 04 2006
parent reply Marcio <mqmnews321 sglebs.com> writes:
Chris Nicholson-Sauls wrote:
 Okay... maybe I'm missing something here?  

Yes, you are.
 I was pretty sure we already 
 do have this, in a little OOP concept called inheritance?  

Nope.
 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?
 

You want String to have a new method, say asURL. Or findReplace. Or whatever. Not a new String subclass. You want to add functionality to String. You want all objects to understand dumpOn (aStream). Say you are writing a persistent framework. You need to add methods to Object. If you ever used Smalltalk, you'd know what I mean. marcio
Sep 04 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Marcio wrote:
 Chris Nicholson-Sauls wrote:
 Okay... maybe I'm missing something here?  

Yes, you are.
 I was pretty sure we already do have this, in a little OOP concept 
 called inheritance?  

Nope. > 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?

You want String to have a new method, say asURL. Or findReplace. Or whatever. Not a new String subclass. You want to add functionality to String. You want all objects to understand dumpOn (aStream). Say you are writing a persistent framework. You need to add methods to Object. If you ever used Smalltalk, you'd know what I mean. marcio

A somewhat related concept is here (very hackish C++, but the concept translates easily to D): http://www.codeproject.com/cpp/retrofitpolymorphism2.asp The idea being that you make a new interface, IDumpableObject, and define how to cast any Object into an IDumpableObject. You never actually add members to Object. Instead, you make everything look as though it derived from IDumpableObject, and then your framework uses IDumpableObject everywhere. I think it would be possible to get most of this behaviour even from D .166, with a bit of hackery.
Sep 06 2006
parent reply Marcio <mqmnews123 sglebs.com> writes:
Don Clugston wrote:
 A somewhat related concept is here (very hackish C++, but the concept 
 translates easily to D):
 
 http://www.codeproject.com/cpp/retrofitpolymorphism2.asp
 
 The idea being that you make a new interface, IDumpableObject,
 and define how to cast any Object into an IDumpableObject.
 
 You never actually add members to Object. Instead, you make everything 
 look as though it derived from IDumpableObject, and then your framework 
 uses IDumpableObject everywhere.

If you don't need to add code to the class, this works well in statically typed languages. You are basically trying to overcome the limitation of static typing where a 3rd-party class already declared the interfaces it implements, so you are stuck. It's a closed module now. If another class declares it uses another interface that looks just the same, the 2 are still incompatible because they implement 2 separate interfaces, even if they are really the same in terms of functionality. This is an issue even more now with web services, and Erik Meijer's talk mentions this issue (it seems that VB will be really flexible here) http://channel9.msdn.com/ShowPost.aspx?PostID=223865#223865 But note that there are many cases when you need to add code as well. http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt gives one example. marcio
Sep 06 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Marcio wrote:
 Don Clugston wrote:
 A somewhat related concept is here (very hackish C++, but the concept 
 translates easily to D):

 http://www.codeproject.com/cpp/retrofitpolymorphism2.asp

 The idea being that you make a new interface, IDumpableObject,
 and define how to cast any Object into an IDumpableObject.

 You never actually add members to Object. Instead, you make everything 
 look as though it derived from IDumpableObject, and then your 
 framework uses IDumpableObject everywhere.

If you don't need to add code to the class, this works well in statically typed languages. You are basically trying to overcome the limitation of static typing where a 3rd-party class already declared the interfaces it implements, so you are stuck.

It's much more than that. It's about extending functionality to a class without polluting the base class. It is not just about renaming interfaces (although in the link I showed, it does) -- it can be used to add code as well (you just need to populate the interface at compile time). IMHO, this kind of interface arises more frequently than interface inheritance does.
It's a closed module now. If
 another class declares it uses another interface that looks just the 
 same, the 2 are still incompatible because they implement 2 separate 
 interfaces, even if they are really the same in terms of functionality. 
 This is an issue even more now with web services, and Erik Meijer's talk 
 mentions this issue (it seems that VB will be really flexible here) 
 http://channel9.msdn.com/ShowPost.aspx?PostID=223865#223865
 
 
     But note that there are many cases when you need to add code as 
 well. http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt gives one 
 example.

Yes, but that example would work perfectly well with static typing.
Sep 07 2006
parent reply Marcio <mqmnews123 sglebs.com> writes:
Don Clugston wrote:
 It's much more than that. It's about extending functionality to a class 
 without polluting the base class. It is not just about renaming 
 interfaces (although in the link I showed, it does) -- it can be used to 
 add code as well (you just need to populate the interface at compile 
 time). 

Ah, ok. Interesting. So, do you mind showing me how I can have the scenario where I can have String now understand a new method, say "asURL", which I can use from my new component? It should return a URL object or null if it is invalid. It is a silly scenario, but adding functionality to String is useful. Java 1.5 just added extra API to String, for example. Code that uses this API won't compile in Java 1.4. So, if you wanted to provide a compatibility layer, you could have it adding this API to String. Can that be done with the approach you sent? It wasn't clear to me that it could. But if it can, I am curious... Another scenario I would be interested to see working is how I can have Object return false to "isWidget" but a Widget class return true. This allows you to get rid of instanceof" checks and rely purely on polymorphism. In my mental model you want to add the isWidget method to Object. You say you can add code to the interface. However, Object and Widget would have 2 opposite implementations, so I am not sure how adding code to the 1 interface would help? Please help me understand that C++ hack - I am not a C++ person :-) Thanks, marcio
Sep 07 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Marcio wrote:
 Don Clugston wrote:
 It's much more than that. It's about extending functionality to a 
 class without polluting the base class. It is not just about renaming 
 interfaces (although in the link I showed, it does) -- it can be used 
 to add code as well (you just need to populate the interface at 
 compile time). 

Ah, ok. Interesting. So, do you mind showing me how I can have the scenario where I can have String now understand a new method, say "asURL", which I can use from my new component? It should return a URL object or null if it is invalid. It is a silly scenario, but adding functionality to String is useful.

In C++ I used my "fastdelegate" template (on CodeProject) to hack delegates into C++. This lets you do something vaguely like: -------------- using namespace fastdelegate; class StringWithURL { String &baseClass; // only necessary when you add new functions public: // The normal String functions. Actually they're delegates, but // they behave exactly like functions. FastDelegate<void ()> makeUpper; FastDelegate<String (String)> concatenate; // etc // Constructor, templated. Note that you can specialize it to behave differently for specific classes. template<class T> StringWithURL(T &a) : baseClass(a), toUpper(MakeDelegate(a, &T::toUpper)), // etc {} // implicit conversion to String. String & operator String () { return baseClass; } URL asURL() { if (baseClass[0]!='h') return 0; // must start with "http" else return new URL("www.smurfsRus.com"); } }; Then, you can write void myfunc(StringWithURL s) {} and it will accept anything derived from String. It's unnecessarily inefficient, though -- not as lightweight as it should be. Also things like delete don't work (they don't delete the base class). What we're doing is using delegates to make a fake vtable. Now, with interfaces, gc, delegates, static if, and is() expressions, D could do much better than this. Only problem is, there's no implicit conversion. Java 1.5 just added extra API to
 String, for example. Code that uses this API won't compile in Java 1.4. 
 So, if you wanted to provide a compatibility layer, you could have it 
 adding this API to String. Can that be done with the approach you sent? 
 It wasn't clear to me that it could. But if it can, I am curious...
 
     Another scenario I would be interested to see working is how I can 
 have Object return false to "isWidget" but a Widget class return true.

Yeah, that's very common. Some cases can be done very easily: template (X) void myfunc(X x) { static if ( is( x.isWidget ) ) { ... } } but if you don't know the type at compile time, you're stuck.
 This allows you to get rid of
 instanceof" checks and rely purely on polymorphism. In my mental model 
 you want to add the isWidget method to Object. You say you can add code 
 to the interface. However, Object and Widget would have 2 opposite 
 implementations, so I am not sure how adding code to the 1 interface 
 would help? Please help me understand that C++ hack - I am not a C++ 
 person :-)

It's very imperfect, but might generate ideas.
Sep 08 2006
parent reply Marcio <mqmnews123 sglebs.com> writes:
 In C++ I used my "fastdelegate" template (on CodeProject) to hack 
 delegates into C++. This lets you do something vaguely like:
 

 Then, you can write
 
 void myfunc(StringWithURL s) {}
 
 and it will accept anything derived from String. 

I want existing String objects, belonging to class String, to be able to understand asURL. Not a new class. Unless I misunderstood your explanation. My understanding is that "derived from String" does not include String.
 It's unnecessarily 
 inefficient, though -- not as lightweight as it should be.
 Also things like delete don't work (they don't delete the base class).

If you could just add methods to the class, these methods would behave the same as the ones defined in the class itself. No speed penalty. The feature request is quite simple actually. Allow a class C to be defined not just in 1 file, but in N files. From many fragments. A class is never a closed module in this case.
     Another scenario I would be interested to see working is how I can 
 have Object return false to "isWidget" but a Widget class return true.

Yeah, that's very common. Some cases can be done very easily: template (X) void myfunc(X x) { static if ( is( x.isWidget ) ) { ... } } but if you don't know the type at compile time, you're stuck.

Yeah, I'd rather just rely on polymorphism. Which can be done if the source of a class can be split across multiple files. These extra methods become regular methods, not second class.
 It's very imperfect, but might generate ideas.

Indeed. But in my mind, a compiler can do lots of interesting things after compiling the full program. These extension methods would not be hard. There are also all sorts of polymorphism optimizations that can be done. SmartEiffel (used to be SmallEiffel) does all sorts of virtual call optimizations because it can do a global analysis of thr code (something Java can't do, for example, because of thr dynamic class loading etc). Sometimes their compiler eliminates 98% of virtual calls. It generates amazingly fast code. Anyway, just to say that if you are compiling a program to generate an EXE, with no fancy dynamic loading etc, it should be possible to do these global analysis and therefore also allow methods to be added from different places. Like extending a framework by adding methods to base classes so that all subclasses now receive the extra behavior. And that includes Object itself. In dynamic languages, it is a no-brainer of course. Anyway, I wish D had this. It's a powerful mechanism to have. But since Walter did not reply at all, I guess he does not like the idea. Oh well... marcio
Sep 08 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Marcio wrote:

   Anyway, I wish D had this. It's a powerful mechanism to have. But
 since Walter did not reply at all, I guess he does not like the idea. Oh
 well...

That certainly is the wrong conclusion to make based on those facts ... Walter very seldom reply to new suggestions, and especially now as he is concentrating on bug fixes, however good the suggestion might be. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Sep 08 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Marcio wrote:
 In C++ I used my "fastdelegate" template (on CodeProject) to hack 
 delegates into C++. This lets you do something vaguely like:

 Then, you can write

 void myfunc(StringWithURL s) {}

 and it will accept anything derived from String. 

I want existing String objects, belonging to class String, to be able to understand asURL. Not a new class. Unless I misunderstood your explanation. My understanding is that "derived from String" does not include String.

Sorry, my wording was poor. Anything implicitly convertible to String will be implicitly convertible to StringWithURL. This obviously includes String itself.
 It's unnecessarily inefficient, though -- not as lightweight as it 
 should be.
 Also things like delete don't work (they don't delete the base class).

If you could just add methods to the class, these methods would behave the same as the ones defined in the class itself. No speed penalty.

Yes. That was a limitation of C++ templates, I think you could do better in D with the same idea. With my technique it would not be possible to add data members, though.
   The feature request is quite simple actually. Allow a class C to be 
 defined not just in 1 file, but in N files. From many fragments. A class 
 is never a closed module in this case.

Simple to request, complicated to implement I would guess. Something defined in a DLL surely has to be a closed module?
     Another scenario I would be interested to see working is how I 
 can have Object return false to "isWidget" but a Widget class return 
 true.

Yeah, that's very common. Some cases can be done very easily: template (X) void myfunc(X x) { static if ( is( x.isWidget ) ) { ... } } but if you don't know the type at compile time, you're stuck.

source of a class can be split across multiple files. These extra methods become regular methods, not second class.
 It's very imperfect, but might generate ideas.

Indeed. But in my mind, a compiler can do lots of interesting things after compiling the full program. These extension methods would not be hard. There are also all sorts of polymorphism optimizations that can be done. SmartEiffel (used to be SmallEiffel) does all sorts of virtual call optimizations because it can do a global analysis of thr code (something Java can't do, for example, because of thr dynamic class loading etc). Sometimes their compiler eliminates 98% of virtual calls. It generates amazingly fast code.

I believe D is designed to allow those optimisations.
   Anyway, just to say that if you are compiling a program to generate an 
 EXE, with no fancy dynamic loading etc, it should be possible to do 
 these global analysis and therefore also allow methods to be added from 
 different places. Like extending a framework by adding methods to base 
 classes so that all subclasses now receive the extra behavior. And that 
 includes Object itself.

I'd rather do that stuff with templates. If mixins were a little more powerful, you could use them to add the extra functionality to base classes. If you look at the example in the gaming article, it's clear that the designer of the framework *knows* where the extra functionality is going to be required. The problem is that the language doesn't give a nice way of expressing it.
Sep 11 2006
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
Sorry to drag this up again, but I was out of town for a while.

Marcio wrote:
   You want String to have a new method, say asURL. Or findReplace. Or 
 whatever. Not a new String subclass. You want to add functionality to 
 String.
 
   You want all objects to understand dumpOn (aStream). Say you are 
 writing a persistent framework. You need to add methods to Object.

The thing that I don't get about this is what happens if code A and code B both decide to add an 'asURL' method to String? Or 'dumpOn' to Object? With a function [e.g. asURL(aString), dumpOn(obj,stream)] these things can be disambiguated by using fully qualified names [myModule.asURL, yourModule.asURL], but if you go and make it a method on the base class [String.asURL()], you're effectively putting in the namespace of that class, right? And so you're suceptible to name clashes with anyone who wants to add methods to the same class. Do you make it so that the lookup is done local to the calling module? So that if module B adds a method to String, only module B can see that method? I don't see how that can work implementation-wise, though. How will I know to use that table instead of the default one when handed some arbitrary pointer to an object that may or may not be derived from String? -- without adding a bunch of extra explicit type checks, I mean. It's a very interesting idea. I guess I still just don't see how it can work in a statically typed language where dispatch is done with vtable lookup. --bb
Sep 21 2006