Fwd: Bug#27716: see function under container file in project treeview

[Richard Dale]

On Sun, 01 Jul 2001, Bernd Gehrmann wrote:
> On Sat, 30 Jun 2001, Richard Dale wrote:
> 
> > On Fri, 29 Jun 2001, jbb wrote:
> > > Also is there differences in the class view between java and c++ and python 
> > > and other class languages? I say there was, but I'm a bit limited on the 
> > > language knowledge. Hmmmm....
> > Java has 'package' access, as well as 'private', 'protected' and 'public' -
> > there is no icon to display this, nor an attribute type in the C++ class parser
> > interface for holding that (currently 'package' is held as 'protected' I
> > think)
> Feel free to extend the class store to support that. BTW, what about a
> little api cleanup? 
I'll add 'package' visiblity - it should be a matter of taking an existing
visibility icon and changing the colour a bit.

> Apparently you have added accessors with non-standard
> names in order to avoid breaking existing code, but IMO renaming the
> variables instead would look more consistent.
Yes, I'll try and tidy the accessor names up - I think the instance variables
should be given names with a preceeding underscore like '_foobar' accessed by
method foobar(), and never directly. 

Also, I needed to subclass KDevLanguageSupport like this (see below) to change
the way it uses subclassing the virtual methods addClass(), addMethod() and
addAttribute(), and to use signals instead - more flexible, and easier to
interface to other languages. I added instance variables to hold the
'features' and 'fileFilters' attributes, rather than hard coding them as the
return result of a method - easier to interface to other languages, and easier
to debug. Would it be a good idea to change KDevLanguageSupport to work like
this, and move this code up to that class?

class KDevLanguageSupportJBridge : public KDevLanguageSupport
{
	Q_OBJECT

public:
	KDevLanguageSupportJBridge(KDevApi* api, QObject* parent, const char* name)
	: KDevLanguageSupport(api, parent, name), _features(Features(0)), _fileFilters("*")
	{
	}
	~KDevLanguageSupportJBridge() {}

	KDevLanguageSupport::Features features();
	void setFeatures(KDevLanguageSupport::Features features);

	QStringList fileFilters();
	void setFileFilters(QStringList fileFilters);

public slots:
	void updatedJavaSourceInfo();

signals:
	void addClass();
	void addMethod(const QString &);
	void addAttribute(const QString &);

private:
	KDevLanguageSupport::Features	_features;
	QStringList _fileFilters;

};
  
> > Java has interfaces as well as classes - they are shown with the same
> > icon in the class view. 
> > 
> > Java classes often have long package names like 'org.kde.koala.KAction'.
> > The class parser doesn't handle fully qualified class names containing '.'s at
> > the moment. A '.' might need to be converted to a '/' (slash), when a path plus
> > classname is added to the class store, as '.'s have a special meaning
> > internally. The '/'s would need to be converted back to '.'s on display.
> 
> Don't you create namespaces (ParsedScope) for packages? In that case, the
> '.' is an implementation detail and shouldn't collide with any of your
> identifiers.
Hmm I thought there was a problem - I'll have to look at how the class store
works. But there is no support for Java packages currently.

-- Richard

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