BUG: inherited method qualifiers

[sl@sh]

Sorry if this has come up before, the search function didn't turn up anything:

When I draw a generalization link from one class to another, EA prompts me with a dialog of methods I'd like to implement. This is all good and well - however, EA retains and removes the wrong method qualifiers from the original methods: it does keep the "Pure" property which translates into the "=0" pure abstract function syntax in C++ and it does remove the "Abstract" property which in C++ translates into the "virtual" qualifier.

EA is wrong in both cases, but I wonder whether this is just a bug or if there's a setting somewhere within the EA UI to fix this behavior!?

Is there?

Stefan

[Paolo F Cantoni]

In my view, the whole inheritance technology is flawed in EA.

The topic What and How should things get Specialized?, notes some thoughts I had on the topic.

You can also search for the term "Undefin" (with 999 days) to see more stuff.

I'm strongly influenced by Bertrand Meyers' views on the topic.  Unfortunately EA doesn't support much of these ideas (yet).  Perhaps the Sparxians will indicate if they are even on the horizon.

Paolo

[sl@sh]

Thanks for your input Paolo (and the link), but I am currently less concerned about what should be inherited, than getting correct code out of my objects without having to correct each individual piece of automatically generated bit!

EA implements the inheritance of a (C++) pure virtual function (also known as an 'abstract' function in C++) as a pure non-virtual function. This is wrong in several aspects:

1. A pure non-virtual function doesn't exist. It just doesn't make sense. As a matter of fact, the combination of the not-'Abstract' and 'Pure' properties shouldn't be possible - however, that's for C++, maybe other languages allow that combination.
2. A virtual function that you want to inherit needs the 'virtual' qualifier, or else it will overwrite the original function, which is both syntactically and semantically different from inheritance.
3. A function implementation can *not* be pure.

All of these are bugs in my eyes, not just a matter of philosophy. I wonder why I didn't find even a single reference to this erroneous behaviour - the generated code shouldn't even compile, let alone do what's intended. That is why I posted in here, not just report a bug - I wondered if this behavior was dependend on a setting that maybe is set to another language by default.

[«Midnight»]

1. A pure non-virtual function doesn't exist. It just doesn't make sense. As a matter of fact, the combination of the not-'Abstract' and 'Pure' properties shouldn't be possible - however, that's for C++, maybe other languages allow that combination.

Or perhaps it can. For a case relevant to C++ please see http://www.parashift.com/c++-faq-lite/abcs.html#faq-22.4

Beyond that you guys are on your own. I work in a different corner of the software sphere. [Or whatever shape you choose to draw, see the example.]

David

[Paolo F Cantoni]

Thanks for your input Paolo (and the link), but I am currently less concerned about what should be inherited, than getting correct code out of my objects without having to correct each individual piece of automatically generated bit!

Hi Sl@sh, I was aware of your needs...  However, as we may probably find, the actual error may be related to the points I raised in the links.  

EA implements the inheritance of a (C++) pure virtual function (also known as an 'abstract' function in C++) as a pure non-virtual function.

Not for me, it didn't.    When I selected the the pure virtual operation in the Overrides & Implementations dialog, it gave me a pure virtual operation in the child.  (As, in my view, it should - I'm the one who decides how I'm going to implement or override the child operation - NOT EA).

Since the observed behaviour appears different in our two universes, the rest of your post is moot.

Can you identify the version you're using and the process you went through to get the outcome you observed?

Then we might be able to zero in on how to help you.

Paolo

[sl@sh]

Or perhaps it can. For a case relevant to C++ please see http://www.parashift.com/c++-faq-lite/abcs.html#faq-22.4

Following your link I didn't find anything in contradicttion to my statement. I was talking about a function that is pure (=0), but not virtual - because that is what EA generates for me! I get something like this:

Code: [Select]


class Class1 {
 virtual void myfunc () = 0;
};
class Class2 : public Class1 {
 void myfunc () = 0;
};

