https://www.linkedin.com/in/christopher-posten-20a025265

The Factory C Manual


introduction
	1.1		- strategy 
	1.2     - 
	1.3     - 
	1.4     - 
	1.5     - 
	
virtual table object
	1.1     - struct config
	1.2 	- implementing a basic struct class
	1.3     - using the virtual object
	
factory table class
	1.2 	- implementing a factory table class and registering
	1.3		- the factory table multimap 
	1.4     - using the factory object
	1.5     - constructing a builder class for complex object
	1.6		- using complex object
	1.7		- the class iterator

adapter table adapter(s)
	1.1 	- implementing an adapter set for virtual object
	1.2     - using virtual adapter(s)
	1.3     - implementing an adapter factory table class
	1.4		- using factory adapter(s)

control factory
	1.1 	- using the control factory
	1.2		- 
	1.3     -
	1.4     -
	1.5     -



Factory C is implemented as a series of fortifications
used to provide the strategic advantage over the program
by overloading everything until nothing can be overloaded 
anymore and object oriented programming can be released 
from its restriction of dependence on an implemented 
structured datatype and its member access operator. This
dynamic-at-compile time only feature introduced using a 
struct (short for implemented structured data type) provides
sturdyness to the structure of the implementation of Factory C
as, (like I said) a series of fortifications used to provide 
strategic adavantage over the program using a factory 
table that is the program's "data type table & builder" that
can take advantage of centralized overloads and 100% dynamic
override capacity thats 100% strategic interface methods across
the full range of overloads and overload cases provided by
the program factory table as the centralized point of access
for interfaces and interface oriented programming. interface
oriented programming underneath class oriented programming.
IOP is not as developed of a term as object
oriented programming (OOP) but interface oriented programming for 
class assigned interfaces (not an objects assigned interface) 
can also be called class oriented programming. 

It is a misplacement of Factory C to put it as 
object oriented programming only because Factory C (OOC) is
(by the weight or scale of its implementation) is 50% class
oriented programming, 25% object oriented programming and
25% control factory that is what can (is) be used to give birth
to C.L.O.S. inside of C or a()( b()()()()() )( b()()()()() )
( b()()()()() )( b()()()()( c()()()() ) )()()()()()()()()()()()d 
syntax. Thats 50% factory table & class builder implementations,
25% virtual table and adapter table implementations, and 25%
control factory. (more or less). that was just something of a
description of what Factory C is by scale. I found it hard trying
to explain to people exactly what makes Factory C (OOC) worth
using over other object oriented programming and getting results
from people who were saying it offers the same thing as C++ or 
Objective-C or that metaprogramming can be used instead or 
C.L.O.S. can be used instead. I am happy to hear that someone 
can see that it does that when it uses all of the otherwise 
unavailable C++ keywords in C, myself giving them personal 
defintions. I don't know what Objective-C is but I can tell you
that 75% of Factory C is not object-oreinted programming now
that i give it a good inspection of what it was again, just 
something I implemented here and there in my spare time even 
sparingly until i introduced a new table, akin to a virtual
table similar to C++, but a factory table. The Factory Table
is what.

  "a series of fortifications used to provide 
strategic adavantage over the program using a factory 
table that is the program's "data type table & builder" that
can take advantage of centralized overloads and 100% dynamic
override capacity and 100% strategic interface methods across
the full range of overloads and overload cases provided by
the program factory table as the centralized point of access
for interfaces and interface oriented programming."

if I were to further develop a term myself here, I would 
further develop the term class oriented programming over
interface oriented programming over object oriented 
programming, in that order. Factory C is all I will ever 
accept to use to implement a program ever in all my life 
for as long as i live unless something critical needs to
be considered like there is no room for it and only room 
for C or Assembler when it comes to certain areas of the 
field like microcontrollers/progamming to a microcontroller.

I find it inspiring that C is C because it comes after B.
For a second i almost thought that C was supposed to be for 
Constructor but I found the real story. Constructor still 
fits and there is almost room for something newish to be 
called Constructor if im not just going to think of C itself
as Constructor, after Assembler. Anyways,... Thank you 
Dennis Ritchie and company. 

