Hi Ruediger,
Rüdiger Timm wrote:
That's a joke, isn't it?
From my point of view of course it has to be (according to your
numeration)
1.
4.
5.
2.
3.
Why would you copy additional stuff into binfilter? We did enormous
efforts to get that monster stripped, and you plan to blow it up again.
as you may know, we _love_ to blow up and to double the amount of code
every year, this is one of our favorites, isn't it? :-)
Seriously, the goal certainly is _not_ to unnecessarily increase code
size. Ideally binfilters would be well formed Uno components,
independently build and deployable. To eventually reach this goal, we
need to make it independent of the rest of the office. Or let me phrase
it the other way, if we are going to keep binfilters dependent on other
C++ parts of the office, we could just have kept the original approach,
to never change the application cores incompatible wrt to the old binary
file format.
Why? If someone does incompatible changes he must do all necessary
adaptions in modules above. Regardless of the name of those modules. Why
change code in 'sw' but leave 'binfilter/bf_sw' untouched?
See above. Keeping binfilter dependent on other C++ code is
-a- a maintenance issue, and
-b- forbids certain kinds of changes, we want to do.
OK, there may be rare cases where no one is able to adapt stone aged
binfilter code with reasonable effort. But that is an evidence of
incapacity and should be the strict exception.
As said above, there are cases where binfilter would hinder the renewal
of other code. This is and was the original reason to factor out the
binfilters. This is the way we want to go. It was an error in the first
place, to ever expose our internal binary formats. binfilters purpose is
to correct this error!
At least that's my understanding. Please correct me where I am wrong.
I tried :-)
Rüdiger
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
