The goodness of goodness

[Bernd Gehrmann]

On Tue, 15 May 2001, Richard Dale wrote:
> > which refers to version 16. But this not a real solution. Parts may
> > also have different ui.rc files in different versions, so having 
> > some versions installed at the time would require to give them different
> > KInstance names, so they can find their resources.
> That sounds interesting, I must go and find out about how KInstance names
> work.

They are basically the directory under KDEDIR/share where a part
stores it resources. The problem is that the name of the
KInstance instance (i.e. an instance of the KInstance class 
[naming a class 'instance' can be confusing, eh?) is usually 
given at compile time, so I think for giving different versions
different resource directories you would have to adjust the
source when compiling.

> > I'm still confused about this 'override' feature. How does the Objective C
> > runtime handle dynamically loaded code? 
> A category is equivalent, in static programming terms, to subclassing without
> adding instance variables, but you can do it on the fly. So you can add methods
> to an existing class at runtime, and instances already running will pick the new
> behaviour up. Another use is where you redefine an existing method in a
> category, and replace the old one at runtime, to fix a bug or make an
> enhancement to a class (without needing the original source).

I should find someone sponsoring me a nice G4 cube for making some
experiments myself :-)
 
> I would tend to call a KDevelop java support class 'Java<rest of classname>'
> even if I could give it the same name as an existing C++ support class via
> namespaces. Is it a good idea for each plugin to declare its own namespace?  I

Hmm, I don't even know. In principle parts only need to export a
single symbol, namely the init_foo which returns a factory. So
there would be no problem. OTOH, it doesn't look like kde doesn't
use ld's feature to restrict exporting symbol tables...

Bernd.


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«