While this kind of code does actually compile (I don't quite understand why, but it does), the code generated for Class2 doesn't fulfil any purpose: because of it's pure function it cannot be instantiated, and because this function isn't even virtual it cannot be overriden within an inherited class either!

Moreover, if I understand C++ syntax correctly, the function Class1::myfunc() is not overridden by Class2::myfunc(), but overwritten - not that it makes a difference since Class2 cannot be instantiated anyway...

[sl@sh]

Not for me, it didn't.    When I selected the the pure virtual operation in the Overrides & Implementations dialog, it gave me a pure virtual operation in the child.  (As, in my view, it should - I'm the one who decides how I'm going to implement or override the child operation - NOT EA).

Since the observed behaviour appears different in our two universes, the rest of your post is moot.

Can you identify the version you're using and the process you went through to get the outcome you observed?

Then we might be able to zero in on how to help you.

Paolo

Hi Paolo,
I agree with you that the best behavior in general terms would be for EA to not change the qualifiers at all. However, when I choose to override a function in an inherited class, why would I do so without wanting to provide an implementation? Or in other words: why should the Pure attribute stay?

Anyway, that is not what I get either way. What I do is the following:

1. In a class diagram, create a new class Class1 and an operation within that class, myfunc. The attributes for this operation are: Abstract and Pure. I can generate this class as C++ and what I get is this:

Code: [Select]

class Class1
{
public:
 Class1();
 virtual ~Class1();
 virtual void myfunc() =0;
};
This looks good.

2. I create another class in the same diagram, Class2.

3. Using the Class2 quicklink, I draw a Generalization link to Class1. This opens the Override & Implementation dialog for me, presenting the function Class1::myfunc(). I select that function and close the dialog. When I look at the attributes of the newly generated function Class2::myfunc(), I see that now only the Pure attribute is selected. When I generate code out of this I get the following:

Code: [Select]

#include "Class1.h"

class Class2 : public Class1
{
public:
 Class2();
 virtual ~Class2();
 void myfunc() =0;
};
This is bad!

4. I can do the same by using the Class1 quicklink, creating a new class Class3 as a Specialization of Class1. When I do that I get the same code as above for Class2.

I am quite sure I used this feature (the Override & Implementation dialog) before, but wasn't aware of any problems so far, so I strongly suspect I inadvertantly changed a setting that I shouldn't. I can't for the life of me think of what that might have been however...  

[Paolo F Cantoni]

3. Using the Class2 quicklink, I draw a Generalization link to Class1. This opens the Override & Implementation dialog for me, presenting the function Class1::myfunc(). I select that function and close the dialog. When I look at the attributes of the newly generated function Class2::myfunc(), I see that now only the Pure attribute is selected.

My view, as expressed above, is that this behaviour is conceptually incorrect.  You should get another Pure Virtual operation.

However, can you now try the following?

Delete the newly created operation out of Class2.  If you now select Class2 and then Element|Advanced>Overrides & Implementations [Ctrl+Shift+O], myfunc should now reappear (as per the original dialog - when you first created the Specialization).  Select myfunc again.  Do you get the same outcome as originally (Pure non-Virtual)?

If so, then your EA is NOT behaving correctly (though consistently .  I know of NO settings to create your observed behaviour although EA's UI (Unique Interface) may have one.

If not then you've just uncovered a bug.

HTH,
Paolo

[sl@sh]

Found it:
When I last created a new EA project I forgot to set the default language to C++. Since I was used to new classes being generated as C++ in my other EA projects I never even looked at this class property. Moreover, the first classes in my diagram were imported interface classes which were set to C++ automatically.

When I created the specialization links I didn't notice that the newly created class was set to java, so that's why I got the behavior described above.

When I set the base class language to C++ (within the general options dialog), none of the function properties get changed on inheritance, just like what Paolo said.

I still wonder though,

• why does EA create a java class as specializations of a C++ class (i. e. why does it set the language property of a class specialization to sth. different than that of the base class)?
  
  
• why does EA keep the Pure flag on function implementations (the answer to this may be that in other languages than C++ this might make sense. However, in C++ it doesn't)
  

P.S.: Sorry Paolo for taking so much of your time - I discovered the source of my problem at about the time of your second last posting, so I never even got to trying what you suggested. You might want to check your classes' language settings though  

I am running build 803 btw., so neither of the versions you tested.

P.P.S: the option I was referring to at the top of this posting is: Tools->Options->[Source Code Engeneering]->[Default Language for Code Generation]

[Paolo F Cantoni]

Yes, You're correct - if the language of the child class is NOT C++ you'll get your behaviour.  

(It's not to do with the EA version - like you, I had two sets of classes (two different .EAP files) in play with different languages)

There's no conceptual requirement that the child class be implemented in the same language as the parent.  You need to manage that yourself through EA's UI (Unique Interface).

Conceptually, you could apply some of the transformations mentioned in my original link and end up with a pure virtual child of a pure virtual parent.  Somewhere along the line, you do need to create an effective class but not necessarily on the first specialization.

However, this behaviour (Pure non-Virtual) is conceptually wrong (regardless of the child class' language).

Can you report the bug in the normal manner we usually recommend?

Paolo

[sl@sh]

I used the Registered Bug Report form to report this bug and linked to this thread.

Stefan

P.S.: I can actually think of a case where it makes sense (even in C++) to override a method without wanting to implement it:

Code: [Select]

class Class1 {
protected:
 virtual void myfunc () = 0;
};
class Class2 : public Class1 {
public:
 virtual void myfunc () = 0;
};
In this case Class2 changes the visibility of myfunc to public, but still relies on further specializations to actually implement it.

So, Paolo, you were right: it might make sense to inherit a method as pure virtual, even in C++ (and certainly conceptually).

[Eve]

We have confirmed that there is an issue with the currenty build not disabling the pure flag when implementing pure operations from the dialog mentioned.   We will fix this in a future build.

PS. Regarding it being said that the user needs to specify when an operation should be implemented.  The dialog shown when a generalization is created is prompting the user to make that exact choice.

[Paolo F Cantoni]

We have confirmed that there is an issue with the current build not disabling the pure flag when implementing pure operations from the dialog mentioned.   We will fix this in a future build.

PS. Regarding it being said that the user needs to specify when an operation should be implemented.  The dialog shown when a generalization is created is prompting the user to make that exact choice.

The proposition concerned the nature of the implementation.  It is accepted that the dialog specifies when.  The question was about the outcome of selecting "now".  The current bug takes the choice of implementation away from the user.

Clarifying,
Paolo

[sl@sh]

Looks like Simon refers to the 'Implementation' part of the dialog title whereas Paolo concentrates on the 'Override' part.

There's two ways a method can conceptually be inherited: either by overriding the original definition without actually implementing it (see my example above: changing visibility), or by actually implementing the method.

Since the dialog causing the problem is labelled Override &  Implementation both variants should be supported. If this is not the case, the title should be corrected according to whatever the sparxians meant it to do. (Implementation, for the moment being)