tpierrain/NFluent

Reorganize project files

Closed this issue · 6 comments

dupdob commented

Folder and namespace structures could benefit from some clean up as they have grown through the years

tpierrain commented

+1 ;-)
Le mar. 13 sept. 2016 à 22:20, Cyrille DUPUYDAUBY notifications@github.com
a écrit :

Folder and namespace structures could benefit from some clean up as they
have grown through the years

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#165, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACsXheVVJYtfA_VrsKlMuAO_4YoQYA-Gks5qpwUvgaJpZM4J8GTj
.

dupdob commented

Here is the proposed target structure. Principles are:
align namespaces are stored into namesake folder. But a namespace can be break down into multiple folders for convenience. I.e: NFluent.Extensibility classes are filed within the extensibility folder. But the 'Checks' folders store classes from the NFluent namespace.
Namespaces

  • NFluent: public entry points and associated interfaces, standard checks
  • NFluent.Kernel: internal classes used for implementation of the core logic of NFluent
  • NFluent.Messages: implementation of message construction logic
  • NFluent.Extensibiliy: classes supporting extensions ton NFluent, focusing on helping implementation of custom checks
  • NFluent.ApiChecks: checks dedicated to API checking. Currently internal only, until sufficient value is reached

Folders

  • namespaces are stored in the folder with same name (e.g.: Kernel)
  • all public Checks are stored in the Checks folder
  • T4 generated checks are stored in a dedicated folder ('T4')
  • Obsolete folder stores obsolete classes
tpierrain commented

Like it! The only important thing is to not impact the end-users experience.

dupdob commented

Potential impacts:

  • some public classes may have unwittingly changed of namespace (unlikely)
  • some public classes are no longer public. Rather should never be in the first place (most classes in Kernel namespace)
    Target is to have
  • no impact for NFluent users
  • minimal impact, if any, to NFluent extenders. Changes should be limited to namespace changes (automatically handled by reshape per)
    There will be breaking changes for extension using NFluent internals, due to visibility restriction. I propose to evaluate potential rollbacks on visibility on a per request basis.
dupdob commented

This proposal has been implemented on my master branch in the NFluent.core project
It will be tested when I'll have migrated tests

tpierrain commented

Ok. Let's see if it triggers a 2.0 release (if breaking changes) or a 1.4 (if no breaking change) then