RE: will commit unless I hear objections...

Hi Christian,

At 01:15 PM 5/30/2003 -0600, you wrote:
>Hi Jake,
>
>Well, not to be argumentative, but... ;-)

heh :-)

> > I plan to change the name of DefaultDOMFactory.java to
> > XMLCStdDOMFactory.java.
>
>I'm happy with the current naming, but it you really want to do this, then I
>think it should be changed to DefaultXMLCDOMFactory. The reason for this is
>that everywhere we have a "default" implementation of an interface, it
>always follows the naming convention of Default<interface name>, and if this
>is going to be the default implementation for the XMLC DOM factory, then I
>think it makes sense to use the name I suggested above.

Hmm.... I guess I can see your point about being consistent with using the 
"Default"... naming scheme.  However, naming it DefaultXMLCDOMFactory 
doesn't tell you what it really is.  The underlying implementation that it 
backs is, quite specifically, the XMLCStdFactory.  There are a couple of 
other factories out there (some that have been removed from XMLC as 
well),  one being the XMLCDeferredParsingFactory which, IMHO, should be 
used as a "default" over the less capable XMLCStdFactory.  In fact, I have 
heard Richard Kunze mention removing the XMLCStdFactory from XMLC entirely 
since XMLCDeferredParsingFactory does everything that the latter does, only 
better and with much more functionality.  Claiming one to be a "default" 
really makes a value judgement about which one should be used.

There is one way that I can think of which might mitigate our differences 
of opinion here;  if we prefix all the Barracuda implementations with 
"Default".  Hence, we would have DefaultXMLCStdDOMFatory and 
DefaultXMLCDeferredParsingDOMFactory.  This meets both our needs.  However, 
it would require me to rename the XMLCDeferredParsingDOMFactory which might 
cause confusion since that is now being used in all the application 
assembly files in Barracuda proper, BarracudaDiscRack, and both contrib 
projects (as well as the test cases I just modified to work with the new 
behavior of the DefaultDOMLoader).  I am ok with doing that if everyone 
else is.  Are you ok with this?  Otherwise, I'd rather stick to my original 
proposal of XMLCStdDOMFactory especially since I think the DOMFactory 
implementations are kind of a special case as they are so implementation 
specific unlike, as I've mentioned, implementations of the 
DOMLoader.  There is, generally, only one way to do dom loading for a 
specific implementation.  However, there may be many different DOMFactories 
that back a general implementation which a single dom loader might 
support.  See more below


> > I am also tempted to do the same thing for the DefaultDOMWriter
> > since it is XMLC specific.  The proposed name would be XMLCDOMWriter.
>
>Once again, I'd prefer DefaultXMLCDOMWriter, for the same reason as given
>above.

This makes perfect sense since there aren't, in general, multiple ways to 
do dom writing with XMLC like there are multiple xmlc dom 
factories.  However, the question still remains about how many apps this 
name change might break since people probably reference DefaultDOMWriter in 
their code.  I can live with that if others can, but I wouldn't do this 
without a lot more people than you and me thinking it is ok.

> > Having a "default' doesn't really make must sense here because it
> > isn't generic like, for instance, the DefaultDOMLoader is.
>
>One other thing to mention is that even though there may not be multiple
>XMLC factories/writers at this point, the whole point of interface is

See above.  There *are* multiple xmlc dom factories by 
necessity.  Necessity only forces a single xmlc dom writer, though.

>allowing other implementations, so its always possible other ones might come
>along. In which case, I think "Default" is still entirely appropriate.

