[haiku-appserver] Re: private development

Stephan Assmus wrote:
>>>Inlines ? :)
>>
>>      To a certain extent. There are some inlines in the server, there 
>>will 
>>be more, but they cannot spread across files (.o) AFAIK. For example, 
>>RooLayer really has to modify region members of Layer class, if it 
>>were 
>>to count how much of times RooLayer would access Layer's public 
>>methods 
>>just for getting a pointer to the object I'm sure your counter would 
>>go 
>>out of scale. :-) There is no need to copy objects internal to Layer, 
>>we 
>>just don't need that because we want to keep our data on a per Layer 
>>basis. And if we return a pointer/reference to a private member, what 
>>is 
>>the point in that public GET method?
>>      There are other classes which are closely tied together, like: 
>>ServerWindow/WinBorder/Layer.
>>
>>      As much as I want I cannot pull out certain 'friend's.
> 
> 
> There certainly is good use for "friend". Then there is places where 
> "friend" can be used, but should be avoided in favor of a cleaner (and 
> more flexible) design. "more flexible" in this sense means "easier to 
> adopt later, should the need arise". Now, for read only access, there 
> should be no speed difference between the following function (in the .h 
> !)
> 
> inline const SomeClass* GetInstance() const { return fInstance; }
> 
> and accessing the member directly. (I hope you didn't read over the 
> "read access" bit.) And just while I was working today on 
> CursorHandler, I was able to remove all such friend stuff *without* any 
> speed change.

        Sure, I won't argue with that. But think at the case where you call 
X::GetInstance() from Y thousands of times. I'm ready to bet the penalty 
on performance is more than 100%.
        What I'm saying: if 2 classes need freqvent need of each other's data's 
they can be considered only one object. Example: BWindow/BView - there 
is no other way to make these 2 work as they do.

> Please don't get me wrong, I'm not saying "Let's go through the source 
> and replace all this", we have more urgent things to do. I'm just 
> trying to tell you that it's better to avoid this where possible in the 
> future and should we happen to refactor some part of the code for other 
> reasons, we could keep this in mind and remove unnecessary occurances 
> of private member access. As I said, I did so with CursorHandler as an 
> example.

        I'm not getting you wrong. :-) In fact, I very much agree with you.


bye,
Adi.

Other related posts: