That sounds like it would accomplish much of what I was looking for. So have them default to public, but then have something like baseMethodsAccessibility=protected?
Actually, after sleeping on it, part of what I was running into was the mixing of the business layer and data layer in an application I'm developing. Torque generates our data layer, of course, and then in the extension classes is where we add some additional business logic, as per some of the Torque tutorials. But it ends up being business logic and it just doesn't feel right to me to merge the business and data layers in the Torque-generated classes. Especially with the current open API to where clients could run amuck in the data layer. I liked Jeff's approach of doing the objects first and thinking about persistence later...in this application we spent a lot of time on the database schema and so perhaps we need to break free for a little while and focus just on the business layer/objects. Dunno. Either way I think the option of an open/closed API is cool. - Stephen > -----Original Message----- > From: John McNally [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 22, 2002 11:57 AM > To: Turbine Torque Developers List > Subject: Re: aggregating BaseXxx > > I would prefer that the access modifier for the methods in the BaseXXX > classes be configurable. The developer can then decide whether they > want an open api, or choose to override and open access to particular > methods. > > john mcnally > > On Mon, 2002-07-22 at 08:39, Stephen Haberman wrote: > > Also, something I'd like to see is that instead of Xxx just blindly > > inheriting from BaseXxx, being able to aggregate it. > > > > So if, say aggregateBase=true, Xxx would be created with a data member > > of BaseXxx and the wrapper methods for all of the public methods > > generated. > > > > Then users could go through and cut out the methods they don't want > > visible to the outside world, but they could still use themselves within > > the business logic via the BaseXxx data member. > > > > Sound like a good idea? > > > > Thanks, > > Stephen > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
