[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