New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wrong code generation for guards because of misinterpreting method calls #870

Closed
vahdat-ab opened this Issue Jun 29, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@vahdat-ab
Member

vahdat-ab commented Jun 29, 2016

Consider the following code:

class CrFwOutCmp{
    Boolean getData = false;
    Boolean data(){
        return true;
    } 
    sm{
        so{
            go [getData()] -> so;
        }
    }
}

The generated code for event go is as follows.

public boolean go()
  {
    boolean wasEventProcessed = false;

    Sm aSm = sm;
    switch (aSm)
    {
      case so:
        if (getGetData()())
        {
          setSm(Sm.so);
          wasEventProcessed = true;
          break;
        }
        break;
      default:
        // Other states do respond to this event
    }

    return wasEventProcessed;
  }

Check this code out if (getGetData()()). The method is considered as an attribute and it's replaced with its get method. This is wrong because the code meant the method.

@tlaport4

This comment has been minimized.

Contributor

tlaport4 commented Dec 13, 2016

After fixing issue #819, it produces the following code:

public boolean go()
  {
    boolean wasEventProcessed = false;

    Sm aSm = sm;
    switch (aSm)
    {
      case so:
        if (getData())
        {
          setSm(Sm.so);
          wasEventProcessed = true;
          break;
        }
        break;
      default:
        // Other states do respond to this event
    }

    return wasEventProcessed;
  }

So, it now uses the method getData() as stated in the umple code. However, this method isn't defined and it doesn't actually exist. Is this how it should be?

@vahdat-ab

This comment has been minimized.

Member

vahdat-ab commented Dec 13, 2016

Yes, it's been fixed. It would be good to show a warning regarding this case. I mean, if there is a method called in the guard and there is not implementation for it inside its superclasses, interfaces, traits, and other events related to state machines then a warning must be raised. It can be considered as an error as well.

@TimLethbridge

This comment has been minimized.

Member

TimLethbridge commented Sep 5, 2018

Methods as well cal call other methods that may not exist. These are detected by the target language compiler. I think it is best to leave this to the target language compiler too. There are just too many cases to check otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment