Daniel,
> Hence, the main thing you get by putting getters and
> setters in front of its fields is complexity,
> convenient places for gdb breakpoints, and extra code
> to deal with when maintaining and accessing.
Plus, we can
- ensure nobody ever does anything unexpected,
which ultimately makes code more robust and harder
to break. That is what is most appealing to me.
- quickly see who needs read only access, and who
modifies.
> I just got sick of re-doing the plumbing every time
> a new feature needed some statistic or characteristic
> that was already derived but sent directly to where
> it used to be needed.
I think that is an indication things are not
compartmentalized correctly yet :)
> If you can find portions that are really
> only used by one plugin, we can move it to that plugin
It is the case for _restrictors, it could easily go into
the restrictorPlugin, but... testQueryAnalysis is checking
few things relates to _restrictors, so, how would you
implement that? We could iterate through the list of plugins
that QuerySession keeps, find the restrictorPlugin and
do the calls testQueryAnalysis needs (what is the number
of restrictors, give me the first restrictor). Is it too ugly?
Thanks,
Jacek
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1
