[Bf-committers] Re: [Bf-blender-cvs] CVS commit: blender/source/blender/python/api2_2x Object.c blender/source/blender/python/api2_2x/doc IDProp.py Texture.py Scene.py Object.py Image.py Mesh.py NMesh.py Material.py

[Martin Poirier]

Hi,

--- Willian Padovani Germano <wgermano at superig.com.br>
wrote:

> And others, too :). This is something we should
> decide for the whole API 
> (short "vs." actual/readable names). Our current
> guideline is to follow 
> Blender's UI, but atually we have a mix of old / new
> / not reviewed names.

Totally agreed, it is MUCH needed.

> As Martin said, it's important to have precise,
> readable terms and 
> follow the Blender UI names. But it's also true that
> whenever possible 
> it's good to be less verbose. So in general: what is
> the best guideline?
> 
> 1) Use precise / readable names, following the UI.
> 
> 2) Use shorter names.
> 
> 3) (1+2 for special cases) Having the precise name
> as default and a 
> shorter version for faster access (*). We'd document
> the precise one (so 
> favoring its usage) and mention in its doc the
> shorter alternative.
> 
> (*) We can (should) restrict this to the more common
> things, like 
> location (loc), rotation (rot), color (col),
> material(s) (mat(s)), 
> property(ies) (prop(s)), etc.
> 
> My vote: I like #3: have readable names, but where
> needed also a shorter 
> alternative (that should be a good reminder of what
> it actually means).

I would oppose to #3, having two ways to access
something is potentially confusing.

1- Are both methods the same?
2- Is their input/output compatible?
3- If 1 and 2 are true, then why give two different
methods?

Haven't we learned anything from Perl's "There's a
bazillion ways to do it!" development fun?!

(and you know my stance on #2)

If you think Python is verbose, never try looking at
the standard Java libraries.

--- Stephen Swaney <sswaney at centurytel.net> wrote:
> 
> The part that bothers me is we call it 'properties'
> in
> most classes except for Object where it becomes
> 'idproperties'
> Being consistent is good.

Agreed. I would suggest we move the game related
properties to .game_properties or something like that.
I do realize that a some scripts might be dependent on
that, but I think consistency is better than backward
compatibility in this case.

--- Campbell Barton <cbarton at metavr.com> wrote:

> agree to disagree- ;)
> properties is somthing yo may use a lot
> 
> I get tired of C having nice short names and python
> while having a nice 
> syntax, using annoyingly long names.
> C: OBACT
> PY: Blender.Scene.GetCurrent().getActiveObject()

It's not a matter of syntax, it's a matter of clarity.
Without someone telling or looking it up, I highly
doubt any newcomer would know what OBACT does whereas
the Python idiom is very clear about what's exactly
happening.

> the result is people will define their own names for
> properties because 
> the veriable is too long to type in all the time,
> which is OK, but can 
> make the code less easy for others to read because
> you need to find the 
> special names, and where its defined etc.

If people decide to obfuscate their own code because
their editor can't do auto completion of often typed
words, it's their own problem.

Unless your typing speed is exceedingly abysmal, five
more letters aren't going to kill you, especially if
they make it easier to understand the purpose of the
code later.

> We alredy have me.mat ob.loc mat.col - why not
> somedata.prop?

Loc, Rot, Col are actual name you can find in the
Blender UI. Prop is not.

Martin


 
____________________________________________________________________________________
Sponsored Link

Mortgage rates near 39yr lows. 
$510k for $1,698/mo. Calculate new payment! 
www.LowerMyBills.com/lre