[Bf-taskforce25] RNA structs for UI grouping?

[Vekoon]

Yes I wasn't saying "if you call it parent it must act as a parent" 
(which is actually not true for many parents, pun)
What I was saying is that nesting creates hierarchies and that's where 
my point started. As you said if the struct is used in more that 1 place 
you have a problem, but the fact that this could happen (even if of 
course the code won't let it to) should immediately point out its weakness.
Oh well, was just my pointless opinion anyway.

Campbell Barton wrote, on 10/01/2009 6.54:
> Even though RNA_ObjectGameSettings could be defined without
> RNA_Object, I dont see how this is relevant, since the api only allows
> access to RNA_ObjectGameSettings from RNA_Object.
> In DNA struct its not a parent/child relationship... but from RNA it
> is (or nested property groups - or whatever, the term parent is used
> loosely)
>
> just adding a "parent" for any nested DNA struct is a bit wrong, since
> the struct could still be used in more then 1 place. this isnt what I
> suggested.
>
> In the struct definition I wrote this comment.
>
> 	/* only use for nested structs, where both the parent and child access
> 	 * the same C Struct but nesting is used for grouping properties.
> 	 * The parent property is used so we know NULL checks are not needed,
> 	 * and that this struct will never exist without its parent */
>
> An annoying side effect is now the structs are documented as...
> rna.FluidSettings.FluidFluidSettings
> rna.Object.ObjectGameSettings
> rna.Material.MaterialRaytraceTransparency
>
> Not much we can do about this, just the result of making global
> namespace C struct names nested.
>
> - Cam
>
> On Fri, Jan 9, 2009 at 11:40 AM, Vekoon <vekoon at gmail.com> wrote:
>   
>> I always thought of rna structs as kind of a "type" information (and is
>> indeed said so in various contexts), where their listed properties
>> indicate the properties supported by that type.
>> So does it make sense to have types defining a parent? I'm still digging
>> into RNA but if I'm not mistaken you mean that RNA_Object should be
>> considered parent of RNA_ObjectGameSettings?
>> My concern is that parenting generally describes a situation where
>> children's definition rely on the parent being defined, which is not
>> really true for the case above as RNA_ObjectGameSettings does not need
>> RNA_Object being defined in order to be defined itself as it doesn't
>> inherit anything from it.
>> Although they're clearly related to one another what they describe is
>> not a hierarchy relationship between the physical types but the relation
>> in which the properties of those types will be found. Basically it's
>> just saying RNA_Object will have a property of type
>> RNA_ObjectGameSettings, which is not really a parent-child relationship
>> between types which is indeed already defined by the "from" field in
>> StructRNA.
>> In my opinion doing so just for the sake of documentation is forcing
>> structs into something they were not really thought for. I could be
>> wrong though.
>>
>>
>> Brecht Van Lommel wrote, on 09/01/2009 14.45:
>>     
>>> Hi,
>>>
>>> On Thu, 2009-01-08 at 10:53 -0800, Campbell Barton wrote:
>>>
>>>       
>>>>> This is something I considered but I think doing this has some problems...
>>>>> any struct that has 1 point of access is assumed a nested struct, but
>>>>> if for some reason a second access point is added, the docs will
>>>>> change (breaking bookmarks/links - not THAT bad, but not great)
>>>>> If member 'FOO' happens to have 1 user and 'BAR' has 2, they will end
>>>>> up in different places in the docs too, even if both aren't nested
>>>>> structs.
>>>>>
>>>>> It also means you cant tell from the docs which structs need NULL checks.
>>>>>
>>>>> --
>>>>> - Campbell
>>>>>
>>>>>
>>>>>           
>>>> Brecht, would it be ok if I look into adding some check for nested structs?
>>>>
>>>>         
>>> OK, an extra "parent" struct pointer or so to organize the
>>> documentation is fine I think.
>>>
>>> Brecht.
>>>
>>>
>>> _______________________________________________
>>> Bf-taskforce25 mailing list
>>> Bf-taskforce25 at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>>
>>>
>>>       
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>     
>
>
>
>