New idea for feature re: object use

T Chap

What about an application or feature in BST or Proptool that allows the user to merge objects into a single main program, versus using a main program that has to work with a lot of objects? Upon a special compile mode, everything becomes one big file containing the objects methods. The benefit being that there would be no more need for pointers, and cog sharing hassles, simply use the same variables between all cogs. In the future if a separate object gets modified, the special compile just replaces the contents in the main 'merged' method with the updated contents from the objects SPIN file, so that the main program goes out, compares and if there is a changed object file, bring in the changes. If there are new methods added to the OBJ, merge in the new methods.

Obviously this would require that some objects get modified to no longer required pointers (if necessary), but I think this would be a very useful system. In this way of thinking, you still have object files that can be used in other projects, but the main program is much simpler as a single standalone program.

Mike Green

One of the main advantages of using objects is that the names are hidden. If you include two slightly different objects, they can have the same variables and the same method names and there's no conflict. You can get around this by modifying the names to include the name of the object, but then you lose the ability to use the "internal" names of the variables or methods. With objects, you can have multiple copies of the same object and there are no conflicts. The same isn't true of your scheme unless you modify the names to prevent conflicts.

Another advantage of objects and the hiding of names is that you can have two objects that appear functionally to be identical. They have the same public methods and they define the same constants, but they're implemented completely differently inside. They have different variables, different amounts of variable space, different private methods that do somewhat different things, yet appear to the outside world to be identical. For example, one implementation might be relatively slow, but very efficient in terms of space used. The other implementation might be very fast, but a hog in terms of memory use.

jazzed

Mike mentions good advantages of objects.

Still, there are cases where merging code from files is useful: PASM source or DAT sections that would contain bit-map sections for example.

Having to copy PASM code by hand from one file to another is painful and error prone.

If one could include source into a DAT section with a directive (file is not good enough), merging PASM source among files would be so much easier. It is possible to do this today with an existing third-party tool (cpp for cygwin/linux), but this makes the source messy and the tools are not easily available to most windows users.

Cheers.

T Chap

I agree there are advantages and disadvantages. I will add another idea that is actually much more of value to me if it were possible. In my case with the Prop, I ONLY work with one program for one specific product, it is very rare and only in a test case to work on another program. The one program is very large, and has a ton of methods. It constantly gets renumbered after some new info warrants a new rev number. Also, the file always gets saved per client with the clients name attached to the latest rev number, so that I can always get back to the version the client has in case I need to troubleshoot, or they have custom features that are not the norm. So what happens is, I may be working on a mod for a client, and find out, hey this is very cool and I need to use this from now on , so that new method may then become the default method for all future use. However, it would be much easier to have all of the methods saved as separate 'raw method files' with their own file names, not objects in the sense that we think of now. I am speaking of a similar situation as above regarding copying objects, where the main program goes out, and copies the separate 'method files' into the main program when compiling. So, if I need to update 10 clients programs that are all custom, but I want to NOT have to copy and paste separate methods back into the main program, the system of having a special feature to copy the so called 'raw method files' back into the main program would be very beneficial. This is probably not how most people work, but when working only with one based program file, it makes sense. So, to simplify, a method can be stored as a SPIN file, but not dealt with as an obj, but it gets copied back into the main program simply by writing PUB methodfile in the main program, the app goes and gets the methodfile.spin content and copies it into the main method under PUB methodfile. This is the similar concept to the copy/paste for objects mentioned in the beginning. Obviously this gets more complex as the issue of how to NOT replace custom methods with the externally saved raw method file, but something as simple as naming the custom method in the main program with a variant would force the app to not overwrite it. Only if there is a same file name, and the contents are modified in the raw method file, will the app go get it and replace the contents of the main program.

Mike Green

What would accomplish this sort of thing for you would be some kind of "#include" statement along with conditional compilation like "#if" / "#then". This setup exists in C and in many compilers and assemblers. There are general purpose source macro pre-processors like M4 that will do this for you.

Homespun is a 3rd party command line Spin compiler / PASM assembler that is cross platform (Windows / Linux / MacOS) and has the conditional compilation along with simple macros (here).

BST is another 3rd party Spin compiler / PASM assembler that includes an IDE although does come in a command line version. It has much the same features as Homespun plus a few of its own (here). I use BST under the MacOS for all my Propeller development.

Neither one has an "#include" statement at present.

T Chap

Thanks for the info. I can only use BST at the moment, the program is so long that it would be impossible without folding methods. What I am considering if doable, is a new app with RealBasic, that is just a text editor that will allow folding, and allow my own system of hosting raw method files outside of the main program, and the main program will go to the raw method file and copy it in if needed, then see if there is a way to have the text editor save the file and run bstc/bstl. There is the issue of losing all the features of BST though, so this may be pointless. I am just thinking out loud hoping for a solution to surface. Probably the text editor would be used only in rare occasions of needing to update other/older programs with the latest features, then just export the text file and reload in BST to work normally.


Some features of the text editor:

The app will look at a folder to see if a file is present with the method name, if not, it creates a file there with the method name for future use.

If you modify a method in the main program, you have an option to update the raw external method file.

Upon compile, the main program will look at the raw external method files, compare, and load in the external version as a default, probably with a warning and options to skip, update the external with the current method.