#32 ✓resolved
Thell Fowler

Introduce FuncGuard category setup

Reported by Thell Fowler | January 27th, 2010 @ 08:47 PM | in v2.0.0

#8 introduced FuncGuards, yet there is quite a bit of repo management involved for both the dev and the repo maintainer in ensuring that function guards don't make it into submitted patches.

In the thread for #8 Joce had brought up some very valid points regarding this issue:

The func_guard() statement needs to be there, but why would you expect the enable/disable statement to be in committed files? A single define in the npp_debug.h to check if there are active func_guards being read in from a non-tracked header seems to be a solution that eliminates having people stepping on each-others toes with enable statements.

That could be useful in some cases, but in many other, having a centralized category file will be rather cumbersome, and will cause full recompilations when adding / removing categories.

Also, for generic calls that can be done in more than one context, it makes much more sense IMO to have the enabling done at file level. Otherwise, you'd still have to have a context for that one file, but it would be declared in a foreign place. i.e. TinyXML. It is its own context. I don't see why the enabling of TinyXML guards should be done elsewhere than that, and disrupting the compilation of other files that have nothing to do with it.

Secondly, that would mean that we have a file that knows about all the project, from the top, but that could be included by the bottom. Allow me to explain: Even though we currently don't have any formal code hierarchy, we can agree that utility files like common.cpp are at the bottom of the pile and should not know anything about files implementing higher level concept, as the Docking*.cpp files for example. With the centralized concept you propose, common.cpp you be exposed, however indirectly, to docking concepts (the Docking category) that mean nothing to it.

So, while I'm not totally opposed to categories that have scopes broader that files, I think that should be layered, and we should be careful what we put and include where.

After discussing this on the irc channel it was agreed there should be a solution.

Here is what I am proposing:
* That there be three files added to support having FuncGuard categories enabled without the penalty of rebuilding the whole project when the state of one is altered. Those three files are:

  • FuncGuards_skel.h will define all of the project's function guards in a disabled state. An example of this file is available in the FuncGuards_skel.h.orig file posted to Github.

  • FuncGuards.cpp will set each FuncGuard to either the enabled or disabled state. It will include the precompiled header of the project and the active FuncGuards.h file. A sample of this file (minus the project specific includes) is available in the FuncGuards.cpp.orig on Github.

  • FuncGuardsImport.h has an import statement for each FuncGuard defined for the project and is included in the precompiled header. The sample for it is available at FuncGuardsImport.h.orig on Github.

Also added to the project would be a pre-build event that validates the existence of a FuncGuards.h file ignored by gitignore. This file would be created if it does not already exist by copying the FuncGuards_skel.h.

I believe that this setup balances the flexibility needs of a developer with the ability to share patches with others without fuss. Simply put, this setup allows a developer to git co -b MyTopic and alter whatever FuncGuards are enabled or disabled without even thinking about how that would effect their commits. Whenever the developer wanted to add a FuncGuard category they would simply add it to those files and commit/submit the addition.

As time goes on there would be more and more predefined FuncGuard categories for the classes, files, and function purposes available to every developer. When a new developer wants to learn how a particular area of the code works they'd simply enable a category and go. No more trying to find which functions relate to each other and how.

Comments and changes to this ticket

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Notepad++ Community Release

Shared Ticket Bins

People watching this ticket

Referenced by

Pages