<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I thought of one other thing that is now starting to lean me more
towards the constants approach: continuing to use namespaces as the
example, pre-registered namespaces consist of both prefixes and URIs,
so there may be a need for either/or, meaning the method approach might
start getting pretty unwieldy and start "littering" the enclosing class.<br>
<br>
John P. A. Verhaeg wrote:
<blockquote cite="mid:483EC636.1010402@redhat.com" type="cite">While
working on the XML sequencer, I determined that I will need
access (via the SPI project) to some "well-known" namespace URI's in
order to build node names, types, and path segments correctly. There
are a few options here:<br>
<ol>
<li>Define the URI's in a separate class or interface, or</li>
<ul>
<li>Con: The need for an "artificial" class just to hold
constants
always feels a little non-OO (although I guess that argument could be
made for anything that's considered globally accessible).</li>
<li>Con: It is not necessarily an intuitive place for developers
to
look when working with a particular API.</li>
<li>Pro: This could provide a "default" location to store other
constants that we determine we need during the course of development.<br>
</li>
</ul>
<li>Define them in an existing class, such as the
org.jboss.dna.spi.graph.NamespaceRegistry interface.</li>
<ul>
<li>Pro: The constants (or methods) would be defined near the
methods with which you would most likely use them, potentially making
it easier to know where to look for them.</li>
<li>Con: There may not always be an appropriate class to define
such constants (or methods).</li>
<li>Con: When the constants are appropriate for use with multiple
classes, it may be difficult or somewhat arbitrary deciding in which
class they should be defined.<br>
</li>
</ul>
</ol>
where by "define", we could either:<br>
<ol>
<li>Provide constants for the URI's (e.g., <b><tt>public static
final String JCR_URI = <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="http://www.jcp.org/jcr/1.0">"http://www.jcp.org/jcr/1.0"</a></tt></b>),
or</li>
<ul>
<li>Pro: The value of the URI would be readily apparent within
the
JavaDocs (via <b><tt>@value</tt></b>).<br>
</li>
</ul>
<li>Provide methods to return the URI's (e.g., similar to <b><tt>NamespaceRegistry.getDefaultNamespaceUri()</tt></b>).</li>
<ul>
<li>Pro: This may provide more consistency with other methods
(such
as the example above).</li>
<li>Con: Not sure if a method would be the intuitive place to
look
for a constant value.<br>
</li>
</ul>
</ol>
I don't really have a religion regarding this one way or the other. I
just want to establish a pattern up front that everyone is comfortable
with, and so I can put as little thought as possible towards this in
the future.<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
dna-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dna-dev@lists.jboss.org">dna-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/dna-dev">https://lists.jboss.org/mailman/listinfo/dna-dev</a>
</pre>
</blockquote>
</body>
</html>