Rob van Maris wrote:
MMOBjectBuilder has a datamember mmb (by inheriance from MMTable)
mmb shoud be used to get a database connection.
According to the documentation this is not true.
This is wat the javadoc (MMObjectBuilder.database), says about retrieving a
reference to the database:
    use MMBase.getMMBase().getDatabase() or mmb.getDatabase() instead
So what you are syaing is that because the javadoc says you need to use the mmb field, you shouldn't use the mmb field?

What the javadoc says is NOT that you cannot use _mmb_, but that you should not use the _database_ field in MMObjectBuilder.

This suggests the field MMTable.mmb should be deprecated as well,
No it doesn't.

This demonstrates also that a reference to an actual MMObjectBuilder
instance is not required to get a database reference.
If you belief that to be the case, the methods do not belong in MMObjectBuilder. I beg to differ though. I can think of some functionality you might want to override when you call a query on a builder, i.e. when testing/sorting/filtering on virtual fields.

The choice class vs. instance method is a conceptual rather than technical.
Technically it can be implemented both ways.
If you remove the flexibility MMObjectBuilder currently allows you, yes.
Even then the question is whether this is intended or by chance.

I am -1 for static methods, for the following reasons:

1.I am not sure if we really WANT the database to be available through a static function. We migth concider, in the future, to enable the use of multiple databases or allow mutiple clouds in one instance of MMBase, which could mean multiple instances of the MMBase.java class. The bridge already takes this into account in its design.

2. Overriding is something people will like to do. Specific builders migth need specific requirements or tests.
If you do not plan to add builder specific code to the class, and do not allow users to modify that behavior, the methods are not specific enough to be in the Builder class.
If you do not want people to override for some reason (please specify), use the final descriptor.

3. Static methods cannot be represented using an interface, which is something we might like to concider doing for some of the core classes during the Cleaning project.


--
Pierre van Rooden
Mediapark, C 107 tel. +31 (0)35 6772815
"Never summon anything bigger than your head."


Reply via email to