[Bf-committers] RNA Rename Proposal

Campbell Barton ideasman42 at gmail.com
Tue Aug 17 05:38:00 CEST 2010


@Dalai, corrected states -> state. The api dumping script didnt show
array sizes which caused this confusion, added array sizes to the
types and corrected in svn.

# IMHO this is just a problem we get from cramming so much
functionality into one actuator.
Actuator|EditObjectActuator.replace_physics_mesh

# Ideally I think we should have a replace mesh actuator.
Actuator|ReplaceMesh.use_physics

RE: use_priority & use_force_distance
use_force_distance is more confusing, since it sounds like this could
be a physics force, perhaps it could be named to use_fixed_distance ?



@Nathan, agree about the problem setting the current frame there are a
few cases like this where the api doesn't behave in a useful way from
a python standpoint.
- Image.filename_raw # so changing the filename doesn't reload the
newly set filename.
- MeshFace.verts_raw # so we can set all 4 indices's on a new face.
Id rather deal with these separately.

Makes sense to choose one here.
Ok to settle on vertex|vertices over vert|verts. (committed)

In this case it makes sense because faces & edges isn't abbreviated
but there are abbreviations we applied in a number of places.
- coordinates -> coords, Otherwise variable names get too long IMHO.
- duplicator -> dupli
- sss & ao are used in a few places, for these I don't think its great
to use the full names though we could for consistency since it is used
in some places.
RenderSettings.simplify_ao_sss would be... ->
simplify_ambient_occlusion_and_subsurface_scattering

Could you make a list of names you think should be using their
un-abbreviated versions?

For "co", used for vertex/grease pencil, keyframe's particles.
Id really prefer to keep this abbreviation, its just very convenient
since these end up being accessed a lot and a vertex doesn't have many
other attributes.
We can end up with lines like
 (v1.co.y - v2.co.x) + (v3.co * matrix).x ... etc



@Alberto, curves have a direction so we could use handle_before/after,
prev/next or similar, IIRC Brecht named this, even though its not
fully correct in the case of 3D curves I don't have a strong opinion
on this.


On Tue, Aug 17, 2010 at 8:35 AM, Alberto Torres <kungfoobar at gmail.com> wrote:
>  Keyframe.handle1 -> handle_left:   float  "Coordinates of the first handle"
>  Keyframe.handle1_type -> handle_left_type:   enum  "Handle types"
>  Keyframe.handle2 -> handle_right:   float  "Coordinates of the second handle"
>  Keyframe.handle2_type -> handle_right_type:   enum  "Handle types"
>
> This new name doesn't make sense (only for f-curves). What's the
> problem with the old name?
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell


More information about the Bf-committers mailing list