daniel added a comment.
Session notes from today's hackathon session:
- performance-sensitive hooks may want to cache/singletonize the instance
created from global state
- Example: MappingConfigHookHandler
- SL pattern as a stepping stone towards DI. -> Recipe for converting a
class to use DI
- Where do we get the locator from in the initial implementations (not the
idealized world)?
- ideally for non-statics you would be injecting via the constructor
- better than nothing would be to use the global service locator to fetch
the things you need
- as the refactoring spreads you hoist the use of the global locator higher
and higher
- refactoring recommendations for smart record objects recommends split to
dumb record, lookup, and store interfaces
- is lookup/store split necessary?
- is a little more boilerplate :(
- allows it to be an implementation detail whether they are same class or not
:)
- static analysis can confirm that you're not using writing code in a
read-only area
- beware runtime type hinting won't save you if the store & load are
implemented on same class! static analysis still cactches it
- most important part is splitting the record from the accessor!
- (etherpad only) bd808 would acutally prefer the data access object (DAO)
pattern where one controller is responsible for both load and store of dumb
objects using methods like "getFooWithX( $x )" and "storeFoo( $foo )". But
whatever, just kill all smart model classes plz.
- chicken-egg problem in configuration
- if we create database connections etc early on to get config, how can we
replace them afterwards? etc
- possible: method to "cannibalize" existing instance when creating 'new'
one, if the config/state is the same don't throw away the old one?
- Aaron suggests names: SalvagableService / salvage( $other )
TASK DETAIL
https://phabricator.wikimedia.org/T124792
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: Smalyshev, adrianheine, Bene, gerritbot, JanZerebecki, daniel, AndyRussG,
Spage, Aklapper, bd808, JeroenDeDauw, GWicke, phuedx, Tgr, MZMcBride,
RobLa-WMF, Ricordisamoa, Glaisher, Izno, Addshore, ClemFlip, WebIntegrity,
Avner, Lewizho99, D3r1ck01, OrenBochman, Wikidata-bugs, Malyacko, aude, jayvdb,
fbstj, Mbch331, Jay8g, Ltrlg, Legoktm
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