Other implementations duplicating/extending the defaults or other 
implementations providing functionality for a completely separate DOM 
implementation than XMLC?  If you mean the former, then I agree with you 
and something like the name DefaultXMLCStdDOMFactory makes sense since 
someone might want to extend that as MyXMLCStdDOMFactory and provide their 
new and improved implementation backing the XMLCStdFactory, but if you mean 
the latter, "Default" doesn't add any useful semantics here.  For instance, 
we could separate implementations with names such as XMLCStdDOMFactory, 
XMLCDeferredParsingDOMFactory, Xerces2DOMFactory, etc...  People could 
still create MyXMLCStdDOMFactory and extend XMLCStdDOMFactory.  "Default" 
is implicit and would really be redundant since by proving a single 
implementation of the XMLCStdDOMFactory in the Barracuda source it is 
already, quite obviously, the "default" implementation.  So, actually have 
a fundamental problem with the whole "Default" naming issue in the first 
place, but I'll accept that it is a naming convention used by much of 
Barracuda and we have a tacit requirement to stick with it.  Given that 
(and moving back to the original question), I hope you are arguing the 
former and not the latter, otherwise, IMHO, your argument not logically valid.

> > I propose adding the various specifyLocalEventInterests() and
> > specifyLocalEventAliases() that DefaultEventGateway provides to
> > the EventGateway interface.  That way, we wouldn't have to do the
> > kludgy check for a specify implementation of EventGateway in
> > DefaultApplicationAssembler.  Comments?
>
>I'm not opposed to this.

Would we also want to add the registerLocalEventInterests() and 
registerLocalEventAliases() to the interface as well?  I forgot to mention 
those before.

Jake

>Christian
>----------------------------------------------
>Christian Cryder [[email protected]]
>Internet Architect, ATMReports.com
>Barracuda - http://barracudamvc.org
>----------------------------------------------
>"Coffee? I could quit anytime, just not today"
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of Jacob Kjome
> > Sent: Friday, May 30, 2003 12:30 PM
> > To: BarracudaMVC Users List
> > Subject: [Barracuda] will commit unless I hear objections...
> >
> >
> >
> > I plan to change the name of DefaultDOMFactory.java to
> > XMLCStdDOMFactory.java.  I don't think this should cause any
> > problems since
> > nothing in Barracuda references DefaultDOMFactory, nor do I believe that
> > anyone likely has referenced it themselves since, in the past, the
> > DefaultDOMLoader used it by default and I doubt anyone changed
> > that default.
> >
> > The reason for the change is that the implementations of
> > DOMFactories are,
> > well..., implementation-specific and it makes it much more clear
> > as to what
> > implementation is being used if the name of the class makes this
> > obvious.  Having a "default' doesn't really make must sense here
> > because it
> > isn't generic like, for instance, the DefaultDOMLoader is.
> >
> >
> > I am also tempted to do the same thing for the DefaultDOMWriter
> > since it is
> > XMLC specific.  The proposed name would be XMLCDOMWriter.  However, this
> > change would be more problematic since there are lots of cases in
> > Barracuda
> > where DefaultDOMWriter is directly referenced and I imagine this
> > is true of
> > applications created by those in the Barracuda community.  So, I wouldn't
> > make this particular change without the explicit "ok" of the community.
> >
> >
> > One other thing.  Currently the DefaultApplicationAssembler does
> > a check of
> > whether a particular event gateway is an instance of DefaultEventGateway
> > when evaluating the <event-interest> and <even-alias>
> > configuration options
> > in the assembly descriptor.  If it isn't, then it throws an
> > exception.  This means that anyone who creates their own application
> > assembler and supports specifying event interests and event alias' just
> > like DefaultEventGateway, but doesn't extend DefaultEventGateway,
> > will find
> > that these configuration options are unavailable to them.  I
> > propose adding
> > the various specifyLocalEventInterests() and specifyLocalEventAliases()
> > that DefaultEventGateway provides to the EventGateway interface.
> > That way,
> > we wouldn't have to do the kludgy check for a specify implementation of
> > EventGateway in DefaultApplicationAssembler.  Comments?  Again, I
> > wouldn't
> > make this particular change without an explicit "ok" from the community.
> >
> > Jake
> >
> > _______________________________________________
> > Barracuda mailing list
> > [email protected]
> > http://barracudamvc.org/lists/listinfo/barracuda
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda