← Back to team overview

yade-dev team mailing list archive

directory tree

 

I have split one email to several posts on mailing list, because they
are all on different topics, so discussion should be easier.

> Oh I forgot something. We should really simplify the directory tree
> because it is not easy even for me to find where is such or such engine. I
> always have to think about what this engine is working on and then find
> the directory ... On top of that only yade-common will contain a lot of
> plugins. All other will be more limited and user's one will be even more
> simple so I think we should have something like that :
> 
> 
> plugins
>     - Data
>             - State
>             - Geometrical Model
>             - InteractingGeometry
>             - BoundingVolume
>             - PhyisicalParameter
>             - InteractionGeometry
>             - InteractionPhysics
>             - PhyisicalAction
>     - Engine
>             - Engine (or StandAlone Engine)
>             - MetaEngine
>             - EngineUnit
>     - Container
>              - BodyContainer
>              - InteractionContainer
>              - PhysicalActionContainer
> 
> And that's all. Otherwise I'm sure that everybody in 3S will be afraid
> of the tree !! Because nobody should modify official packages so if
> there are 5 or more plugins in one dir I think it is no problem and in
> user defined packages I'm sure few people will define a lot of plugins
> per dir.

Yes, I completely agree. I also have problems navigating the tree, at
first I thought that it's because this is a new version of the tree. Now
I see, that although it is very logical, its logic seems to be different
from 'developer-point-of-view'. So it is clean, but not in a way that
you think when writing code.

1. First of all I'd like to move Sensor to upper level. Everytime I look
for RenderingEngine, I expect it at the same level that Container, Data
and Engine are. It makes sense for me, because one is to store data,
another to operate on data, and sensor is to "percieve" data. I'm not
sure about DataRecorder, but I feel it should be okay to stay there
together.

2. then I'd like to move InteractionSolver one level up, because it is
so special, so it should be easier to access it.

3. I opt for moving TimeStepper also one level up (you remember that we
had problem with this one...)

4. I'm not sure what with DeuxExMachina, so I don't touch it.


|-- Container
|   |-- BodyContainer
|   |-- InteractionContainer
|   `-- PhysicalActionContainer
|-- Data
|   |-- State
|   |-- BoundingVolume
|   |-- GeometricalModel
|   |-- InteractingGeometry
|   |-- PhysicalParameters
|   |-- InteractionPhysics
|   |-- InteractionGeometry                      ( it was Narrow ... )
|   `-- PhysicalAction
|-- Sensor
|   |-- DataRecorderEngine
|   `-- RenderingEngine
|-- Engine
|   |-- DeusExMachina
|   |   |-- ForceEngine
|   |   |-- GravityEngine
|   |   |-- RotationEngine
|   |   `-- TranslationEngine
|   |-- Engine
|   |   |-- BodyEngine
|   |   |-- BroadInteractionEngine               ( Broad  ) InteractionBroadEngine
|   |   |-- NarrowInteractionGeometryEngine      ( Narrow ) InteractionGeometryEngine
|   |   |-- PersistentInteractionCriterion
|   |   |-- VolatileInteractionCriterion
|   |   |-- PhysicalActionEngine
|   |   `-- InteractionSolver                    ( was inside PhysicalActionEngine )
|   |-- EngineUnit
|   |   |-- BoundingVolumeEngineUnit
|   |   |-- GeometricalModelEngineUnit
|   |   |-- InteractingGeometryEngineUnit
|   |   |-- PhysicalParametersEngineUnit
|   |   |-- StateEngineUnit
|   |   |-- BroadInteractionEngineUnit           ( Broad )  InteractionBroadEngineUnit
|   |   |-- InteractionPhysicsEngineUnit                    InteractionPhysicsEngineUnit
|   |   |-- NarrowInteractionGeometryEngineUnit  ( Narrow ) InteractionGeometryEngineUnit
|   |   `-- PhysicalActionEngineUnit
|   `-- MetaEngine
|       |-- StateMetaEngine
|       |-- BoundingVolumeMetaEngine
|       |-- GeometricalModelMetaEngine
|       |-- InteractingGeometryMetaEngine
|       |-- PhysicalParameterMetaEngine
|       |-- BroadInteractionMetaEngine           ( Broad )  InteractionBroadMetaEngine
|       |-- InteractionPhysicsMetaEngine                    InteractionPhysicsMetaEngine
|       |-- NarrowInteractionGeometryMetaEngine  ( Narrow ) InteractionGeometryMetaEngine
|       `-- PhysicalActionMetaEngine
`-- TimeStepper


Basically we have removed one level in directory tree - Body, and
Interaction. So maybe all class names should start with word "Body" and
word "Interaction" ?


less important ideas about names:

5. In your proposition of tree above, you have removed "Narrow" from
InteractionGeometry. I don't know if this was intentional or maybe it
was just small mistake. But to be honest I like this shorter name... But
then - maybe we have to remove "Broad" or "Narrow" from other names? 

6. In fact I like when class name starts with "Interaction". And I feel
that "Narrow" is maybe unnecesary. My proposed name is on the right. We
don't have to change them now, there are many changes waiting. Just say
if you like the idea.


-- 
Janek Kozicki                                                         |
_______________________________________________
Yade-dev mailing list
Yade-dev@xxxxxxxxxxxxxxxx
http://lists.berlios.de/mailman/listinfo/yade-dev



Follow ups