Method Naming

[worbit]

This code prints a list of all the classes and methods pulled up to top-level import by the __init__.py file:

for i,e in enumerate(mola.__all__):
    print(i,e)

A	B	C
0 Box	38 constructIcosahedron	76 normalEdge2D
1 Edge	39 constructSingleFace	77 normalEdge2DNonUnified
2 Face	40 constructTetrahedron	78 normalFromTriangle
3 Graph	41 constructTorus	79 normalFromVertices
4 GraphAnalyser	42 copy	80 normalVertex2D
5 Grid	43 copyProperties	81 ntpath
6 GridManager	44 core	82 offset
7 HexGrid	45 cross	83 offsetLine
8 Mesh	46 curvature	84 offsetPlanar
9 PriorityQueue	47 distance	85 offsetPoint
10 SinusFunction	48 divide	86 perimeter
11 Vertex	49 division	87 polyUtils
12 add	50 dot	88 rot2D90
13 angle	51 exportOBJ	89 scale
14 angleTriangle	52 exportOBJFaces	90 slice
15 area	53 extrude	91 sliceTriangle
16 areaFromVertices	54 extrudeTapered	92 sliceWithZ
17 areaTriangle3D	55 extrudeToPoint	93 slicer
18 areaTriangle3DCoords	56 extrudeToPointCenter	94 splitFrame
19 betweenAbs	57 faceUtils	95 splitGrid
20 betweenRel	58 factory	96 splitOffset
21 center	59 getColorRGB	97 splitOffsets
22 centerFromLine	60 graph	98 splitRel
23 centerFromVertices	61 grayscale	99 splitRelFreeQuad
24 color	62 grid	100 splitRelMultiple
25 colorFacesByArea	63 horizontal_angle	101 splitRoof
26 colorFacesByCompactness	64 importOBJ	102 subdivide
27 colorFacesByCurvature	65 importOBJFaces	103 subdivideCatmull
28 colorFacesByFunction	66 io	104 subdivideCatmull2D
29 colorFacesByHorizontalAngle	67 length	105 subdivide_catmull_translate_facevertices
30 colorFacesByPerimeter	68 lineLineIntersection	106 subdivide_translate_facevertices
31 colorFacesByVerticalAngle	69 marchingCubes	107 subdivision
32 colorsys	70 marchingCubesFromGrid	108 subtract
33 compactness	71 math	109 unitize
34 constructBox	72 mathUtils	110 vec
35 constructCircle	73 mesh_extrude_tapered	111 vertical_angle
36 constructCone	74 mesh_extrude_to_point_center	112 weldVertices
37 constructDodecahedron	75 normal

I suggest we try to be as explicit as possible. All things subdivision (also extrude and split) should start with subdivision, cross and dot could become cross_product and dot_product... more suggestions welcome!

[modellstadt]

Ok lets collect naming proposals. we should do this only once

On Mar 2, 2020, at 18:12, Mathias Bernhard notifications@github.com wrote:

 This code prints a list of all the classes and methods pulled up to top-level import by the init.py file:

for i,e in enumerate(mola.all): print(i,e) A B C 0 Box 38 constructIcosahedron 76 normalEdge2D 1 Edge 39 constructSingleFace 77 normalEdge2DNonUnified 2 Face 40 constructTetrahedron 78 normalFromTriangle 3 Graph 41 constructTorus 79 normalFromVertices 4 GraphAnalyser 42 copy 80 normalVertex2D 5 Grid 43 copyProperties 81 ntpath 6 GridManager 44 core 82 offset 7 HexGrid 45 cross 83 offsetLine 8 Mesh 46 curvature 84 offsetPlanar 9 PriorityQueue 47 distance 85 offsetPoint 10 SinusFunction 48 divide 86 perimeter 11 Vertex 49 division 87 polyUtils 12 add 50 dot 88 rot2D90 13 angle 51 exportOBJ 89 scale 14 angleTriangle 52 exportOBJFaces 90 slice 15 area 53 extrude 91 sliceTriangle 16 areaFromVertices 54 extrudeTapered 92 sliceWithZ 17 areaTriangle3D 55 extrudeToPoint 93 slicer 18 areaTriangle3DCoords 56 extrudeToPointCenter 94 splitFrame 19 betweenAbs 57 faceUtils 95 splitGrid 20 betweenRel 58 factory 96 splitOffset 21 center 59 getColorRGB 97 splitOffsets 22 centerFromLine 60 graph 98 splitRel 23 centerFromVertices 61 grayscale 99 splitRelFreeQuad 24 color 62 grid 100 splitRelMultiple 25 colorFacesByArea 63 horizontal_angle 101 splitRoof 26 colorFacesByCompactness 64 importOBJ 102 subdivide 27 colorFacesByCurvature 65 importOBJFaces 103 subdivideCatmull 28 colorFacesByFunction 66 io 104 subdivideCatmull2D 29 colorFacesByHorizontalAngle 67 length 105 subdivide_catmull_translate_facevertices 30 colorFacesByPerimeter 68 lineLineIntersection 106 subdivide_translate_facevertices 31 colorFacesByVerticalAngle 69 marchingCubes 107 subdivision 32 colorsys 70 marchingCubesFromGrid 108 subtract 33 compactness 71 math 109 unitize 34 constructBox 72 mathUtils 110 vec 35 constructCircle 73 mesh_extrude_tapered 111 vertical_angle 36 constructCone 74 mesh_extrude_to_point_center 112 weldVertices 37 constructDodecahedron 75 normal
I suggest we try to be as explicit as possible. All things subdivision (also extrude and split) should start with subdivision, cross and dot could become cross_product and dot_product... more suggestions welcome!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[modellstadt]

