Closed bmcfee closed 9 years ago
.. and while we're at it, how about renaming jams.pyjams
to jams.core
?
sounds sensible on both accounts
Ok. I'll hack it in a branch and then we can reconvene when it's done.
+1 to all.
On Wed, Jul 15, 2015 at 2:04 PM, Brian McFee notifications@github.com wrote:
Ok. I'll hack it in a branch and then we can reconvene when it's done.
— Reply to this email directly or view it on GitHub https://github.com/marl/jams/issues/49#issuecomment-121695295.
What do people think about moving all schema management functionality into a single submodule? We currently have the
ns
module for handling dynamic namespace schemata, and the core jams schema is handled directly inpyjams
.Since these two things are not entirely independent -- validation code needs to touch both, for example -- I'm thinking it would be simpler if we move
jams.ns
tojams.schema
and then have all schema loading/manipulation done from there.The reason to do this comes from the
validation
method for annotations, which has to supply the schema for aSparseObservation
object to the namespace schema constructor. This is the only value ever passed in tons.schema()
, so it's silly to have a parameter and condition checking for it. We can't just hard-wire the current implementation though, since it would introduce a circular dependency in the submodules.Moving
pyjams.__SCHEMA__
to reside in the same submodule fixes the dependency cycle and simplifies some api and internal logic. Also, in case we do decide to include other schemata later on (eg, collections), having a catch-all submodule for schema handling makes a lot of sense.From the end-user perspective, nothing important should change.
Some of the internals to
pyjams
will need to change if we do this, but it's simply a matter of pointing to the new location of the schema object. Similarly, tests and docs will have to change, but that's pretty trivial.Opinions?