Object inheritance from .APP

[Nro]

I’m programming with Fox for a long time now. I’ve created a lot of utility classes, build from derived classes of FFC, some of them are made from other bases class. I usually distribute an .EXE and I never had to distribute the code of my sources base class.

New client, new restrictions.

I can Instantiate an object from a .APP library, so I don’t have to distribute the .VCX or .PRG

My question is: is it possible to derived one class from another, even if the base class is not a .VCX ?
OLE is not an option and maybe and .FXP
Here something I want to do

* Instantiate from test01.app - working
LOCAL lom AS Object
lom = NEWOBJECT("_ocustom", "_oclass", "test01.app")
lom.cBoxMess = "Test - App"

MESSAGEBOX(lom.cBoxMess, 0+ 64, "Test 1")

lom = NULL

and

* Instantiate from dev_ocustom – not working
LOCAL lom AS Object

lom = NEWOBJECT("dev_ocustom")

MESSAGEBOX(lom.cBoxMess, 0+ 64, "Test 2")

lom = NULL


* Derived from _ocustom in test01.app – not working
DEFINE CLASS dev_ocustom AS _ocustom OF "p:\objitech\apps\develop\test01.app"

	PROCEDURE init
		DODEFAULT()
		THIS.cBoxMess = "Test Sub-Class"
	ENDPROC

ENDDEFINE

Thanks in advance.

Nro

 

[Olaf Doschke]

As class of classlibrary can only be a vcx or prg, not an APP.
The syntax that would need to be supported would be DEFINE CLASS myclass AS classname OF some.vcx IN another.app, but such a syntax doesn't exist.

But you build the APP from vcxes. You can inherit the usual way and compile new classes into an APP together with their older parent classes and classlibs.

Bye, Olaf.

 

[Olaf Doschke]

I also have such APPs and just experimented with SAVEASCLASS.

The idea was: If you can't inherit directly from APP you may inherit from a class you create by a) creating an object with NEWOBJECT and b) save this object as a new class with object.SAVEASCLASS().
The resulting class hasn't got the app as it's class location, it points back to the original vcx and base class used to compile the APP.

So it all turns to what I already said, to extend your class hierarchy you have to inherit from the classes and classlibs, which are the source code of the APP, like with an EXE. It doesn't surprise me.

Bye, Olaf.

 

[Nro]

What if I copy my class code juin a .PRG and compile it?

 

[Olaf Doschke]

Can you expand on your idea? SaveAsClass doesn't generate PRG class code.
You may knoe "viewcode" as feature of the class browser. It's part of SCC and creates a PRG code for source code control, but partly not working.

You have the source code you compiled as APP, don't you? So why don't you continue to develop in the source code and create a new app? Are saying you need class inheritance at runtime? Creating new classes? Are you developing a programming language based on VFP for your customers? Any need for customizing a software within the software I can think of won't need to go as far.

Bye, Olaf.

 

[Nro]

All I want to do is re-use the 10000 lines of code I already create. And I don’t want to distribute these classes with my new project.
I’m thinking of it as .NET assembly. You can sub-class you classes from the assembly but you don’t have to provide the assembly source code. I’m out of the office right now but I’ll give you more detail next week

 

[Olaf Doschke]

As far as I understand you don't want to sub class at runtime, you just want to subclass from your current repository of libraries. As I said you can, simply on the normal way of inheriting from the VCXes that make up the APPs. Then build the new APP including that new inheritance level of classes and that's it, isn't it?

To protect your intellectual property (source code) neither assemblies nor APPs are a way, .NET IL code as part of assembly DLLs is decompilable in the same way as VFP object code is, if you don't protect it by encryption, that's more essential than whether you could inherit from APPs or not, the compilation doesn't protect your code.

I know what you mean, in .NET you add a reference to Assemblies of the .NET framework or by third parties and your classes can inherit from there (if classes are not defined sealed).

In VFP there is no such mechanism. An APP or EXE is simply a archive of the VCXes etc in them. And in VCXes the object code already is within the VCX, not in a separate file. You can remove the code from the code memo after compiling a VCX and it still works, that would be the most similar way of inheritance. But in projects having such VCXes you can never build with the option "recompile all", as that would destroy the object code in these VCXes. The only thing in VFP having object code separate from source code are PRG and FXP, but you can't define a class referencing a class in some fxp. So VCXes in which you remove source code are the nearest you get to your goal.

Both assembly DLLs and VCXes and FXPs and also Java object code can be decompiled, .NET code because it's just IL (intermediate language) code and VFP object code also is composed of certain opcodes, that map back to the source code function or command. We don't have a translation like C++ was translated to assembly and then compiled, which is much harder to decompile back to C++, but decompilation has a long history also back to older languages that were harder to decompile.

And in the end, if you inherit from a DLL in .NET, and that inherits from another DLL, your distribution will need to contain all the DLLs back to the first level. That's even true for the .NET framework DLLs, the way to distribute them just is easier by installing the targetted .NET framework itself or making it a prerequisite.

Bye, Olaf.

 

[Nro]

Thanks Olaf. I think you exactly understand what I want to achieve.

My VCX libraries has as a lot of PEM, and the new project I’m working on doesn’t need all of this code.

For example, I have a class that is returning a message from a text file, in English or in French depending of some parameters. I think it will be useful in my new project, but I don’t want to re-write the whole thing, and I don’t want to include the VCX file (with all the other classes) into my new project.