faceUtil Methods, methods which analyse faces: calc_face_perimeter() calc_face_area() calc_face_curvature()

[modellstadt]

vector_add vector_dot vector_cross

[modellstadt]

face_extrude_point face_extrude_tapered

[modellstadt]

mesh_subdivide mesh_suddivide_catmull

[worbit]

faceUtil Methods, methods which analyse faces: calc_face_perimeter() calc_face_area() calc_face_curvature()

i agree with all the others, here i would even skip the calc_ prefix, 1) because it is redundant if used in all methods and 2) because in a way all methods do some calculation...

for vector / vertex (we use the same class for both) there is also

• vector_scale
• vector_unitize
• vector_length
• vector_angle (between 2)
• ...

[modellstadt]

you are right, what about? face_area() face_curvature() face_perimeter()

[modellstadt]

the logic seems clear and similar to rhino python.

[modellstadt]

construct_cone construct_box

[demsham]

as we improve the naming, should we also move some methods from one file to another? example: determinant in mathUtils instead of faceUtils?

[demsham]

also, do we favor the underscore over the capital letter in everything? e.g should mesh.weldVertices() be mesh.weld_vertices() then?

[worbit]

• i agree on construct_box (as opposed to constructBox as we have it now)
• i might take back my suggestion of vector_scale etc, as these are directly in the class, so v.scale(f)
• other classes, such as Edge also have some methods (getCenter) whereas the Face class has its methods "outsourced" to faceUtils.center(face)

... there can be some more cleaning...

[worbit]

snake_case everwhere

[demsham]

class Box b.getDimX, b.getDimY, b.getDimZ b.getCenterX, b.getCenterY, b.getCenterZ

why not just b.dim_x, b.dim_y, b.dim_z b.center_x, b.center_y, b.center_z

[worbit]

or: Edge, Face and Box all have the same method, get_center() which returns a Vertex with x,y and z?

[demsham]

much better. but i still have the question of 'get' vs not. in some cases we don't use it (vertex.length) and in some we do (box.get_center)

[demsham]

if area(face) -> face_area(face) then areaTriangle3D(a,b,c), areaFromVertices(vertices) etc. -> ?

same goes for face_normal(face), face_center(face)..

[modellstadt]

I think so. Lets rather talk on a higher level of a consistent scheme..

On Mar 3, 2020, at 15:21, demsham notifications@github.com wrote:

 if area(face) -> face_area(face) then areaTriangle3D(a,b,c), areaFromVertices(vertices) etc. -> ?

same goes for face_normal(face), face_center(face)..

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[demsham]

i think these are already the exceptions. the scheme would be that there's prefixes similar to the file naming. construct_ for factory meshes face_ for operations / properties of class Face vector_ for operations / properties of class Vertex (i suggest we 'externalize' all of these. currently there are duplicates in the vec.py (should probably be vecUtils.py) and in the Vertex class) subdivide_ for mesh+face subdivision or mesh_subdivide_ face_subdivide_ import_ export_ for io

[modellstadt]

https://docs.google.com/spreadsheets/d/1i80xlgWk0vkMauEFwJ24zz-hkpuYMoSrOA9XaC5etzo/edit?usp=sharing

here a google sheet to plan the renaming. should be easier to do it first there instead of coding

[modellstadt]

I am afraid core is growing. Would it make sense to separate Mesh, Vertex, Edge, Face and Box in separate files?

compared to now:

core facutils

but otherwise also ok

[demsham]

I am afraid core is growing. Would it make sense to separate Mesh, Vertex, Edge, Face and Box in separate files?

compared to now:

core facutils

but otherwise also ok

moved to #42 since it's related to that

[modellstadt]

Dear All, I try to summarize all changes? From the perspective of users (organisation of modules is not visible to users)

• from thisStyle to this_style consistent.
• methods within classes can have simple names. like in class Vertex: v.add()
• methods that are in modules (but not in classes) should have a name allowing them to be easily found with autocomplete. i.ex. in module vector_utils.py the method vector_add(). We could solve this also with static methods with the class Vertex, but for students it might be more complicated to learn that.
• we avoid getters and setters. if a method calculates a value, for example the perimeter, we don't use get_perimeter()