Class/method naming conventions (yes, again....)

[Ian Young]

On 4 Oct 2013, at 21:49, Brent Putman <putmanb at georgetown.edu> wrote:

> We are
> assuming a release in the near future of java-support 2.0.0 to support
> some of Ian's work.  I have forgotten exactly what the timeframe for
> that is, but do we want to implement the naming convention change for
> java-support 2.0.0, or just defer it to a later release (which of
> necessity be a new major version)?  We have a lot of this renaming work
> to do across all the projects, so maybe it's best to do it all at once,
> rather than piecemeal?

I also have addressing the new conventions as an open issue for the MDA, but it won't be looked at in any depth for the upcoming release. I am fine with an incremental approach to the agreed conventions both for the MDA (until it reaches an arbitrary 1.0) and for anything it relies on. So I am fine for this to be deferred for now.

> My rationale is that for example you're not working with an instance of
> an "HTTP client"  or an "HTTP request" (in some general sense), but
> rather specifically an instance of a thing called "HttpClient" and
> "HttpServletRequest".  So basically treat it as an opaque, immutable
> name, not an acronym.
> 
> Note that this cuts both ways, e.g. we have a UriSupport class with
> manipulates java.net.URI instances and so would become URISupport. 
> 
> Opinions? Dissent?

I can accept that reasoning, but I would probably also be fine with strict adherence to the opposite convention too so that doesn't tell you much. I guess the thing to do is talk it through at the next dev meeting, decide one way or the other and then document it so we don't forget.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20131007/a117eb5e/attachment.bin