underneath of class oriented programming is interface oriented
programming and beside interface oriented programming is 
object oriented programming. interface oriented programming 
in Factory C consists also of not only a class extended interface
but a class interface heap it is placed inside as a utility to 
go beside interface registrations, each with a pair of methods.
This is true also for the the class virtual table before extending it,
that it has a pair of methods, the constructor/initializer (1)
and the destructor (2) (and after the type method that they all have(0)).
these interface registrations are best accessed in a way similar
to a C++ constructor, which is non-dynamically. This would be 
using the interface name instead of the class name, but still a 
dynamic-at-compile time at best typedef or text identifier. This is
because my dear little interface registrations are very small and
very neatly cut-cornered to fit about ten or so into a class 
interface heap (to go with still exactly one class extended 
interface). I am very excited for introducing a structured process
where classes as datatypes get registered at the program factory
table and when they do, get registered with a number of registration
interfaces (interface registrations) for providing a single
strategic point from where any class shares its functionality 
with any other class for a specific purpose hopefully determined 
by a type of object-oriented design pattern. Never forget that 
the class is the object and believe it and you will never be 
confused again over the difference between class and object in 
object-oriented programming (OOP). structclass.h has all 25 or 
so interface registrations, struct class registrations. the single
most strategically fortified place i know of is the registered 
factory table class, registered at the factory table with its 
arrays and its typenames (prototype shaped) factory methods or
maps for the class. Map like C++ gives a definition of a map as
a class in Factory C (OOC) is like a map you read on paper, a 
multimap in C++. the keyword multimap from C++ is used for the 
factory table class multimap in C++. Below I have each Test case
for multimaps use in Factory C. Remember that multimap factory 
methods (all three) do not know how to return 0 but throw an 
exception at the point when it would otheriwse be forced to 
return 0. You can therefore always dereference the return from 
multimap. If you do not use all the designated factory methods
(false designates two, true designates three) then it leaves one
on the stack (map stack) for you to call from map. map; by itself
is a statement and pops a factory method without calling it. map
always has a chance to return 0 so its way more within comfort to
try to use it as a case but at the same time never dreference what
map returns as it always has a chance to return 0. 

		multimap(-1);
		if( map("Class") ){}

		multimap(-1)("Class");
		if( map("class(FactoryTable)") ){}

		multimap(true)("Class")("class(ComplexHeap)");
		if( map("val") ){}

 - - or - - 
 
---Check if row == 0 or nullptr or null or NIL or NULL lol after
using map() to init (ialize).
 
		multimap(true)("Class")("class(ComplexHeap)");
		Complex * row = map("val");

---This is for initializing a variable without having to check for 0

Interface reg = multimap(false)("Class")("class(ComplexHeap)");

Complex * row = multimap(true)("Class")("class(ComplexHeap)")("val");

---This is what it looks like when I really just wanna use my 
multimap to do something! (call execute function strategically 
example) this can be given an overload function:

((execPtr*)class(multimap)(true)
(typeid(obj))(class(OverloadHeap))("val"))[1](obj);

---special: note that "val" goes into the sub factory method,
            now if i was strategiaclly inclined enough to have
			a variable or method that goes in place of that it
			would unlock the strategic potential of Factory C
			"overload specializations", maybe for some reason
			a new method can map data members to something like
			a typeid() or type_info() that has to do with revealing
			adapters over plain objects...
			 
---overload function:

void execute(Object * obj)
{
((execPtr*)class(multimap)(true)(typeid(obj))
(class(VirtualHeap))("execute"))[2](obj);        //override not included
}

---or maybe:

void execute(Object * obj)
{
  ((execPtr)*function(obj, "execute"))(this);   //for override also
}

this function is overloaded for every class with an
execute method at somedatafield position inherited
from some struct or something from down the line it
makes no difference whether its inherited or not by
anything just as long as its there so just bridge that 
shit together and we will never again have to worry 
about where we put our methods for our inheritances, 
just think the interface is an array of pointers as methods 
accessed strategically by mapping the datafield positions, 
using the class(VirtualHeap) registration for an overload 
to overload the interface! thank the goddamn factory table!

I need to make a note about strategy, it is/based on 
direction/indirection and its a pointer in C that is indirect/
has the indirection and so is 100% strategically capable.
But all strategy (at least in C) is achieved by using
a pointer for some procedural or operational purpose. 

Maybe I was going too fast also, interface registrations that
have the word Heap in them use a (sub) factory method and
pointer to the datastructure used by it as the two pointers
provided by interface registration. these sub factory methods 
are for class information tables as sub heaps to the class 
interface heap as a form of a composite data structure (very sturdy).

The greatest thing would be to strategize on interface 
registations and their sub heaps and possibly make new ones.

Each interface registration is implemented to represent
a form of object oriented design pattern or something like.
This will determine what helper method(s) can come of 
using a registration, if not just multimap is used as the
backbone of Factory C for its class oriented programming.
thats a good 50% of its functionality. So implement a new
method that uses multimap or anything multimap was used 
to implement to do it all yourself in Factory C is my advice.
to re-apply object-oriented programming to the object 
procedurally using the factory table there are the three
object oriented helper methods (global methods) that 
are used to access the object datamembers: (()complex())

		(**(int**)complex(obj,"val")) = 123;

---used to access the interface methods: (()function())()

		((void(*)(Object*))*function(obj, "fun"))(this);

---and used to allocate an object: factory()()

		Object * obj = factory("Class")(this, 2, a,b,c);

