Open source my OIOIC, a completely new object-oriented mechanism for the C.

[pervise.zhao]

Have you ever worked with a language that supports OOP natively? Have you worked with any GUI libraries in an OOP language? I'm thinking of things like wxWidgets, Ultimate++, FLTK, QT or GTK+ for C++; Delphi (VCL + Object Pascal); .NET languages. In every one of those instances, I am able to simply include a component, such as a socket listener, and the only code I have to write is a #include! I do NOT every touch the library to make the component work with my code. While I need to know a component's properties, I never need to worry about incorporating its implementation details into my own project. The #include simply handles that for me.

By contrast, if you gave me a network socket class written in OIOIC, it appears that I would have to worry about merging multiple source files together with my own project, managing any potential conflicts in the various aliases used, etc. My concern, when looking at this, is simple: it looks like it makes my life harder, not easier. It also looks like it does not support many of the OOP concepts that I rely on.

As I said before, it is a brilliant creation. Unfortunately, I am having a hard time seeing how it would make my life easier. I can, however, envision it making my life harder.

The creator of the component should write a .h (recommended name is "ComponentName.h") file, which contains some required definitions for outside.

1.Do not have to merge multiple files. The only code you have to write is ALSO a #include (the above .h file).
If the source code of the components has the following definitions:
#define X 1
#define Y (X+1)
#define Z (Y+1)

Supposing outside use the Z, the creator of the component should write the Z in the above .h file:
#define Z 3

2. It is also very easy to manage conflicts in the various aliases used. Just change its name (recommend to prefix component name):
#define ComponentName_Z 3

In the future, if there will be a C IDE that supports OIOIC, these work will be done by the IDE.

I think OIOIC will make our life easier rather than harder in many aspect.

[WingedPanther]

I guess I will need to see something significantly more involved than the examples you have before I will be convinced there is value to OIOIC.

[pervise.zhao]

I guess I will need to see something significantly more involved than the examples you have before I will be convinced there is value to OIOIC.

I also think so. But compared with other technologies, OIOIC is an universal idea of object-oriented framework. Therefore, as long as a project has the part that is decided to be implement with C, I will use OIOIC to design it. Thus, the framework design saves my much power, because OIOIC have done a lot of job for me.

Welcome everyone to continue the discussion, express your views on OIOIC.

[pervise.zhao]

Welcome your views on OIOIC, sincerely!

[WingedPanther]

Have you created any more complicated programs with it?

Let me try explaining my concerns in a more concrete way while I'm at it. Let's say I work for a company that has five programmers who are working on a suite of programs. Because of the type of work they do, and their specialties, the result is that three of the programmers work on specialized areas, and two work on general stuff. The result might be something as follows:
Programmer1 develops and maintains mathutils.c and mathutils.h
Programmer2 develops and maintains sqlutils.c and sqlutils.h
Programmer3 develops and maintains guiutils.c and guiutils.h

These three sets of files exist independently of each other, and the three programmers have essentially no awareness of what the other two are doing. Furthermore, programmers 4 & 5 have no awareness of the details of the above .c files, nor do they care. They work on:
Programmer4: service1.c, service2.c, service3.c, service4.c
Programmer5: app1.c, app2.c, app3.c, app4.c

The question becomes: if these programmers are using OIOIC, do they have to maintain a common OIOIC file for everything? If so, then won't service2.c get polluted with logic from service1.c, especially if service2.c doesn't use mathutils but service1 does?

If they are using seperate OIOIC files, one for each product, doesn't that suggest that Programmers1-3 need to update the OIOIC files for the products whenever they make a change to one of their utilities that affects OIOIC? Wouldn't that require them to be overly aware of what programmers4-5 are doing and potentially have to maintain each OIOIC file differently because of changes that have been made?

What if Programmer5 isn't interested in using OIOIC? How much awareness of it will be forced on him in order to use the utilities that are developed using it?

