🚀 go-pugleaf

If you are using SOM to develop some classes with implied metaclass
methods, be careful of the following situation:

1) Create a CSC file with a class method as the last item, i.e.

     methods:

        void foo(), class;

2) Generate the C file from the CSC file.

3) Later on, add an instance method to the end of the CSC file 
   and regenerate the C file.  SOM will append the new function
   to the end of the existing C file.

If you look at the C code that gets generated, you'll see something
like this:

    #undef SOM_CurrentClass
    #define SOM_CurrentClass SOMMeta

just before the definition for the foo class function.  But 
the SOM_CurrentClass macro will not be correct for the instance
function that you just added, because the SOM compiler forgot
to add the following lines just before the new function definition:

    #undef SOM_CurrentClass
    #define SOM_CurrentClass SOMInstance

Ooops... this causes all kinds of havoc when you try to invoke
parent methods and the like.  To be safe, I'm keeping all of my
class methods at the _end_ of the CSC and C files!

Which brings me to my biggest beef about SOM as it currently stands:
If you make major changes to the CSC file, as you are liable to do
in the beginning stages of a system, it's hard to keep the corresponding
C files in sync with the CSC file, the example above being one of the
problems you'll run into.

-- 
 Eric Giguere                                    giguere@csg.UWaterloo.CA
          So is Windows NT short for "Windows, NOT?"