Re: tdf#74702 1/2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06.07.19 19:59, Adrien Ollier wrote:
Hello Community,

I am writing this very important e-mail because I need the collaboration of each of you.

I am working on bug #74072 <https://bugs.documentfoundation.org/show_bug.cgi?id=74702> whose aim is to remove the OutDevType enumeration. OutDevType was introduced to know the real type of an OutputDevice <https://docs.libreoffice.org/vcl/html/classOutputDevice.html> at any moment because some functions need the real type of the OutputDevice.

But using this enum is not the good way for doing that. So far, I could quite easily correct this in the OutputDevice's functions by introducing virtual methods. There are still a few OutputDevice's methods that use OutDevType (through GetOutDevType()) but the big majority of remaining functions take an OutputDevice as argument and virtual functions can't help. The only good way for not using OutDevType can be summarized in this simple sentence: "If a function needs to know the real type of an object, keep the real type of the object."

Suppose we have the following hierarchy of classes:

class A {/* ... */};
class B : public A {/* ... */};
class C : public A {/* ... */};

And suppose we have the following function:

int g(A* pA);

But g behaves differently according to pA is a A*, a B* or a C*. Instead of introducing an enum to know if pA is a A*, a B* or a C*, the good solution is to have three functions:

int g(A* pA);
int g(B* pB);
int g(C* pC);

mixing ad-hoc and inclusion polymorphism in this way, i.e., overloading across subtypes, is a really bad idea. (and the undisciplined overloading in languages like C++/Java is quite error prone in general and i'd rather discourage its use).


This requires to keep the real type of the variable object before calling g.
So we must NOT write this:
A* myVar = new B{};
g(myVar); // calls g(A*)

Instead, we MUST write:
B* myVar = new B{};
g(myVar); // calls g(B*)

But if g() is called by a function f(), f() also requires to keep the real type of the variable. And if f() is called by e(), e() also needs to keep the real type of myVar. And can continue until the first function a() which calls g() by waterfall effect.

which is of course silly because the result is quite contorted function abstractions and it's trivially easy to call the wrong (superclass) overload by mistake... so you agree that it's a really bad idea :)
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux