Getting derived classes

[Bruno Medeiros]

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