Mailing-List: contact dev-help@any23.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@any23.apache.org
Date: Tue, 5 Feb 2013 00:24:12 +0000 (UTC)
From: "Peter Ansell (JIRA)" <jira@apache.org>
To: dev@any23.apache.org
Message-ID: <JIRA.12630551.1359846635733.242582.1360023852797@arcas>
In-Reply-To: <JIRA.12630551.1359846635733@arcas>
References: <JIRA.12630551.1359846635733@arcas>
Subject: [jira] [Commented] (ANY23-144) Implement comprehensive naming of
 o.a.a.api.vocab classes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ANY23-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570790#comment-13570790 ] 

Peter Ansell commented on ANY23-144:
------------------------------------

My preference is for all uppercase vocabulary class names if the commonly used prefix is an acronym, and camel-case where it is not, however, in some cases that distinction is not necessarily clear.

That is mostly based on positive experiences with the Sesame vocabulary classes, where you can use RDF.TYPE etc. The any23 vocabulary design requires access to entire vocabularies, which isn't a design constraint currently for the Sesame vocabulary classes, so there may end up being some difference still. 

The current Any23 pattern has access to vocabulary properties using DOAP.getInstance().PROPERTY, which tends to result in DOAP.getInstance() being stored in a private static final variable inside of each of the relevant extractors. The static final variable in the current extractors tends not to be named in upper-case to follow the java convention for static final variables. Instead they are named in hungarian case, with a "v" prefix to indicate they are vocabularies.

To clear up the naming I would prefer if we avoided the getInstance() pattern. We might be able to convert the vocabularies into an extensible enumeration pattern with direct access to fields along with an interface to access the entire vocabulary using a base implementation. Then we could legitimately get access to the vocabulary properties programmatically as we currently can, and we could still have RDF.TYPE like access to the properties without storing them in a local private field to get around the getInstance() call.


> Implement comprehensive naming of o.a.a.api.vocab classes 
> ----------------------------------------------------------
>
>                 Key: ANY23-144
>                 URL: https://issues.apache.org/jira/browse/ANY23-144
>             Project: Apache Any23
>          Issue Type: Improvement
>          Components: api
>    Affects Versions: 0.7.0
>            Reporter: Lewis John McGibbney
>            Assignee: Lewis John McGibbney
>            Priority: Minor
>             Fix For: 0.8.0
>
>         Attachments: ANY23-144.patch
>
>
> As Simo pointed out we currently have a rather naff naming convention for all classes contained within the above package.
> This issue should address that and rename all classes.
> Thread for reference 
> http://s.apache.org/XTk

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira