On 01/03/2012 19:16, Hans-Peter Diettrich wrote:
Martin schrieb:
It does still cost time to write up all the info, and guarantees
nothing. While if someone wants to do work on something, there are
much better chances that the work (providing infos/answers) will
bear fruits.
This finally explains the often confuse and inconsistent
implementations, found across the entire LCL :-(
I consider this a sarcasm gone badly wrong.
If those kind of implementation exist (rather than just being
perceived as such by individuals), then for those there are many
reasons possible. Many of which would still apply, even if ass the
docs existed.
What makes you thing out of all those reasons, it must be the missing
docs?
Documentation readers will easily find what's wrong with an
uncoordinated design, and can point the developers there. Then each
involved developer can study the documentation of the others, instead
of figuring out what the might had in mind when implementing their
isolated parts.
E.g. I'm voting for a layout manager interface since years, derived
from the already existing DockManager interface. But in the meantime
many features have been implemented that make it almost impossible to
add layout managers to the TWinControls. Even docking has been broken,
and the IDE layout management follows another and again different and
incompatible way. The time, spent in such different approaches, could
have been used much better.
IIRC the layout was discussed long ago per mail, you did ask questions
and iirc, they where answered.
If hypothetically:
- documentation was created which stated the concept of current layout
implementation
- and also stated that this will (if not for any other reason then at
least for compatibility) will be kept as it is
would you then be happier? Would then it be ok for you, and would then
your desire for a layout manager be gone?
I do not thing so at all.
Let me add: I would myself like nore modular concepts for layout. But I
do not know if it can be done at reasonable cost (speed, memory, and
compatibility). If I had time I would investigate. (I have not the time)
More than documentation, I would need test cases (If I would work on it,
I would create them). Documentation I can misunderstand, and then my
changes will break things. Testcases are better on catching those issues
(and by doing so, they will help me understand)
There are wiki pages, documenting how layout works (IIRC there where
some recent mail involving you and that doc)
Yes they do not tell you about the internal organisation about the data
involved. But what can I say: it is my firm believe, that given the
current situation (project size, number of people involved, number of
people seeking to be involved) this is better done by asking question.
This may change in future.
But there it is my believe that such change (e.g actually documenting
those things up front) is to be a *reaction* to changes of the situation
(size/people).
I accept you believe otherwise. I accept and applaud that you seek to
convince others.
--------------
About how to define good and bad implementation or concepts.
I guess it is rather the concept/design you complain about? After all,
if the design was good, but badly implemented it would likely be easy to
fix?
When 4 years ago, I first looked at the debugger, I thought the design
was rather bad. Now that I learned more about it, I can only applaud
Marc for the incredible foresight he put into it (sure some things where
changed, but many of the general concepts still stand).
Would it have been easier, if it had been documented? Not at all, or
very little. Marc had back then answered all my question. So the issue
wasn't getting or having the info. It was for me to familiarize myself
with the huge amount of code. That simple takes time.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
