FreeLists / haiku-appserver / [haiku-appserver] Re: invalidation again

["Stephan Assmus" <superstippi@xxxxxx>]

> > Yeah, I tried to follow that. The main problem was all these 
> > clipping 
> > regions with completely obscure names. They give no hint what they 
> > are 
> > used for.
> 
>       Well, maybe you're right.
> 
> fVisible - is the actual visible region of a layer
> fFullVisible - is the visible region of a layer + all the visible 
> regions
>       of all layers that it contains (the whole tree).
> fFull - is the region equal to layer's bounds + client specified 
> clipping
>       regions BView::ConstrainClippingRegion(). (this how the Layer's
>       visible region would look like if it would be completely visible
>       and have no children)
> 
> fVisible + fFullVisible == fFull if the Layer is entirely visible.

Ok, so what is RootLayer::fUpdateReg (for example)?

I must say I don't like the design with the "current layer". I think 
that the layers and the data they carry is munched together with the 
managing of multiple layers. This is the confusing part. So inside an 
instance of layer, there is code concerning that layer (instance), and 
then there seems to be code as if Layer was a static class. You set 
some member variable of one layer instance, to manage another layer. So 
it is completely confusing, which layer we're actually updating or 
changing. You don't see this from the code, it just "happens" to work 
if the client code knows what it is doing. This is not necessarily good 
code, the correct usage should be enforced by the design, this would 
make it all much more usable. And I think most of the bugs come from 
client code not actually doing all the necessary things in order for 
the mess in Layer to "magically" work correctly.

Ok, I don't like to "preach" or anything, so please don't take the 
following that way. Take it as someone stating his experience, you may 
agree or not agree. So here it goes:

In my experience, this is a good aproach to object oriented 
programming: Usually, a class contains data and functions to manipulate 
that data. Most of the times, there are multiple bits of data, which 
depend on each other in some way. Certain combinations of the data 
values can be considered "valid", other as "invalid". Now, the trick is 
to enforce the "valid" combinations of data inside the class. So that 
client code which uses the public methods of a class *can not* bring 
the object into an "invalid" state.
As soon as you design your code so that you depend on the client code 
to keep the data valid, you have a number of problems:
        * You open up a lot of possibilities for bugs
        * You make the code hard to understand, because you don't know 
which part of the client code might mess with something and cause an 
invalid state, you cannot enforce "code paths".

I know, you have all this "but it needs to be fast" stuff in mind. And 
you think that "if I know what I'm doing, everything will be fine". 
There might be occasions where it makes sense to have a framework of 
classes manipulating each other and acting like "one" object. But I 
think the current app_server design is completely overdoing this, for 
_no_ good reason. I think a lot of the problems can be contributed to 
this fact. So while you work on something, please try to make the extra 
effort to refactor things. It will save so much time in the end.

Best regards,
-Stephan