we open, parse and throw away a much larger number of TopicObjects
than change and save them.
If we differentiate normal, readonly TopicObjects
from writeable ones, we could more safely cache them, and more carefully control how we treat the lifecycle of writeable instances.
Description and Documentation
in essence, I'm thinking that a Meta Object is created with no 'Setters' and with the data more difficult to get to (in a write context), and to add a ->getWriteableCopy() that would specifically make a copy of the object that then has
and the infrastructure to write.
thus we might have a
This can give us speedup possibilities for the most common use, security, because we don't pass around a topic object that can be modified accidentally...
in combination with PromoteMetaDotPmToFirstClassAPI
, we can then use the
to re-use these static topic object to speed up repeated requests to
etc (which happen alot), and we can also quietly pre-load the cache for this info using SEARCHes, rather than accessing directory or topic files individually.
be worth considering renaming the class to avoid confusion - no idea what to tho (
class seems quite unedifying).
-- Contributors: SvenDowideit
- 14 Nov 2010
superceeded and subsumed by SimplifyTheStoreMetaSemantics
- 19 Aug 2011