Project

General

Profile

Task #5860

Разделение сигналов в VariableContainer

Added by Igor Melnichenko over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Model
Target version:
Start date:
04/19/2015
Due date:
% Done:

100%

Estimated time:
Detected in build:
svn
Published in build:
20150701

Description

Предлагаю в VariableContainer ввести разделение переменных по типу: вход/выход/внутренняя переменная.
Относительно способов хранения и добавления переменных у меня предпочтений нет. Что касается получения их объявлений из контейнера, предлагаю такие методы:
public Set<VariableDeclaration> getDeclarations() //возвращает все объявления
public Set<VariableDeclaration> getInputDeclarations() //возвращает объявления входных переменных (включая inout-переменные)
public Set<VariableDeclaration> getOutputDeclarations() //возвращает объявления выходных переменных (включая inout-переменные)
public Set<VariableDeclaration> getInnerVariableDeclarations() //возвращает объявления внутренних переменных

Далее по аналогичному принципу:
public boolean containsVariable(String variableName)
public boolean containsInput(String variableName)
public boolean containsOutput(String variableName)
public boolean containsInnerVariable(String variableName)

public VariableDeclaration getDeclaration(String variableName)
public VariableDeclaration getInputDeclaration(String variableName)
public VariableDeclaration getOutputDeclaration(String variableName)
public VariableDeclaration getInnerVariableDeclaration(String variableName)

History

#1

Updated by Sergey Smolov over 4 years ago

  • Status changed from New to Open
#2

Updated by Sergey Smolov over 4 years ago

  • Status changed from Open to Feedback

1. The method with signature "Collection<VariableDeclaration> getDeclarations()" is already implemented. Is it really important to add another one with "Set<VariableDeclaration> getDeclarations()" signature?

2. As it is proposed to implement methods like "containsInput\Output" maybe we change other method names to "getInputs" and "getInput" for shortening?

3. Another renaming is proposed for making methods names shorter: InnerVariable -> Register.

4. Shall get-methods of the last group return null, if there is no variable with the specified name in this container?

#3

Updated by Igor Melnichenko over 4 years ago

Sergey Smolov wrote:

1. The method with signature "Collection<VariableDeclaration> getDeclarations()" is already implemented. Is it really important to add another one with "Set<VariableDeclaration> getDeclarations()" signature?

2. As it is proposed to implement methods like "containsInput\Output" maybe we change other method names to "getInputs" and "getInput" for shortening?

3. Another renaming is proposed for making methods names shorter: InnerVariable -> Register.

4. Shall get-methods of the last group return null, if there is no variable with the specified name in this container?

1. A return type isn't part of a signature, so I think it would be better to replace Collection by Set to emphasise uniqueness of collection elements. But it is not essential.

2. OK.

3. OK.

4. Yes.

#4

Updated by Sergey Smolov over 4 years ago

  • Status changed from Feedback to Open
#5

Updated by Sergey Smolov over 4 years ago

  • Status changed from Open to Feedback

I think that the internal data structure for variables and their declarations looks exhaustive. In fact, the variable name is a key and it is in the NodeVariable field of
VariableDeclaration class too. So I propose not to keep in the VariableDeclaration the NodeVariable itself.

Shall proposed get-methods return a pair "NodeVariable - VariableDeclaration" in this case?

#6

Updated by Igor Melnichenko over 4 years ago

I propose to split the getDeclaration methods to getDataType, getInitialValue and getInvariantCondition methods and do not return VariableDeclaration explicitly.

#7

Updated by Sergey Smolov over 4 years ago

I don't catch the idea.

The task was to implement the following methods:

1) multiple-get-methods:

public Set<VariableDeclaration> getDeclarations()
public Set<VariableDeclaration> getInputDeclarations()
public Set<VariableDeclaration> getOutputDeclarations()
public Set<VariableDeclaration> getInnerVariableDeclarations()

2) contains-methods:

public boolean containsVariable(String variableName)
public boolean containsInput(String variableName)
public boolean containsOutput(String variableName)
public boolean containsInnerVariable(String variableName)

3) single-get-methods:

public VariableDeclaration getDeclaration(String variableName)
public VariableDeclaration getInputDeclaration(String variableName)
public VariableDeclaration getOutputDeclaration(String variableName)
public VariableDeclaration getInnerVariableDeclaration(String variableName).

Suppose that VariableContainer keeps information in the Map<NodeVariable, VariableDeclaration> object, where VariableDeclaration keeps only invariant and initial value of the key NodeVariable.

How should change the proposed methods (multiple-get, single-get)?

#8

Updated by Igor Melnichenko over 4 years ago

Oh, I forget about the first group. For my classes these accessor methods are preferred:

1)

public Set<String> getVariables() //or getVariableNames and so on for other methods of this group
public Set<String> getInputs()
public Set<String> getOutputs()
public Set<String> getRegisters()

2) The second group is OK.

3) And now I think the third group may have no division based on variable types:

public DataType getDataType(String variableName)
public Node getInitialValue(String variableName)
public Node getInvariantCondition(String variableName)

#9

Updated by Igor Melnichenko over 4 years ago

And may be it is worth using maps of the form Map<String, VariableDeclaration> inside VariableContainer where VariableDeclaration contains DataType and two Nodes (initial value and invariant).

#10

Updated by Sergey Smolov over 4 years ago

Having such structure as "String -> <DataType, Node, Node>" the task to identify which declaration is for input signal, becomes impossible. We need to store the NodeVariable object somehow because it contains VariableData descriptor in it's userdata field.

#11

Updated by Sergey Smolov over 4 years ago

  • Status changed from Feedback to Open
#12

Updated by Sergey Smolov over 4 years ago

  • Status changed from Open to Resolved
  • % Done changed from 0 to 100

Done in r1867.

#13

Updated by Igor Melnichenko over 4 years ago

  • Status changed from Resolved to Verified
#14

Updated by Sergey Smolov over 4 years ago

  • Category set to 125
#15

Updated by Sergey Smolov about 4 years ago

  • Status changed from Verified to Closed
  • Published in build set to 20150701

Also available in: Atom PDF