|
|
Re: Use object as type instead of String [message #1779361 is a reply to message #1779359] |
Fri, 05 January 2018 17:38 |
Dennis Melzer Messages: 48 Registered: December 2014 |
Member |
|
|
The EObject is ok as well.
Currently the value is always a String (at the modell class), but it can be null or 112 or 11.2. or "A".
The issue is I do not know the original value anymore.
Small example with null:
@Test
public void parseNull() {
final String value = null;
String expression = "eq"+ value;
//parsing...
Eq eq;
assertThat(eq.getValue()).isEqualTo(value);
}
JUnit result said: Expected null Actual: "null"
Thanks for your help
[Updated on: Fri, 05 January 2018 17:39] Report message to a moderator
|
|
|
|
Re: Use object as type instead of String [message #1779371 is a reply to message #1779367] |
Fri, 05 January 2018 18:06 |
Dennis Melzer Messages: 48 Registered: December 2014 |
Member |
|
|
Christian Dietrich wrote on Fri, 05 January 2018 17:51that sounds like a parse error?!?
Why should this be a parse error?
Christian Dietrich wrote on Fri, 05 January 2018 17:51
the question is your semantic?
The semantic is like:
eq(attribute, "a") or eq(attribute, 1) or eq(attribute, null)
Christian Dietrich wrote on Fri, 05 January 2018 17:51
wouldnt it be better to have a StringLiteral, a NumberLiteral, and Null as separate types?
Do you mean something like this:
Instead of
Eq:
'eq' '(' attribute=FIELD_VALUE ',' value=STRING | INT | NULL')';
this:
Eq:
EqString | EqInt ...
EqString:
'eq' '(' attribute=FIELD_VALUE ',' value=STRING')';
EqInt:
'eq' '(' attribute=FIELD_VALUE ',' value=INT')';
|
|
|
Re: Use object as type instead of String [message #1779372 is a reply to message #1779367] |
Fri, 05 January 2018 18:07 |
Dennis Melzer Messages: 48 Registered: December 2014 |
Member |
|
|
Christian Dietrich wrote on Fri, 05 January 2018 17:51that sounds like a parse error?!?
Why should this be a parse error?
Christian Dietrich wrote on Fri, 05 January 2018 17:51
the question is your semantic?
The semantic is like:
eq(attribute, "a") or eq(attribute, 1) or eq(attribute, null)
Christian Dietrich wrote on Fri, 05 January 2018 17:51
wouldnt it be better to have a StringLiteral, a NumberLiteral, and Null as separate types?
Do you mean something like this:
Instead of
Eq:
'eq' '(' attribute=FIELD_VALUE ',' value=STRING | INT | NULL')';
this:
Eq:
EqString | EqInt ...
EqString:
'eq' '(' attribute=FIELD_VALUE ',' value=STRING')';
EqInt:
'eq' '(' attribute=FIELD_VALUE ',' value=INT')';
|
|
|
Re: Use object as type instead of String [message #1779373 is a reply to message #1779367] |
Fri, 05 January 2018 18:07 |
Dennis Melzer Messages: 48 Registered: December 2014 |
Member |
|
|
Christian Dietrich wrote on Fri, 05 January 2018 17:51that sounds like a parse error?!?
Why should this be a parse error?
Christian Dietrich wrote on Fri, 05 January 2018 17:51
the question is your semantic?
The semantic is like:
eq(attribute, "a") or eq(attribute, 1) or eq(attribute, null)
Christian Dietrich wrote on Fri, 05 January 2018 17:51
wouldnt it be better to have a StringLiteral, a NumberLiteral, and Null as separate types?
Do you mean something like this:
Instead of
Eq:
'eq' '(' attribute=FIELD_VALUE ',' value=STRING | INT | NULL')';
this:
Eq:
EqString | EqInt ...
EqString:
'eq' '(' attribute=FIELD_VALUE ',' value=STRING')';
EqInt:
'eq' '(' attribute=FIELD_VALUE ',' value=INT')';
|
|
|
|
Re: Use object as type instead of String [message #1779375 is a reply to message #1779367] |
Fri, 05 January 2018 18:08 |
Dennis Melzer Messages: 48 Registered: December 2014 |
Member |
|
|
Christian Dietrich wrote on Fri, 05 January 2018 17:51that sounds like a parse error?!?
Why should this be a parse error?
Christian Dietrich wrote on Fri, 05 January 2018 17:51
the question is your semantic?
The semantic is like:
eq(attribute, "a") or eq(attribute, 1) or eq(attribute, null)
Christian Dietrich wrote on Fri, 05 January 2018 17:51
wouldnt it be better to have a StringLiteral, a NumberLiteral, and Null as separate types?
Do you mean something like this:
Instead of
Eq:
'eq' '(' attribute=FIELD_VALUE ',' value=STRING | INT | NULL')';
this:
Eq:
EqString | EqInt ...
EqString:
'eq' '(' attribute=FIELD_VALUE ',' value=STRING')';
EqInt:
'eq' '(' attribute=FIELD_VALUE ',' value=INT')';
|
|
|
|
|
|
|
|
|
|
|
|
Re: Use object as type instead of String [message #1779466 is a reply to message #1779461] |
Mon, 08 January 2018 10:39 |
Dennis Melzer Messages: 48 Registered: December 2014 |
Member |
|
|
Christian Dietrich wrote on Mon, 08 January 2018 10:23why do you want to?
Because a EObject is a interface and a Object is easier to use:
This will not compile if the list contains EObjects
assertThat(inFilter.getValues()).contains("a", "b");
I found this solution, but this no good idea, becuase the conversion is not working anymore
Literal returns ecore::EJavaObject:
StringOrNumberLiteral | BOOLEAN | NULL;
StringOrNumberLiteral returns ecore::EJavaObject:
(STRING | NUMBER);
[Updated on: Mon, 08 January 2018 11:58] Report message to a moderator
|
|
|
Re: Use object as type instead of String [message #1779472 is a reply to message #1779462] |
Mon, 08 January 2018 12:17 |
Dennis Melzer Messages: 48 Registered: December 2014 |
Member |
|
|
Christian Dietrich wrote on Mon, 08 January 2018 10:24and how does the grammar look like. maybe you did something wrong
Currently looks like, but iam not happy with it.
That's way too many classes. That's why an object would be my favorite. Is that not possible?
Literal returns ecore::EObject:
(StringOrNumberLiteral | BooleanValue | NullValue);
StringOrNumberLiteral returns ecore::EObject:
(StringLiteral | NumberValue);
StringLiteral returns ecore::EObject:
StringValue;
StringValue:
value = STRING;
NumberValue:
value = DOUBLE;
BooleanValue:
value = BOOLEAN;
NullValue:
value = NULL;
:
[Updated on: Mon, 08 January 2018 12:35] Report message to a moderator
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.08998 seconds