[Smtk-developers] Pie in the sky

[TJ Corona]

> Since no one appears to mind libraries with some source-dir overlap, maybe we could eliminate core and extensions at the top level and just have
> 
>  smtk/attribute/core
>  smtk/model/{core, polygon, discrete, ...}
>  smtk/mesh/{core, moab, vtk, pumi, ...}
>  smtk/qt
>  smtk/vtk
>  smtk/paraview/{server, components, ...}
> 
> and just make one library out of smtk/*/core. Or to be more consistent,
> 
>  smtk/core/{attribute, mesh, model, operation, resource}
>  smtk/{discrete, mesh, polygon, ...}/{operators, environment, ...}
>  smtk/{qt, paraview, python, vtk}

We are still on the topic of pies in the sky, right? I would really, really like to see the smtk core library turn into something more granular. In addition to having smaller libraries, forcing developers to be mindful of directional dependencies would enforce better coding practices. While the directory structure neither helps nor hurts this goal, a good first step would be to remove core as a directory. 

> On Mar 21, 2018, at 8:51 AM, David Thompson <david.thompson at kitware.com> wrote:
> 
>> I’m ok either though I tend to like keeping “like” files close so having a json or pybind subdirectory in the same directory as the source file does remind you that you might need to make changes to them as well.
> 
> I agree that's useful. It sounds like everyone's in agreement not to force separate directories for each library's source files -- at least for wrapping and serialization.
> 
>> What about the stuff under bridge :) - should it be 
>> 
>> smtk/extension/session/polygon,
>> or
>> smtk/extension/modeler/polygon
>> or  maybe 
>> smtk/modeler/polygon?
> 
> In my examples, I put it under extension/smtk/model/polygon so it would live in the smtk::model::polygon namespace. That eliminates the need for another namespace like kernel, session, or modeler. I would prefer to keep namespaces shallow and broad, however if you want to be more explicit at the top-level of SMTK's sources, we could split the extensions directory into different functional categories:
> 
>  modeler/smtk/model/polygon
>  modeler/smtk/model/discrete
> 
>  mesher/smtk/mesh/triangle
>  mesher/smtk/mesh/netgen
> 
>  gui/smtk/qt
>  gui/smtk/paraview
>  gui/smtk/vtk
> 
> instead of just putting them all in extension/smtk/...
> 
> Since no one appears to mind libraries with some source-dir overlap, maybe we could eliminate core and extensions at the top level and just have
> 
>  smtk/attribute/core
>  smtk/model/{core, polygon, discrete, ...}
>  smtk/mesh/{core, moab, vtk, pumi, ...}
>  smtk/qt
>  smtk/vtk
>  smtk/paraview/{server, components, ...}
> 
> and just make one library out of smtk/*/core. Or to be more consistent,
> 
>  smtk/core/{attribute, mesh, model, operation, resource}
>  smtk/{discrete, mesh, polygon, ...}/{operators, environment, ...}
>  smtk/{qt, paraview, python, vtk}
> 
> would put all of smtkCore in smtk/core/* (along with its json, pybind, and environment libraries). That simplifies the directory layout a bit, but now what are the namespaces? Would we have smtk::core::model but smtk::polygon for the polygon session? I like keeping namespaces that correspond to directory trees.
> 
> 	David
> 
>>> On Mar 20, 2018, at 4:33 PM, David Thompson <david.thompson at kitware.com> wrote:
>>> 
>>>> I vote for putting them in the subdirectories of whatever source they wrap/serialize since each of them is associated with a specific file/class.
>>> 
>>> I think TJ was hinting that we we do this:
>>> 
>>>> core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx}
>>>> core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx
>>>> 
>>>> extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx}
>>>> extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx
>>> 
>>> then everything in core/smtk is in the smtkCore library; everything in the core/json directory could live in an smtkCoreJSON directory, etc. In general, the pattern would be that no two libraries have code in the same source directory.
>>> 
>>> 	David
>>> _______________________________________________
>>> Smtk-developers mailing list
>>> Smtk-developers at smtk.org
>>> https://smtk.org/mailman/listinfo/smtk-developers
>> 
> 
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> https://smtk.org/mailman/listinfo/smtk-developers