"Ary Borenszweig" wrote
> Steven Schveighoffer wrote:
>> "Ary Borenszweig" wrote
>>> Andrei Alexandrescu escribió:
>>>> dsimcha wrote:
>>>>> I know that, in std.traits, there's a template that spits out all base
>>>>> classes
>>>>> for a given class.  Based on reading the source, it seems to work
>>>>> based on a
>>>>> rather interesting use case for is expressions.  Is there any
>>>>> equivalent way
>>>>> to do the opposite:  For any given position in a class hierarchy, to
>>>>> get a
>>>>> tuple of all possible descendants?
>>>> That's not possible in general because in D the derived classes form an open set. I guess it could be done at runtime via reflection (not implemented afaik), but not at compile time.
>>> But for a given set of modules, the hierarchy is finite and known.
>>
>> Not at compile time, only at link time.  You can't compile code at link time.
>
> I still don't understand why you can't do this at compile time, assuming you have the source code for everything that you'll link into your executable.

Let's say this feature theoretically existed.  Here's an example usage:

class X
{
   Tuple!(???) getAllDerivedTypes() { return std.getAllDerivedTypes!(X)();}
}

If you compile this module like:

dmd -c X.d;

At this point, how does the compiler know all the modules that will derive from X?

D's compile-time reflection is generally limited to what is at or below a certain point in the hierarchy, not what has derived from it.

If you wanted to do something at runtime, that is possible, you might even be able to do this today by looking at the global TypeInfo array.

But you certainly cannot get a tuple of the derived classes at compile-time.

>
> How is a class hierarchy different in D than in Java? Eclipse JDT's has a type hierarchy feature, and Bruno was going to implement it in Mrnmhrm, all based on what's defined in the modules (you can say, compilte-time). What's the problem?

Java has runtime reflection.  D does not.  You have to implement runtime reflection on top of compile time reflection (or so says Walter).

There should be no problem if you want the information at runtime.  But a Tuple is a compile-time entity.  You can probably get the TypeInfos of the classes, but not really be able to do much, since D's runtime reflection capabilities are limited.

-Steve

Steven Schveighoffer wrote:
> "Ary Borenszweig" wrote
>> Steven Schveighoffer wrote:
>>> "Ary Borenszweig" wrote
>>>> Andrei Alexandrescu escribió:
>>>>> dsimcha wrote:
>>>>>> I know that, in std.traits, there's a template that spits out all base classes
>>>>>> for a given class.  Based on reading the source, it seems to work based on a
>>>>>> rather interesting use case for is expressions.  Is there any equivalent way
>>>>>> to do the opposite:  For any given position in a class hierarchy, to get a
>>>>>> tuple of all possible descendants?
>>>>> That's not possible in general because in D the derived classes form an open set. I guess it could be done at runtime via reflection (not implemented afaik), but not at compile time.
>>>> But for a given set of modules, the hierarchy is finite and known.
>>> Not at compile time, only at link time.  You can't compile code at link time.
>> I still don't understand why you can't do this at compile time, assuming you have the source code for everything that you'll link into your executable.
> 
> Let's say this feature theoretically existed.  Here's an example usage:
> 
> class X
> {
>    Tuple!(???) getAllDerivedTypes() { return std.getAllDerivedTypes!(X)();}
> }
> 
> If you compile this module like:
> 
> dmd -c X.d;
> 
> At this point, how does the compiler know all the modules that will derive from X?

Well explained.

> D's compile-time reflection is generally limited to what is at or below a certain point in the hierarchy, not what has derived from it.

s/below/above/

> If you wanted to do something at runtime, that is possible, you might even be able to do this today by looking at the global TypeInfo array.
> 
> But you certainly cannot get a tuple of the derived classes at compile-time.
> 
>> How is a class hierarchy different in D than in Java? Eclipse JDT's has a type hierarchy feature, and Bruno was going to implement it in Mrnmhrm, all based on what's defined in the modules (you can say, compilte-time). What's the problem?
> 
> Java has runtime reflection.  D does not.  You have to implement runtime reflection on top of compile time reflection (or so says Walter).

I said so. All derived classes is, however, a case of runtime-available
information that's not there during compilation.

Anyhow, there's a start with the function static Object.factory(string).
You give it a string, it gives you a newly-instanced object. So the
information is there, it just needs exposing.


Andrei

Andrei Alexandrescu wrote:
> 
> Anyhow, there's a start with the function static Object.factory(string).
> You give it a string, it gives you a newly-instanced object. So the
> information is there, it just needs exposing.

Much of it is even exposed, just not in a convenient manner.  A list of classes is available via ModuleInfo, and ClassInfo provides a means of finding the ClassInfo instance of a class by name.  From there it should be possible to obtain a list of parent classes, and so one could build a hierarchy graph with some work.


Sean

"Sean Kelly" wrote
> Andrei Alexandrescu wrote:
>>
>> Anyhow, there's a start with the function static Object.factory(string). You give it a string, it gives you a newly-instanced object. So the information is there, it just needs exposing.
>
> Much of it is even exposed, just not in a convenient manner.  A list of classes is available via ModuleInfo, and ClassInfo provides a means of finding the ClassInfo instance of a class by name.  From there it should be possible to obtain a list of parent classes, and so one could build a hierarchy graph with some work.

