The BaseFoo and Foo classes are designed so that they both have to be present. The BaseFoo class is contains code that can be regenerated and any modifications should be made to Foo. One case for referencing Foo in BaseFoo is when instantiating a new Foo as happens in the copy method. BaseFoo is abstract as there should not be any instances of BaseFoo.
If you want to create a separate package, just extend from Foo in the new package. Though I do not see the reason for doing so. john mcnally Robert Jenks wrote: > > Hi, newbee here :-) I went back 3 months of list archives and couldn't find > a mention of this, but I'll apologize in advance if it's been discussed > before. > > Playing around with Torque (cool stuff dudes!) and have a question about > the OM generated classes. I prefer to keep my auto-generated and human > generated source files in separate directory trees, therefore I modified the > om/Control.vm template and commented out the calls to ExtensionObject and > ExtensionPeer so that the skeleton sub-classes don't get generated. I'll > simply write them myself in a separate directory tree and compile both > directory trees together. > > All is fine and dandy until I find that the Base classes won't compile > without the sub-classes. Is there a reason that BaseFooEntity has multiple > references to it's sub-class (FooEntity) or is this a template bug? This > seems to be true of all the Base classes. They all depend on their skeleton > sub-classes. > > Thanks, > -Robert > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
