Re: Code/Arch Team Meeting 6 PM Eastern, Fri March 9, 2012.
- --- In firstname.lastname@example.org, Martijn Verburg <martijnverburg@...> wrote:
>SOMETHING needs to make it onto the Wiki; IMHO the "why" of the decisions is not best captured in Javadoc - it needs to be at a higher level.
> Hi all,
> So a couple of questions/comments from the meeting log:
> 1.) Overall comment - That was a really useful read and it's great to
> see some more monolithic stuff get split out!
> 2.) ReferenceFacade question:I'm not sure we want a contract there - I tend to try to avoid creating situations like that (because unless it's a template, it's forgotten anyway, and templates can produce problems from forcing a certain hierarchy and certain assumptions - they are good in certain cases, but I'm not sure it's the best solution here)
> Connor states that "its up to the facade layer implementation to make
> sure that these references stay up to date when changes in the core
> occur". Is this something that we can guide the developers to
> remember by enforcing a contract (perhaps an interface) here?
I think the solution here is to take the event driven core (Facets) and attach it to the event-desiring UI. Right now, PlayerCharacter.java is a disservice in this, in that it basically presents a static front (basically no events as passed out of the facets).
As the facets are updated to indicate what really is the presentation (output) layer vs. the core facets, then I think it makes sense to have the Facades directly subscribing to core events.
> 3.) LstSystemLoader DeprecationI tend to agree here. Having a pointer as to where things go should always be a requirement when things are deprecated.
> I noticed this in the code when some new deprecation warnings popped
> up. Sadly the LstSystemLoader javadoc didn't tell me what it had been
> replaced by ;-). I assume it's OK if I reference the 3 new classes in
> the Javadoc for others to follow?
We also have some ambiguity in what it means to be deprecated. I'm not terribly thrilled with "preventive deprecation" (as we seem to have in SettingsHandler), when there is no place to point and say "this method is now over here". I'd rather stick to deprecated means there is already another way to do it, so we don't have warnings that really can't be fixed.
For those that don't like my perspective on deprecation of SettingsHandler, go un-deprecate it and look at the change in warning count in pcgen.gui2.* ... the hundreds (thousands?) of warning messages that disappear then allows the few dozen remaining warnings to stand out, some of which need some analysis as to whether they are real problems... (I think some are problems, but I sense they are hidden in the overwhelming list of deprecation warnings)