Sure, but what do you do with that graph ;)  Calling methods/ctors is not exactly easy with D currently.

-Steve

Reply to dsimcha,

> I know that, in std.traits, there's a template that spits out all base
> classes for a given class.  Based on reading the source, it seems to
> work based on a rather interesting use case for is expressions.  Is
> there any equivalent way to do the opposite:  For any given position
> in a class hierarchy, to get a tuple of all possible descendants?
> 

Via DLL/SO's, a derived class can be /written/ after the program that it will be used in is /compiled/. Because of that (and other less restrictive forms of that issue) The most general answer is; can't be done.

On Sat, Oct 18, 2008 at 6:20 AM, BCS <ao@pathlink.com> wrote:
> Reply to dsimcha,
>
>> I know that, in std.traits, there's a template that spits out all base classes for a given class.  Based on reading the source, it seems to work based on a rather interesting use case for is expressions.  Is there any equivalent way to do the opposite:  For any given position in a class hierarchy, to get a tuple of all possible descendants?
>>
>
> Via DLL/SO's, a derived class can be /written/ after the program that it will be used in is /compiled/. Because of that (and other less restrictive forms of that issue) The most general answer is; can't be done.

I wonder what Object.Factory does when you try to make a class from a DLL like that.

I'm guessing it doesn't work.

--bb

On Fri, Oct 17, 2008 at 5:34 PM, Bill Baxter <wbaxter@gmail.com> wrote:

> I wonder what Object.Factory does when you try to make a class from a DLL like that.
>
> I'm guessing it doesn't work.

I think you've guessed correctly.  DLLs, in general, are next to useless with D.

Reply to Bill,

> On Sat, Oct 18, 2008 at 6:20 AM, BCS <ao@pathlink.com> wrote:
> 
>> Reply to dsimcha,
>> 
>>> I know that, in std.traits, there's a template that spits out all
>>> base classes for a given class.  Based on reading the source, it
>>> seems to work based on a rather interesting use case for is
>>> expressions.  Is there any equivalent way to do the opposite:  For
>>> any given position in a class hierarchy, to get a tuple of all
>>> possible descendants?
>>> 
>> Via DLL/SO's, a derived class can be /written/ after the program that
>> it will be used in is /compiled/. Because of that (and other less
>> restrictive forms of that issue) The most general answer is; can't be
>> done.
>> 
> I wonder what Object.Factory does when you try to make a class from a
> DLL like that.
> 
> I'm guessing it doesn't work.
> 
> --bb
> 

it might work by hiding a static this function that registries the class, from that, when the dll lodes the class is registered.

Jarrett Billingsley wrote:
> On Fri, Oct 17, 2008 at 5:34 PM, Bill Baxter <wbaxter@gmail.com> wrote:
> 
>> I wonder what Object.Factory does when you try to make a class from a
>> DLL like that.
>>
>> I'm guessing it doesn't work.
> 
> I think you've guessed correctly.  DLLs, in general, are next to useless with D.

Rather:
A D app and a D DLL can only communicate via extern(C) interfaces. Or via COM. It's not great, but it isn't any worse than DLLs in C++.

Ary Borenszweig wrote:
> Steven Schveighoffer wrote:
>> "Ary Borenszweig" wrote
>>> Andrei Alexandrescu escribió:
>>>> dsimcha wrote:
>>>>> I know that, in std.traits, there's a template that spits out all base classes
>>>>> for a given class.  Based on reading the source, it seems to work based on a
>>>>> rather interesting use case for is expressions.  Is there any equivalent way
>>>>> to do the opposite:  For any given position in a class hierarchy, to get a
>>>>> tuple of all possible descendants?
>>>> That's not possible in general because in D the derived classes form an open set. I guess it could be done at runtime via reflection (not implemented afaik), but not at compile time.
>>> But for a given set of modules, the hierarchy is finite and known.
>>
>> Not at compile time, only at link time.  You can't compile code at link time.
> 
> I still don't understand why you can't do this at compile time, assuming you have the source code for everything that you'll link into your executable.
> 
> How is a class hierarchy different in D than in Java? Eclipse JDT's has a type hierarchy feature, and Bruno was going to implement it in Mrnmhrm, all based on what's defined in the modules (you can say, compilte-time). What's the problem?
> 

It would be possible for the compiler to determine subtypes, if, just like an IDE or build tool, the compiler had a well structured concept of a project (ie, a set of source folders, libraries, included modules, etc.).

But just because it is possible, doesn't mean it's desirable, and in fact, it isn't. It's senseless: Such code (ie, getting all derived types) would introduce an open-ended compile-time coupling, as a module using that functionality would depended on *every* other module of the project. And that makes such functionality compilable only in projects that compile into an executable (which is when the set of dependencies is finite). That is, you couldn't use that functionality in a library, which shows much of an inane idea it is. It's breaking an abstraction barrier.

Getting that information at *runtime* might be sensible, but I'm not seeing much usefulness in that.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D