Hi Mathias,

> Perhaps we should follow up on this elsewhere.

You're right, issue 81309 is not the proper place. [EMAIL PROTECTED] might be 
better.

> The problem is when people use code without asking its owner (if someone used
> so3 without asking me or mav that would be the case)

Come on. We used the Paste Special dialog from so3. You are not going to
say that if somebody uses a helper class from
unotools/comphelper/svtools/whatever, he must ask the owner of that
module/code, are you? And if not: What's the difference between so3 and
svtools? And, more important, how is the ordinary developer to know this
difference?

No, sorry, "ask the owner of the module before using helper code
exported by this module" is no valid concept.

> or when people make big
> changes like the ResMgr change without really having a strategy to find all 
> the
> pitfalls and without a comprehensive testing.

I don't think testing would have been a help here. After dealing with
the topic, I think "Paste Special" in Base might have been the only
place where the problem struck.
Also, I doubt Philipp didn't have a strategy, though I admit that in
this special case, he could have found the problem with a little more
digging. Nonetheless, if we wouldn't have this dead code, there would
have been no need at all to invest the time ...

> There is no difference between so3 and binfilter.

In fact there is. binfilter contains code used for the binary filters,
and only such code. And this is a pretty well-known fact. For so3, this
isn't known (I'd claim).

I'd even bet we didn't have a chance of knowing this. Has there been an
API changes mail "module so3 is deprecated"? Can't remember having read
it ... which is one more reason why I regret the fact API changes are
out of fashion nowadays. Nobody has a chance knowing what's going on on
such a low level. We're lucky if we know what features were implemented
in the other applications, but we can't know what code exists in our
application, even if this would be of great interest to all core developers.

> Both are modules only used to
> load and save old binary files. As you write you don't care about the size of
> binfilter I don't know why you care for the size of so3. 

I don't care (too much) for the size. As I tried to explain in the
issue, I care for dead code lingering around, producing effort in later
API chances, and offering pitfalls for the people who do not know its dead.

> I don't know why base crashes due to problems in so3.

Because it uses a dialog which is loaded with a NULL-ResMgr.

I didn't check this in CVS, but I assume it was like this: The code to
use the dialog was introduced a few years ago, but existed in a CWS
only. With moving dialogs into a load-on-demand library, the dialog was
duplicated in CVS, but not removed from so3. Also, there was no API
changes mail saying "Don't use this dialog from so3 anymore.". So, all
went fine. Until the ResMgr change happened, which unfortunately, in
this particular case, caused all resources in SO3 to be constructed with
a NULL-ResMgr, which isn't valid anymore.

side note: If the man who did
 ResMgr* SoDll::GetResMgr()
  {
    // resources are in the default res mgr (OFA)
    return NULL;
  }
would have done this change - from an own SoDll::pResMgr to the OFA res
mgr - *properly*, and would have removed this function, together with
all - unused for years - .src files in the module, then we wouldn't do
those long discussions years later. But alas, a simple "return NULL"
probably was considered the easier and faster solution.

This fast solution is one reason why "Edit/Paste special" crashes in
2.3/Base. I continue to think it would have been worth the effort to
implement the real solutions instead of the quick ones, in all places
which contributed to this crash.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer         [EMAIL PROTECTED] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  • [dev] Re: remove dead corpses ... Frank Schönheit - Sun Microsystems Germany

Reply via email to