Hi Sébastien.[1]
On Sun, Oct 02, 2011 at 01:34:50PM +0200, Sébastien Brisard wrote:
> Right. I tend to like self-describing names also good. In french
> (you've rightly spotted a non-native speaker...), an "operator" is not
> necessarily linear, and I think same goes to english terminology
> (could you confirm please). So a linear operator is not exactly
> identical to an operator.
> However, as Phil pointed out, the distinction does not really matter
> when it goes to exceptions. So maybe I could replace LinearOperator
> with Operator in exception names. For other classes, with more
> mathematical meaning, we could keep LinearOperator, even if it makes
> for very long names. Would that suit everyone?
> Sébastien
>
> 2011/10/2 Ted Dunning <ted.dunn...@gmail.com>:
> > On Sat, Oct 1, 2011 at 10:58 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
> >
> >> > As for shortening the name, I'm all for it. For consistency, I would
> >> > do it for every class matching the pattern *LinearOperator* if you all
> >> > agree. Also, I think that "linear" is as important as "operator" in
> >> > "LinearOperator" (even if lilnearity might seem an obvious feature,
> >> > provided all the classes we are discussing are actually located in the
> >> > linear package). So what do you think of LinOp as a compromise?
> >> > Something like RealLinOp instead of RealLinearOperator,
> >> > NonSquareLinOpException, etc...
> >>
> >> I like full words. I don't know about "linear" vs "operator" in
> >> "LinearOperator" but I think the "linear" can safely be dropped in
> >> "SingularLinearOperator."
> >
> >
> > Abbreviations don't really shorten names. They just make them impossible
> > for non-native speakers to guess. And if abbreviations are done by
> > non-native speakers, they become impossible for anybody to guess.
> >
> > +1 to avoiding abbreviations where possible.
+1 also because it is the standard style in Java (for better or worse).
As I've pointed out somewhere else[2], to avoid an avalanche of exception
classes[3], the default assumption should probably not be that every concept
embodied in a Java class must have its own set of subsumed exceptions.
Rather, failures are more of a concern that is cross-cutting along possibly
unrelated (algorithm) classes. E.g. even if an operator is not always a
linear operator, couldn't it be that using one or the other could trigger a
"SingularOperatorException" (where the "ExceptionContext" would be used to
more fully describe the specifics of each case)?
[1] A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
[2] https://issues.apache.org/jira/browse/MATH-485
[3] This is the same problem as the numerous error messages in the
"LocalizedFormats" enum.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
