[PATCH] Make language support types more generic

Hamish Rodda rodda at kde.org
Wed Aug 13 02:09:54 UTC 2008


Hi,

While implementing support for languages other than c++, it has become 
painfully obvious that much code is just copied from c++ into those language 
supports.

It's clearer still that this is unnecessary for much of the code, and this 
patch removes the need to duplicate code for the type system.

Unlike the last make-generic code that I just committed, I thought I should 
post this patch series for review first.  The change log follows.

The only remaining issue with this patch is that in StructureType::toString(), 
currently we can't get to Cpp::IndexedInstantiationInformation, should that be 
made generic too somehow?  Alternatively I could bring back Cpp::ClassType, 
just for this functionality if it is truly c++ specific.

Cheers,
Hamish.

KDevPlatform:
- Remove CVSpecs from Declaration (replaced by AbstractType::CommonModifiers::
{ConstModifier|VolatileModifier}

Type System
- Change all equals operators so that A != B when B is a subclass of A 
(before, A == B but B != A)
  This is achieved by comparing the typeClassId within AbstractType::equals, 
and negates the need for fast cast.
- Re-enabled fastCasts. BTW, fastCast would be faster if we just compared 
typeClassIds.
- Remove all operator== and operator!=, just use equals() instead
- Ported all changes to c++ types since this patch set started

- Structure Type
  - Now an IdentifiedType subclass
  - Only remaining issue with this patch: currently we can't get to 
Cpp::IndexedInstantiationInformation in toString(), should that be made 
generic too somehow?  Alternatively I could bring back Cpp::ClassType, just 
for this functionality if it is truly c++ specific.

- Integral Type
  - remove name() / setName() (not used, doesn't make sense)

- Enumerator Type, Enumeration Type
  - moved from c++

KDevelop:
- Ported to new api
- Removed custom c++ types where their functionality is 100% implemented by 
the generic types

Still TODO:
- Clarify which AbstractType::CommonModifiers should stay and which should be 
moved to Declaration
- Introduce same flag system to Declaration?
- Better support custom types, modifiers by providing an interface which 
language supports can implement to return the string translation of each 
custom type/modifier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdevplatform-generictypes-20080813.patch
Type: text/x-patch
Size: 40428 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080813/2a6bd28b/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdevelop-generictypes-20080813.patch.zip
Type: application/zip
Size: 32515 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080813/2a6bd28b/attachment.zip>


More information about the KDevelop-devel mailing list