The reason I bring all these issues up is that I work for a company that has a similar structure of files (in Delphi). When one utility is updated, there is generally NO impact on the files that rely on it. Similarly, the above scenario in C++ would allow developers to have minimal awareness of what the others were doing. Anything that entails developers dealing with shared files is a potential issue. It represents a burden on the development process, and increased potential for people to damage other people's code.

How does OIOIC handle this?

[pervise.zhao]

Have you created any more complicated programs with it?

Let me try explaining my concerns in a more concrete way while I'm at it. Let's say I work for a company that has five programmers who are working on a suite of programs. Because of the type of work they do, and their specialties, the result is that three of the programmers work on specialized areas, and two work on general stuff. The result might be something as follows:
Programmer1 develops and maintains mathutils.c and mathutils.h
Programmer2 develops and maintains sqlutils.c and sqlutils.h
Programmer3 develops and maintains guiutils.c and guiutils.h

These three sets of files exist independently of each other, and the three programmers have essentially no awareness of what the other two are doing. Furthermore, programmers 4 & 5 have no awareness of the details of the above .c files, nor do they care. They work on:
Programmer4: service1.c, service2.c, service3.c, service4.c
Programmer5: app1.c, app2.c, app3.c, app4.c

The question becomes: if these programmers are using OIOIC, do they have to maintain a common OIOIC file for everything? If so, then won't service2.c get polluted with logic from service1.c, especially if service2.c doesn't use mathutils but service1 does?

If they are using seperate OIOIC files, one for each product, doesn't that suggest that Programmers1-3 need to update the OIOIC files for the products whenever they make a change to one of their utilities that affects OIOIC? Wouldn't that require them to be overly aware of what programmers4-5 are doing and potentially have to maintain each OIOIC file differently because of changes that have been made?

What if Programmer5 isn't interested in using OIOIC? How much awareness of it will be forced on him in order to use the utilities that are developed using it?

The reason I bring all these issues up is that I work for a company that has a similar structure of files (in Delphi). When one utility is updated, there is generally NO impact on the files that rely on it. Similarly, the above scenario in C++ would allow developers to have minimal awareness of what the others were doing. Anything that entails developers dealing with shared files is a potential issue. It represents a burden on the development process, and increased potential for people to damage other people's code.

How does OIOIC handle this?

In the future, if OIOIC is popular as a standard of the C, at that time, when using other OIOIC-based software,you will firstly be customary to ask: Does this software use which version OIOIC?

In addition, OIOIC files are dapper, if you are familiar with the OIOIC enough, you can customize own OIOIC files according to own needs, without affecting outside to use your software.

[WingedPanther]

My concern is about distributing a utility library, not a complete software. I would expect that if I write a library in OIOIC, and somebody else tries to write a program in OIOIC that uses my library, there will be numerous conflicts.

Also, I'm not sure you addressed my previous concerns. As an American, if I were considering OIOIC as a technology for my company to use, your response would convince me NOT to use it. I may consider the use of OIOIC a trade secret. If I'm producing libraries and my customers need to know whether I used OIOIC to use my library in their OIOIC programs, then there is a problem. If they need some of my OIOIC files for integration, things just got worse.

[pervise.zhao]

SORRY! My english is not good.
Reply slowly!
Misunderstand your question!
Express inaccurately!
I would like to gradually get better.

[WingedPanther]

My concern is this: If you are using OIOIC for a single program, and you are the only programmer, there is no problem.

If you are using OIOIC for multiple programs with common files, or with multiple programmers, then coordinating changes becomes complicated. Does OIOIC have a mechanism to handle that transparently?

[pervise.zhao]

My concern is this: If you are using OIOIC for a single program, and you are the only programmer, there is no problem.

If you are using OIOIC for multiple programs with common files, or with multiple programmers, then coordinating changes becomes complicated. Does OIOIC have a mechanism to handle that transparently?

The common files are OIOIC files (oioic.h and oioic.c). In the same OS platform, do not need to change the two common files.