[Bf-python] [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [10922] branches/pyapi_devel/source/ blender/python/api2_2x: Camera, Scene, Object - removed get/set' s from the API (getName, setName) - just use .name

[Campbell Barton]

Stephen Swaney wrote:
> On Thu, Jun 14, 2007 at 04:26:46PM +1000, Campbell Barton wrote:
>> I had a search, and nothing specific to this came up such as - "Should 
>> We have Layers and layers" - but I think it needs to be discussed.
> 
> The name Layers is a holdover from olden times before we standardised
> on an attribute naming convention.  In a nutshell, layers is preferred,
> Layers is old, legacy cruft that can and should fade away.
> 
> 
>> If layers as lists are supported they should all share code and possibly 
>> even have a reference wo the original data so one could do 
>> ob.layers.append(20) or ob.layers.remove(1)
>>
>> but personally I find lists are a bad way to represent layers
>>
>> for instance, if you want to remove a layer you have to check its in the 
>> list operate on the list and then re-assign it.
>>
>> if 1 in ob.layers:
>>    layers = ob.layers
>>    layers.remove(1)
>>    ob.layers = layers
>>
> 
> I agree that a list is an unsuitable data structure to represent layers.
> Something that works like ob.layers.remove(1) or ob.layers.add(1) is
> much more straight forward.
> 
> Being able to assign like ob.layers = old-layers is useful too.
> Same with supporting the iterator protocol.
> 
>> whereas..
>>
>> ob.layers &= ~1 # does the same thing
>>
>> looping on layers is nicer with ob.layers (list) but not bad with a bitmask
>>
>> for i in xrange(20):
>>     if ob.Layers & 1<<i:
>>         ....
>> I think we could have docs with snippets like this showing scripters how 
>> they can do layer operations with bitmasks.
>>
>> when using 1<<4 syntax its not that hard to do.
> 
> The bitmask syntax is fine for anyone who understands C programming.
> However, one of our target audiences is the 'naive scripter or artist
> who needs to create simple utilities or macros.  For them, ob.layers &= ~1
> is just a little to cryptic.
> 
> I can see supporting both styles, but to solely use the bitmask syntax is
> ungood.

yes, set like syntax would work well here,

Id like to look into subclassing sets() here since there are quite a few 
PyTypes like this that dont need many of their own functions.

- materials are also a candidate for subclassing

The idea is that the subclass will intercept calls like append or add, 
remove etc. and keep a reference to the blebder data that is kept in 
sync. - This might end up being less work then writing PyTypes from 
scratch as well.

how about ob.layerMask, scene.layerMask - for the bitmasks, and .layers 
for the set lookalike?

However if the layer set thing is done baddly- Id prefer it not be done 
at all - There are probably a lot of naive python scripters who dont 
know how to use sets either. and giving scripters a half working 
solution is worse then them having to read up on how bitmasks work.

And its still more error prone since a layer-Set pytype will need a 
pointer to the scene (to stay in sync) that will become invalid if the 
scenes removed (possibly crashing blender if the layer data;s written to 
later)
This problem needs to be delt with in quite a few areas so not just 
layer related. just an advantage to using bitmasks until removing data 
pointer issues are resolved.

- Cam,