To get it right, Factory C still tries its hardest to 
centralize on the object-oriented corner of it. since everything
is for the object to be fully capable of any task. for strategic
purposes, there is a primary and a secondary virtual table. that can
be discussed if we need to implement an operating system(s). 
otherwise just be aware that there is a hidden virtual table
with different forms of information hiding centered around it.
This gesture makes way for the most grand gesture that 
Factory C has and thats an empty virtual table for objects, to 
put what you want into it and have full control using a clean
table of a virtual table with no hidden processes accessing
it any time ever. (just for your runtime objects)(simple). 

I am going to (last but not least) reserve space to talk about the
control factory and its uses. it is in one way, like a class
with an initializer for a function sequence using an iterator
called the controller. discombobulated from that is its virtual
table object made to go also onto a stack for when control factories



(continue on this tomorrow with emphasis on stacks and how
everything like a constructor stacks and everything goes on a stack)
the function arguments stack, what every function needs to look like:


        explicit bool       _(remove)( Object * self, ... )
        {
            if( !(*Flags[0]) ){flags(0)=1;ControlSlot[0][0]=&self;}

            bool flag = ((bool()(*)(Object*,...))

                (*function( self, "remove" )))(this);

            (*Flags[0]) = false;

            return flag;
        }

That my firend is the most beautiful piece of syntax sugar for
a c program with small statements to well presented functions

















Factory C is Factory C because it uses a factory table that uses a 
strategic factory method(s) thats the singleton class factory method 
to the class interface heap for a factory table class. There are 3 
levels of OOP in Factory C and thats Virtual, Factory, and Complex. 
The Complex object uses a runtime object for its interface inside of 
its own builder table and heap containers for its class interface heap 
and class information heaps, and runtime objects for its interface 
registrations. This (Factory C) is for fully dynamic-at-runtime 
Object-Oriented Programming with no limitations on things like datatypes 
or multiple inheritance or coupling.
As a presentation of hash tables or data structures Factory C uses a 
Virtual Table, Factory Table, and an Adapter Table. there is a single 
linked list template you can typename, also a vector and binary search 
tree (heap). but only the datastructures needed to implement Factory C 
are included. Also, part or the Object-Orientation of Factory C is that 
every primitive type has a constructor plus interface as a virtual table 
object and factory method plus interface heap as a factory table class. 
The Complex object is created using a small class builder that is 
implemented in C.


Factory C is the Object-Oriented Library Designed to finish the implementation 
of the C programming language that started over 50 years ago. It does so by 
implementing large runtime structures, and multimethods that are a combination 
of factory methods (maps), constructors, overload functions, using 3 primary 
hash tables (Virtual, Factory, Adapter), 2 secondary hash tables (Builder, 
Secondary Virtual), 10 stacks (Object, Exception, Jump, Flag, Map, Heap, TypeID, 
Interface, ControlFactory, Pass) (all singletons).Factory C gives class factory 
methods to its classes, the single most strategic method a class can have and can 
be compared to a tractor with torque (like strategy) enough to pull a plow (like 
an interface heap). I am proud to anounce that Factory C uses a small class builder 
that, using several global multi-methods that include constructors, implements a 
class inside a function or function(s) reaching the highest-level of object-oriented 
programming that includes things like the complex constructor for a complex object, 
the constructor assigned to a builder complex that uses the complex heap to determine 
how many parameters the constructor takes (and in alphabetical order for instance). 
Factory C is supposed to be a programming language itself but is not. Not having taken 
the time yet to build a compiler that, does not make any changes to the C compiler and 
adds all the new methods, macros as keywords that cannot be indefined. If this would 
be done then that programming language would be known as "Constructor". Constructor 
(Factory C) unlocks the fully-dynamic object-oriented potential of the aged programming 
language C, which in the authors opinion, C was always for Constructor anyways. That's 
Constructor after Assembler, or Assembly. There are 3 levels of Object in Factory C 
including Adapters at each level. Virtual, Factory, Complex. I am proud to announce 
that Factory C uses a Constructor Sequence known as the Control Factory for things 
like IO Streams.


The Sole Developer/Programmer/Engineer of Factory C. Core skills in Data Structures, 
Design Patterns, DataType Templates, Virtual Table & Polymorphism. This is all done 
using macros, functions, pointers. The Object Oriented Definition starts with using 
an Object, Iterator, Container. Iterator and Container are Implemented Structured 
DataTypes (struct), Object is a type define for a void pointer. There is a struct 
class, or more like a set, starting with the "struct" class(VirtualTable), 
class(FactoryTable), class(AdapterTable), ... Factory Methods and Constructors,... 
and Registrations that are non-extended struct class Interfaces go with the 
class-extended Interface in an Interface Heap. There is the substitute for multimple 
inheritance, or there is multimple inheritance, i was never excited to use multiple 
inheritance in C++, its coupling is too tight. Way too tight. Factory C provides the 
Interface solutions and the solution of Object-Oriented Programming that the community 
deserves to see. So Factory C is free software... (2023) is still early on and not much 
for promotions on it, but just getting into things like online repositories, forges, etc...