As we write the API docs it's become apparent that the naming conventions in the Tripal Chado api docs are not consistent, there is a mix of tripal, tripal_chado, and chado.
The suggestion is to change all the names to chado_function_name and deprecate the old names.
For example:
function tripal_get_publication would become function chado_get_publication and tripal_get_publication would end up in a tripal_chado.DEPRECATED.api.inc pointing to the new chado_get_publication, something like this:
function tripal_get_publication($identifiers, $options = array()) {
chado_get_publication($identifiers, $options);
}
Thoughts are welcome!
I like changing all API functions in the tripal_chado module to have just a 'chado_' prefix as opposed to 'tripal_chado' as the prefix as it's shorter and I think a namespace that probably won't ever have a conflict...
Is this specific to the API functions carried over from Tripal2 or does it include new API functions in Tripal Chado?
When we last went through making API functions consistent, we went with
tripal_[verb]_* for general Tripal API functionschado_[verb]_* for general Chado API functions tripal_chado_[verb]_* for API functions in specific modules (e.g. publication, organism, etc.)So while it looks inconsistent now, that's because it has all been lumped together. There is a reason to it ;-)
That said, now that they are all lumped together in the single Tripal Chado module, I think I'm content condensing the tripal_chado_[verb]_* to chado_[verb]_*.
What are the tripal_[verb]_* functions in tripal chado? We should be careful of these...
I'm a bit confused now. Most of the methods in the tripal_chado/api/module folder all start with tripal_[verb]_* instead of tripal_chado_[verb]_*.
Excluding those files the tripal_[verb]_* are:
tripal_chado.cv.inc
tripal_replace_chado_tokens
tripal_chado.mviews.api.inc
tripal_edit_mview
tripal_get_mview_id
tripal_refresh_mview
tripal_get_mviews
tripal_delete_mview
tripal_populate_mview
tripal_chado.query.api.inc
hook_tripal_get_schema_name_alter
tripal_chado.semweb.api.inc
tripal_associate_chado_semweb_term
tripal_get_chado_semweb_term
tripal_format_chado_semweb_term
tripal_get_chado_semweb_column
I suspect that the tripal_chado_[verb]_* may be in the legacy folders and are now deprecated.
Here is a suggestion for API documentation naming
| Module Type | Naming Scheme | Notes |
| ------------- |-------------| -----|
| Tripal Core Modules | tripal_[verb]_* | This includes tripal, tripal_ds, tripal_bulk_loader, tripal_ws, etc. modules. |
| Tripal Chado | chado_[verb]_* | For backwards compatibility we will keep Chado API calls without a 'tripal' prefix for all API functions in the tripal_chado module. This will be used for all API functions in the tripal_chado module. |
| Tripal Storage Modules | tripal_[service]_[verb]_* | For all future Storage API (other than Chado) those will have a 'tripal' prefix. The [service] tag would be the name of the storage service (e.g. 'neo4j', 'mongodb', etc.)|
| Tripal Extension Modules | [module_name]_[verb]_* | Extension modules authors are encouraged to name their modules with a 'tripal' prefix, thus API function calls should also begin with tripal in that case. | |
I like your suggested naming @spficklin.
At first I was hesitant to change the current tripal_[verb]_ functions in tripal chado... But after looking at @shawnawsu list above, I agree that all those functions should be chado_[verb]_ to reduce conflict with similar support for alternate storage backends.
tripal_chado.cv.inc
tripal_chado.migrate.api.inc
tripal_chado.mviews.api.inc
tripal_chado.query.api.inc
tripal_chado.semweb.api.inc
Looks good! My only comment is: do you think we need the double chado in some of the names (e.g. chado_get_chado_tokens)? I think the fact that they are specific to chado is implied by the first chado making the second one redundant.
I would suggest,
- tripal_get_chado_tokens --> chado_get_chado_tokens --> chado_get_tokens
- tripal_replace_chado_tokens --> chado_replace_chado_tokens --> chado_replace_tokens
- tripal_add_chado_semweb_table --> chado_add_chado_semweb_table --> chado_add_semweb_table
- tripal_associate_chado_semweb_term --> chado_associate_chado_semweb_term --> chado_associate_semweb_term
- tripal_get_chado_semweb_term --> chado_get_chado_semweb_term --> chado_get_semweb_term
- tripal_format_chado_semweb_term --> chado_format_chado_semweb_term --> chado_format_semweb_term
- tripal_get_chado_semweb_column --> chado_get_chado_semweb_column --> chado_get_semweb_column
Thoughts? @spficklin do you think that looses too much info in favor of being succinct?
Yes, I agree, let's take out the double chado.
Ok, I've made these changes:
Changes in the tripal_chado.module.DEPRECATED.api.inc:
tripal_chado.analysis.api.inc
tripal_chado.contact.api.inc
tripal_chado.cv.api.inc
tripal_chado.db.api.inc
tripal_chado.feature.api.inc
tripal_chado.organism.api.inc
tripal_chado.phylotree.api.inc
tripal_chado.pub.api.inc
tripal_chado.stock.api.inc
Most helpful comment
tripal_chado.cv.inc
tripal_chado.migrate.api.inc
tripal_chado.mviews.api.inc
tripal_chado.query.api.inc
tripal_chado.semweb.api.inc