Most of the class I want to include are based on Custom class, and I don’t really care if they want to decompile it.

Maybe I found something OK, but I’m not sure if it’s viable

First, I can use all the class code I already write. For example;

*  TestClass.prg

DEFINE CLASS _ocustom AS custom
	cmessbox = ""
	nmesscode = 0
	Name = "_ocustom"


	PROCEDURE Init
		WITH THIS
		 .cMessbox = ""
		 .nMessCode = 0

		ENDWITH
	ENDPROC


ENDDEFINE

I compile TestClass.prg to create and .FXP

Now, I can distribute the FXP, no source code is visible (maybe they can decompile it, but it’s ok)

Then, I start a new project and now, I can sub-class code, and instantiate it:

* test01.prg

LOCAL lom AS Object

lom = NEWOBJECT("dev_oCustom")

MESSAGEBOX(lom.cMessbox, 0 + 64, "Test FXP")

lom = NULL


DEFINE CLASS dev_oCustom AS _ocustom OF "TestClass.fxp"
	* Sub class .FXP
	PROCEDURE init
		DODEFAULT()
		THIS.cMessbox = "Test Sub-Class"
	ENDPROC

ENDDEFINE

Finally, I can distribute my new classes, and the one I already wrote in FXP, without the source.

Thanks for your input.

Nro

 

[Olaf Doschke]

I already said you can't subclass from FXP only from PRG, or are you saying you tried and that worked?

Even if, your main problem is you want to create slimmer subclasses, I wouldn't address that by subclassing, you're forwarding all the burden of the oversized class and add another level to it. Do you think this will speed up the instantiation? If you instanciate a class you instanciate the whole inheritance branch back to the native base class, so you only add to that.

As your main issue is you want to subclass an existing class and shrink it down to less PEMS, then you should not subclass the latest class but modify it for the new project. You could create an assistant displaying a classes PEMS for selection to remove them and then rewrite the class without the removed PEMS, wouldn't that help much easier?

Bye, Olaf.

 

[Olaf Doschke]

OK, now I tried DEFINE CLASS xyz As abc OF ...some.fxp and that indeed works. But you're still forwarding all the PEMS you don't want to inherit. You for example inherit all if you don't even have one line of code between DEFINE and ENDDEFINE, then you have the 1:1 inheritance of the parent class with all its PEMS. Even if you make PEMS hidden or private they are still there, you don't have less load in memory, that will really need a rewrite of the class instead of a further inheritance level.

In C# you can have virtual methods you can override in the child class and then you don't inherit it, it's af if it wasn't there, we don't have that kind of inheritance in VFP. You'll also see the hidden and private methods and properties in intellisense.

Overall you're not simplyfying your class hierarchy the way you want to inherit it, if you want the simplest version of a class to use you have to preplan that and have the class level you want to use in the class hierarchy before the most complex class, have a vcx per class inheritance level and then don't distribute the most complex levels, that would save.

If the size/bytes won't matter and the main thought is on light weight intellisense, then write a wrapper class, that means a class that loads the too complex class as it's subobject and uses it. That way you can let the wrapper only have the PEMs you really went to use, but all the methods you want to inherit need an implementation to forward the call of them to the inner sub object. So that's a little cumbersome. I did that in one case and used the separation to make the parameter type checks and assertion in the wrapper and let it have some configuration functionality about the inner main object.

For your situation redesigning the class family in a way you can pick the level of complexity needed for the current project would be easiest, I think.

Bye, Olaf.

 

[Nro]

Thanks Olaf.

Sub-classing from a .FXP is in the VFP documentation.

Now my first thought was to “hide” code of my distributed application. You are right, it’s not possible to derivate a class from a classlib compiled in an .APP, but it’s possible from a pre-compiled FXP ad not an external PRG.

From now, I can create a project (PJX) with some program code (PRG) that’s using the classlib contain into the FXP. When I compile the project to create an EXE, I may “Exclude” the FXP library from the project, allowing my executable to be distributed separately from the FXP. The size of the executable is a lot smaller because all of the complex code for my base classes and tools are inside the FXP.

Now, is it faster? I don’t know. Is it stable or easy to break? I’ll have to test it.

I understand that if I sub-class one base class and create a new instance, the new object will have all the PEM’s available, but it is only pointers. My FXP classlib is separate from the main project, so the resulting EXE will be a lot smaller and will only contains the new code I’ll write for the new class. Is it right?

Like I said, I only want to use custom classes, and I think the maximum of levels of sub-classing is around three or four, so I think I won’t be a lot of work validating them and viewing the hierarchy of the structures.

I hope it’s a little bit understandable (English is not primary language)

Thanks again for you input.

Nro

 

[Olaf Doschke]

You have to distribute the FXPs together with the EXE, or it's put into the EXE at compilation anyway, as VFP automatically adds parent classes and libs into compilation. Anyway, overall you won't save bytes.

Bye, Olaf.

 

[Nro]

Yes, I don’t save bytes for the first installation (EXE separate from FXP), but the upgrades of the main exe will be smaller if I don’t distribute FXP (static classes).

Anyway, I think this solution is not very good because I have to maintain 2 separate series of code, one visual VCX’s then and some PRG’s for the purpose of compiling FXP. I think Foxpro was not design to work that way.

Thanks again

Nro