[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [API] Flake class names
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2009-12-14 19:19:08
Message-ID: 200912142019.09446.boud () valdyas ! org
[Download RAW message or body]

On Saturday 05 December 2009, Thomas Zander wrote:
> On Saturday 5. December 2009 13.43.18 Johannes Simon wrote:
> > Woot, replying to myself. I like doing that.
> >
> > I realize that my previously suggested policy would cause confision,
> > because in general, a base class does not have to be abstract.
> >
> > In contrast to that, the following policy should be rather obvious:
> > 1) Classes you must subclass to use should get the prefix "Abstract"
> > 2) For classes you can use directly, but that are also encouraged to
> > subclass, use "Base"
> 
> I have the impression its a little more complicated then you suggest above;
> imagine renaming KoShape to KoAbstractShape.
> 
> * From the point of view of people inheriting from it, that makes sense.
> * From the point of view of using it in a method, it doesn't.  I don't care
>   the shape is abstract if I just want to use its API. I don't want to have
>   to do a dynamic_cast<KoAbstractShape*>()  everywhere. KoShape makes sense
>   on its own.
> 
> This is why half our abstract classes don't have any such self explanatory
> name

Hm, yes, this is a good point, I think. Not sure what a good solution is, 
though -- on a case by case base I'd be tempted to:

> See here a list of abstract classes in flake alone;
> 
> KoDockFactory
> KoEventActionFactory
> KoFilterEffectFactory
> KoShapeBorderFactory
> KoShapeConfigFactory
> KoShapeFactory
> KoToolFactory

Rename those to *FactoryBase because those classes are only visible to the 
developer if he subclasses them, the subclasses are used internally in Flake, 
aren't they?

> KoFilterEffect

That's Jan's call. I wouldn't rename, personally.

> KoTool

This feels like a candidate for a rename, again because KoTool is something 
you subclass as a plugin developer, you don't write code against KoTool in 
your plugin, generally.

> KoShape
> KoFrameShape
> KoShapeContainer
> KoParameterShape

These sound like good candidates for not renaming.

> 
> KoFilterEffectConfigWidgetBase
> KoShapeConfigWidgetBase
> 
> KoShapeContainerModel
> KoShapeBorderModel
> KoViewConverter
> 
> KoCanvasBase
> KoCanvasObserver
> KoCanvasObserverProvider
> 
> KoDataCenter
> KoDevice
> KoDeviceEvent
> KoEventAction
> KoDragOdfSaveHelper
> KoShapeBackground
> KoSvgPathParser


Same for these, I think

> > I can prepare a patch if no-one disagrees.
> 
> I suggest first writing a 'foo -> bar' rename set and posting it here so we
>  can look at the results before you put a lot of work in it.
> See if it makes sense :)
> 


-- 
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]