yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

I just asked Andrea, a new user, what he thinks about the following 
names : State, Engine, and PhysicalAction. For him, those names are ok 
(he suggested "Module" if we really want to change the name "Engine" 
though, he also confirmed that LoopEngine means "the engine which runs 
the loop").
If we rename some classes, I think we should focus on the most 
problematic ones, there is no reason to change all names, is there?

Bruno

Frédéric Victor Donzé a écrit :
> Vasclav, Janek, Bruno,
>
> Well, I am here and I am concerned about a good "typology" concerning 
> the class name. When Olivier Galizzi developed YADE first , he had a 
> "mystic vision" about naming classes and it was almost impossible for 
> him to understand that YADE could be used by standard persons. I would 
> like someone (whatever is his background) who starts with YADE, not 
> being lost by annoying and incoherent class names.
> Moreover, it will help to write a clear doxygen documentation.
> Thank you guys for being so creative and constructive.
> Frederic.
>
>
> Janek Kozicki a écrit :
>> Václav Šmilauer said:     (by the date of Fri, 13 Jul 2007 09:18:46 +0200)
>>
>>   
>>> If you rename classes in two days, many mistakes will be done inevitably. 
>>>     
>>
>> fortunately we have a week. Or in fact, if it takes longer ... three
>> weeks. Because that's when I return to poland.
>>
>>
>>   
>>> (And making Shape shortened to Shap is ridiculous, it saves 1 (one) letter).
>>>     
>>
>> That's also why I prefer to use acronyms :-)
>>
>>  
>>   
>>> State doesn't exist currently. For the rest; Shape vs. OptimizedShape? 
>>> Technically, it is SiplifiedShape or RepresentativeShape and that is all too 
>>> long. 
>>> For my suggestions, not all of them were serious. The serious ones were 
>>> State, Shape, Mold, perhaps Material. The rest (Bang, Bump, Smash, Bag) were 
>>> not.
>>> Why YadeSimulation - you should have YadeShape, YadeBodyOptimizedShape etc. 
>>> for everything then?! Simulation is just fine. The same for BodyVariable, 
>>> BodyConstitutiveParameters, etc. The cleanest whould be to have Body::State 
>>> (whatever you call that), Body::Shape, Body::Mold (or something different), ...
>>>
>>> SimulationLoopEngine, SimulationLoopDispatcher? LoopEngine, LoopDispatcher 
>>> would be better perhaps. What about inconsistency between LoopDispatcher and 
>>> DispatcherFunctor? LoopDispatcherFunctor? I would suggest something like 
>>> Engine, EngineDispatcher, and maybe EngineFunctor.
>>>     
>>
>> Thank you, I have updated wiki with your suggestions. Please edit it as you want.
>>
>>
>>   
>>> And for the dispatcher functors: you do the same mistake as you have been 
>>> doing from the beginning IMO: If you say 
>>> Sphere2Sphere4SpheresContactGeometry, it is clear that you mean 
>>> InsteractingSphere, since that is what SpheresContactGeometry uses.
>>>     
>>
>> I don't think it's a mistake. I think rather to use acronymys in
>> naming, that say "it dervies from InteractingGeometry". Bear in mind
>> that there are other functors also, not related to
>> InteractingGeometry.
>>
>> A possible alternative is to make subdirectories for each type of
>> functor, depending on from where they come, but I don't like it, and
>> maybe be impossible, because you can't have 2D directory structure.
>>
>>
>>   
>>> Remember that you should create a bash/perl/whatever script that will 
>>> mass-replace the names everywhere (including actors, where the names are 
>>> quoted). Ideally, we should have something like "convert-yade --from 0.11 
>>> --to 0.12 *.?pp" that would do that and be maintained.
>>>     
>>
>> of course, we need a good way to convert. I won't do it by hand, forget it.
>>
>>  
>>   
>>> As a side-note, most classes still lack any doxygen documentation. That is 
>>> much more serious than their names and Frederic should make you focus on 
>>> that (Fred, are you there?! ;-) ).
>>>     
>>
>> Well, currently Frederic is more interested in submitting an article
>> (with final versions of class names).
>>
>>
>>   
>
> -
> ------------------------------------------------------------------------
>
> _______________________________________________
> yade-dev mailing list
> yade-dev@xxxxxxxxxxxxxxxx
> https://lists.berlios.de/mailman/listinfo/yade-dev
>   


-- 
_______________
Chareyre Bruno
Maitre de conference

Institut National Polytechnique de Grenoble
Laboratoire 3S (Soils Solids Structures) - bureau I08
BP 53 - 38041, Grenoble cedex 9 - France     Tél : 04.56.52.86.21
________________ 

_______________________________________________
yade-dev mailing list
yade-dev@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/yade-dev