Extensible class - for lack of a better term

General
21

it wont compile if the module is missing

22

so we are right back to the KEY idea I had a few hours ago (where “KEY” is “kProVersion”)

23

if you’re going to sell full source then theres no “lite” version without splitting it into 2 classes
lite is “full source” with Pro stuff missing but anyone who has full source & doesn’t have the missing Pro stuff can just read the code & add whatever they want

so “lite” probably needs to be less expensive and encrypted
and pro full source & more expensive

and IF lite is encrypted then it can quite literally be "pro with features disabled because the kPro constant is set false

24

You keep making incorrect assumptions… as I said in an earlier post, the plan is make availabe all combos in source and encrypted modes…

I have a solution I am going with… Thanks for all the input

25

curious to see how you’re going to do this

26

I’ve already told you.

Lite Version (and its not really “light”, it just doesn’t have 7 functions active), this will consist of TWO files (open or encrypted doesn’t matter)

  • the code that encompassed the main class
  • a “key” module that has ONE public const “kPro=false”

If the developer decides to opt for the upgrade to “pro” which will add those 7 functions, they will get another TWO files

  • the code for the module
  • a NEW “key” module that has ONE public const “kPro=true”

So the lite version consists of two files

  • class code
  • key code (kPro=false)

the “pro” version consists of three files

  • class code
  • key code (kPro=true)
  • module code

Should the developer have only the “lite” version and decides to alter the key module to change false to true, then attempts to compile will fail, as it will be looking for the contents of the “pro” module, but that is on the developer for trying to game the process.

Should the developer have the “pro” version, and for some stupid reason change the key from true to false, it will simple compile as the lite version

The lite version (ie. class code) will never need to be modifed (outside of bug fixes), and will contain all the code necessary to identify, parse all the information for the 7 extra functions, but it will not insert them into its internal execution queue.

When it gets “kPro=true”, then it Will insert them into the queue, and the code to process those queue elements will be in the “pro” module, and the calls will be protected with a #IF conditional. As a matter of fact I am going to have only ONE entry point in the pro module, thus reducing the complexity and need for multiple #IF statements.

Thanks to all of you for your input, insight, … it all helped me decide on this course of action