The goodness of goodness

[Richard Dale]

On Mon, 14 May 2001, you wrote:
> On Mon, 14 May 2001, Richard Dale wrote:
> > > Hmm, aren't bundles just distiguished by their file name (i.e. directory
> > > name)? How do you distinguish different versions of them?
> > Yes, they were, but we gave them names like FooBar.17.bundle. I assume you
> > would have to include the goodness number in the real name of KPart library too,
> > but the 'KTrader/goodness as version number' gives you a level of indirection
> > away from that. Perhaps there could also be some sort of KTrader service to give
> > the the current version set of the app's KParts. 
> 
> One thing you can do is to install different versions of a part
> by using different library (i.e. .so) names. Then you can switch
> between them by copy different variants of the according .desktop
> to the service directory. For example, for the documentation tree, 
> you would have
> 
> [Desktop Entry]
> Type=Service
> Name=KDevDocTreeView
> ServiceTypes=KDevelop/Part
> X-KDE-Library=libkdevdoctreeview16
> 
> 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. A bundle is a directory, and so it can contain both libraries and
resources. If you could write a KTrader service which you could query about the
current versions of parts for a user/app, it wouldn't matter whether it got its
information from a relational database or from a desktop configuration file.

> > It was quite a powerful feature to always be able to revert to a previous set
> > of bundles if something went wrong with a new release. It meant that you
> > rarely had to release the entire app (Objective-C also allows you to override
> > and patch existing code at runtime with 'categories'). So for large, constantly
> > changing custom apps this was very useful.
> 
> 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).

>  Are methods defined in a plugin
> automatically globally 'visible'? Then you can probably not have
> different classes with the same name in different plugins. Since Objective
> C doesn't have namespaces, how do you avoid conflicts then? 
Yes, namespace support is probably the most important feature missing from
Objective-C, and consequently all classes are globally visible. You need to
avoid giving classes bland names such as 'Action' or 'Exception', and add a
unique prefix (cf 'K' or 'Q'), or whatever. Perhaps this would be a problem for
KDevelop plugins, more than it is for custom apps where you aren't expecting
third party contributions.

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
think namespaces come in to their own with large frameworks. KDevelop is
small enough that classname clashes probably wouldn't prove to be a problem in
practice. I think source files with identical names are more trouble - it
makes them harder to edit in KDevelop - even if they compile ok.

-- Richard


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