Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » ToStringVisitorImpl.toString returning null
| ToStringVisitorImpl.toString returning null [message #34554] |
Fri, 19 May 2006 14:26  |
Eclipse User |
|
|
|
Originally posted by: jgreen.upb.de
Hi,
I observed the method ToStringVisitorImpl.toString(Visitable v) returning null.
While creating e.g. a Variable through the reflective API mechanism, the method returns null. Probably because not all
features have been initialized corretly. Changing the method as shown works fine so far.
public static String toString(Visitable v) {
return (String) v.accept(getInstance()) + "";
}
I don't know if this is a bug or if there might be more general problems with what I'm doing?
Joel
|
|
|
| Re: ToStringVisitorImpl.toString returning null [message #34689 is a reply to message #34554] |
Tue, 23 May 2006 10:23  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Joel,
The toString() is really only intended for debugging purposes, because a
correct AST-to-Text convertor would have to account for operator precedence
and other constructs (such as if..then..else..endif) that require smart
parenthesization (as the AST has no parentheses).
However, I would like it to work reasonably well, and I think that returning
null is not particularly reasonable.
The only way that you should be able to get null for a Variable's toString
is if the variable has no name. This is not a valid variable, so there is
no corresponding valid text. I would rather display, in this case,
"<unnamed variable>" or some such for the name so that an expressions'
toString() will indicate where the problem is.
Would you mind opening a bug? Just click here:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EMFT& ;version=1.0&component=OCL&form_name=enter_bug
Thanks,
Christian
Joel Greenyer wrote:
> Hi,
> I observed the method ToStringVisitorImpl.toString(Visitable v) returning
> null.
>
> While creating e.g. a Variable through the reflective API mechanism, the
> method returns null. Probably because not all features have been
> initialized corretly. Changing the method as shown works fine so far.
>
> public static String toString(Visitable v) {
> return (String) v.accept(getInstance()) + "";
> }
>
> I don't know if this is a bug or if there might be more general problems
> with what I'm doing?
>
>
> Joel
|
|
| |
| Re: ToStringVisitorImpl.toString returning null [message #34939 is a reply to message #34861] |
Wed, 24 May 2006 23:12 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed,
In my experience, Object.toString() isn't an API that production code
should use. Most objects don't provide anything useful (often just
"<class-name>@<memory-address>") and very few specify the content of their
string representations. I like JFace's and EMF's approach of delegating
the calculation of displayable strings to third parties (label providers).
Unfortunately, many APIs do seem to assume that toString() provides
something useful, so it behooves objects like OCL expressions to try hard
not to throw NPEs in this method.
At this point in the release, it's hard to do more for bugs such as 125079
than what they ask for. However, if you have a robust implementation to
contribute, I will be more than happy to accept it! It would be great to
have help to make the ToStringVisitorImpl more tolerant of invalid
expression models; it's a big job, and there is so much else to do ...
Perhaps you can raise a bugzilla and attach your RobustToStringVisitor to
it? And if you can provide JUnit tests, so much the better.
Eventually, EMFT OCL will have to provide a specific public API for
transforming expression models to text. That will be a more "correct"
solution. Until then, of course, we only have toString().
Cheers,
Christian
P.S. - there are other issues in the fidelity of the string rendered by
ToStringVisitorImpl, for which help would be appreciated:
- rendering operators with infix notation (not, e.g., "a.+(b)"), which
would incidentally require parenthesization
- eliding implicit iterator variables (no ugly "temp4"s)
- simplifying type references, to use unqualified names where possible
- (I'm sure there are more)
|
|
| | |
| Re: ToStringVisitorImpl.toString returning null [message #35393 is a reply to message #35360] |
Fri, 26 May 2006 07:54 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------090502000709080501010905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
Wilson, our new co-op student, is starting to work on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933 so we should be in
much better shape next release to weed out Ecore model badness before it
breaks downstream code that expects well-formed Ecore models...
Christian W. Damus wrote:
> Ed Willink wrote:
>
>
>> Hi Christian
>>
>>
>>
>>> In my experience, Object.toString() isn't an API that production code
>>> should use.
>>>
>> I agree. My usage/problems arose while developing code that
>> generated OCL models and then attempted to persist them fully. My
>> code was not entirely bug free especially as OCL drifted towards strict
>> compliance. So I was particularly sensitive to the quality of the
>> toString() method as invoked by JDT, which has also improved. The
>> NPEs hiding debug output and sometimes even disrupting debug operation
>> were very unhelpful.
>>
>
> I agree. The toString() works great for well-formed OCL and debugging
> problems with well-formed expressions, but was rather useless for debugging
> bad OCL expressions, themselves!
>
>
>> My RobustToStringVisitor was a pragmatic hack fixing apparent hazards
>> intuitively. It certainly didn't fix all problems, it had no tests.
>> But it did help me discover which 'optional' OCL attributes were
>> actually mandatory. It has been attached to Bug 143882.
>>
>
> Great! Thanks. I'll have a look at it ASAP. I have an idea how to work it
> into our tests to ensure that well-formed expressions, at least, will
> always succeed in producing a toString.
>
> BTW, would you happen to know off-hand (or have a list in your back pocket)
> of which properties are optional in the Ecore model but actually mandatory?
> It's quite probable that there are still some mismatches in this regard
> between the Ecore and the spec.
>
>
>> Custom formatters are indeed a better approach.
>>
>> Perhaps you should regard maximising utility within JDT as the design
>> goal for toString(). This might suggest retaining a.+(b) to more
>> clearly reflect the object structure.
>>
>
> Good point. That sounds like the right approach.
>
> Thanks again!
>
> Christian
>
>
>> Regards
>>
>> Ed Willink
>>
>
>
--------------090502000709080501010905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
Wilson, our new co-op student, is starting to work on <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933">https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933</a>
so we should be in much better shape next release to weed out Ecore
model badness before it breaks downstream code that expects well-formed
Ecore models...<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mide56ort$icc$1@utils.eclipse.org" type="cite">
<pre wrap="">Ed Willink wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Christian
</pre>
<blockquote type="cite">
<pre wrap="">In my experience, Object.toString() isn't an API that production code
should use.
</pre>
</blockquote>
<pre wrap="">I agree. My usage/problems arose while developing code that
generated OCL models and then attempted to persist them fully. My
code was not entirely bug free especially as OCL drifted towards strict
compliance. So I was particularly sensitive to the quality of the
toString() method as invoked by JDT, which has also improved. The
NPEs hiding debug output and sometimes even disrupting debug operation
were very unhelpful.
</pre>
</blockquote>
<pre wrap=""><!---->
I agree. The toString() works great for well-formed OCL and debugging
problems with well-formed expressions, but was rather useless for debugging
bad OCL expressions, themselves!
</pre>
<blockquote type="cite">
<pre wrap="">My RobustToStringVisitor was a pragmatic hack fixing apparent hazards
intuitively. It certainly didn't fix all problems, it had no tests.
But it did help me discover which 'optional' OCL attributes were
actually mandatory. It has been attached to Bug 143882.
</pre>
</blockquote>
<pre wrap=""><!---->
Great! Thanks. I'll have a look at it ASAP. I have an idea how to work it
into our tests to ensure that well-formed expressions, at least, will
always succeed in producing a toString.
BTW, would you happen to know off-hand (or have a list in your back pocket)
of which properties are optional in the Ecore model but actually mandatory?
It's quite probable that there are still some mismatches in this regard
between the Ecore and the spec.
</pre>
<blockquote type="cite">
<pre wrap="">Custom formatters are indeed a better approach.
Perhaps you should regard maximising utility within JDT as the design
goal for toString(). This might suggest retaining a.+(b) to more
clearly reflect the object structure.
</pre>
</blockquote>
<pre wrap=""><!---->
Good point. That sounds like the right approach.
Thanks again!
Christian
</pre>
<blockquote type="cite">
<pre wrap="">Regards
Ed Willink
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------090502000709080501010905--
|
|
|
| Re: ToStringVisitorImpl.toString returning null [message #35915 is a reply to message #35360] |
Sun, 04 June 2006 04:27 |
| Eclipse User |
|
|
|
Christian W. Damus wrote:
> BTW, would you happen to know off-hand (or have a list in your back pocket)
> of which properties are optional in the Ecore model but actually mandatory?
> It's quite probable that there are still some mismatches in this regard
> between the Ecore and the spec.
The following is a vaguely remembered list of nightmare debugs that I have had over
the past couple of years. EMF error handling has improved dramatically in that time and
I have reported a fair number of bugs so it may well be that some of the following
no longer apply.
XMI semantic errors used to be catastrophic, now bad references are often
correctly diagnosed, but I still end up in the attempt to use the null feature
NPE more often than I like, and it's very hard to diagnose.
Derived Java code for a model can enforce a stricter type on a model element, and
it works just fine until a model is read that explicitly xsi:type="...:... ..." provides
an insufficiently strict class. The resulting CCE occurs in subsequent usage rather
than during the model read. I no longer try to use stricter types, though I think
MOF would allow it.
A null ENamedElement.name can be quite unforgiving.
A null ETypedElement.eType/EReference.eReferenceType/EAttribute/eAt tributeType can be very unforgiving.
EMF itself (create/loadResource is pretty good) it's genModel where the nightmares
begin. Bad models can/could variously cause models to be unloadable, or for
referenced genmodels to be unconfigurable or for code generation to fail sometimes
silently. It is unhelpful that the genmodel progress monitor is far from
uniform rate; the last bits are very quick especially for a silent failure.
A null EDataType.instanceClassName is really bad, and quite reasonable when
EMF is perceived as a generic modeling capability rather than a Java code generator.
A null EPackage.nsURI is similarly bad and reasonable.
It would be nice if genModel could automatically provide defaults for everything that
is missing from a model only file.
- offer java.lang elements for EDataTypes
- offer default URIs
rather than barf.
Incorrect containment is one of my regular problems. Using the Ecore editor, it is very
hard to check that relationships are correct. It is only when a UML-like presentation is
used that stipidities are self evident. I suspect that there are some useful diagnostics
that a nanny-mode might support - for instance, perhaps no model element other than the
root should lack a potential container.
|
|
|
| Re: ToStringVisitorImpl.toString returning null [message #35949 is a reply to message #35915] |
Sun, 04 June 2006 08:13 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------000703020008020207090602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
The problems you list will be diagnosed as constraint violations when
this is done:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933
We've started work on it so it will be available early in the next
development cycle.
Keep in mind that in an open source community it's also possible to help
yourself by helping the community, i.e., donations will accomplish more
than will hand wringing...
Ed Willink wrote:
> Christian W. Damus wrote:
>
>> BTW, would you happen to know off-hand (or have a list in your back
>> pocket)
>> of which properties are optional in the Ecore model but actually
>> mandatory? It's quite probable that there are still some mismatches
>> in this regard
>> between the Ecore and the spec.
>
> The following is a vaguely remembered list of nightmare debugs that I
> have had over
> the past couple of years. EMF error handling has improved dramatically
> in that time and
> I have reported a fair number of bugs so it may well be that some of
> the following
> no longer apply.
>
> XMI semantic errors used to be catastrophic, now bad references are often
> correctly diagnosed, but I still end up in the attempt to use the null
> feature
> NPE more often than I like, and it's very hard to diagnose.
>
> Derived Java code for a model can enforce a stricter type on a model
> element, and
> it works just fine until a model is read that explicitly
> xsi:type="...:... ..." provides
> an insufficiently strict class. The resulting CCE occurs in subsequent
> usage rather
> than during the model read. I no longer try to use stricter types,
> though I think
> MOF would allow it.
>
> A null ENamedElement.name can be quite unforgiving.
>
> A null
> ETypedElement.eType/EReference.eReferenceType/EAttribute/eAt tributeType
> can be very unforgiving.
>
> EMF itself (create/loadResource is pretty good) it's genModel where
> the nightmares
> begin. Bad models can/could variously cause models to be unloadable,
> or for
> referenced genmodels to be unconfigurable or for code generation to
> fail sometimes
> silently. It is unhelpful that the genmodel progress monitor is far from
> uniform rate; the last bits are very quick especially for a silent
> failure.
>
> A null EDataType.instanceClassName is really bad, and quite reasonable
> when
> EMF is perceived as a generic modeling capability rather than a Java
> code generator.
>
> A null EPackage.nsURI is similarly bad and reasonable.
>
> It would be nice if genModel could automatically provide defaults for
> everything that
> is missing from a model only file.
> - offer java.lang elements for EDataTypes
> - offer default URIs
> rather than barf.
>
> Incorrect containment is one of my regular problems. Using the Ecore
> editor, it is very
> hard to check that relationships are correct. It is only when a
> UML-like presentation is
> used that stipidities are self evident. I suspect that there are some
> useful diagnostics
> that a nanny-mode might support - for instance, perhaps no model
> element other than the
> root should lack a potential container.
>
--------------000703020008020207090602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed,<br>
<br>
The problems you list will be diagnosed as constraint violations when
this is done:<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933">https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933</a><br>
</blockquote>
We've started work on it so it will be available early in the next
development cycle.<br>
<br>
Keep in mind that in an open source community it's also possible to
help yourself by helping the community, i.e., donations will accomplish
more than will hand wringing...<br>
<br>
<br>
Ed Willink wrote:
<blockquote cite="mide5u5h5$530$1@utils.eclipse.org" type="cite">Christian
W. Damus wrote:
<br>
<br>
<blockquote type="cite">BTW, would you happen to know off-hand (or
have a list in your back pocket)
<br>
of which properties are optional in the Ecore model but actually
mandatory? It's quite probable that there are still some mismatches in
this regard
<br>
between the Ecore and the spec.
<br>
</blockquote>
<br>
The following is a vaguely remembered list of nightmare debugs that I
have had over
<br>
the past couple of years. EMF error handling has improved dramatically
in that time and
<br>
I have reported a fair number of bugs so it may well be that some of
the following
<br>
no longer apply.
<br>
<br>
XMI semantic errors used to be catastrophic, now bad references are
often
<br>
correctly diagnosed, but I still end up in the attempt to use the null
feature
<br>
NPE more often than I like, and it's very hard to diagnose.
<br>
<br>
Derived Java code for a model can enforce a stricter type on a model
element, and
<br>
it works just fine until a model is read that explicitly
xsi:type="...:... ..." provides
<br>
an insufficiently strict class. The resulting CCE occurs in subsequent
usage rather
<br>
than during the model read. I no longer try to use stricter types,
though I think
<br>
MOF would allow it.
<br>
<br>
A null ENamedElement.name can be quite unforgiving.
<br>
<br>
A null
ETypedElement.eType/EReference.eReferenceType/EAttribute/eAt tributeType
can be very unforgiving.
<br>
<br>
EMF itself (create/loadResource is pretty good) it's genModel where the
nightmares
<br>
begin. Bad models can/could variously cause models to be unloadable, or
for
<br>
referenced genmodels to be unconfigurable or for code generation to
fail sometimes
<br>
silently. It is unhelpful that the genmodel progress monitor is far
from
<br>
uniform rate; the last bits are very quick especially for a silent
failure.
<br>
<br>
A null EDataType.instanceClassName is really bad, and quite reasonable
when
<br>
EMF is perceived as a generic modeling capability rather than a Java
code generator.
<br>
<br>
A null EPackage.nsURI is similarly bad and reasonable.
<br>
<br>
It would be nice if genModel could automatically provide defaults for
everything that
<br>
is missing from a model only file.
<br>
- offer java.lang elements for EDataTypes
<br>
- offer default URIs
<br>
rather than barf.
<br>
<br>
Incorrect containment is one of my regular problems. Using the Ecore
editor, it is very
<br>
hard to check that relationships are correct. It is only when a
UML-like presentation is
<br>
used that stipidities are self evident. I suspect that there are some
useful diagnostics
<br>
that a nanny-mode might support - for instance, perhaps no model
element other than the
<br>
root should lack a potential container.
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------000703020008020207090602--
|
|
|
| Re: ToStringVisitorImpl.toString returning null [message #578354 is a reply to message #34554] |
Tue, 23 May 2006 10:23 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Joel,
The toString() is really only intended for debugging purposes, because a
correct AST-to-Text convertor would have to account for operator precedence
and other constructs (such as if..then..else..endif) that require smart
parenthesization (as the AST has no parentheses).
However, I would like it to work reasonably well, and I think that returning
null is not particularly reasonable.
The only way that you should be able to get null for a Variable's toString
is if the variable has no name. This is not a valid variable, so there is
no corresponding valid text. I would rather display, in this case,
"<unnamed variable>" or some such for the name so that an expressions'
toString() will indicate where the problem is.
Would you mind opening a bug? Just click here:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EMFT& ;version=1.0&component=OCL&form_name=enter_bug
Thanks,
Christian
Joel Greenyer wrote:
> Hi,
> I observed the method ToStringVisitorImpl.toString(Visitable v) returning
> null.
>
> While creating e.g. a Variable through the reflective API mechanism, the
> method returns null. Probably because not all features have been
> initialized corretly. Changing the method as shown works fine so far.
>
> public static String toString(Visitable v) {
> return (String) v.accept(getInstance()) + "";
> }
>
> I don't know if this is a bug or if there might be more general problems
> with what I'm doing?
>
>
> Joel
|
|
| |
| Re: ToStringVisitorImpl.toString returning null [message #578544 is a reply to message #34861] |
Wed, 24 May 2006 23:12 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed,
In my experience, Object.toString() isn't an API that production code
should use. Most objects don't provide anything useful (often just
"<class-name>@<memory-address>") and very few specify the content of their
string representations. I like JFace's and EMF's approach of delegating
the calculation of displayable strings to third parties (label providers).
Unfortunately, many APIs do seem to assume that toString() provides
something useful, so it behooves objects like OCL expressions to try hard
not to throw NPEs in this method.
At this point in the release, it's hard to do more for bugs such as 125079
than what they ask for. However, if you have a robust implementation to
contribute, I will be more than happy to accept it! It would be great to
have help to make the ToStringVisitorImpl more tolerant of invalid
expression models; it's a big job, and there is so much else to do ...
Perhaps you can raise a bugzilla and attach your RobustToStringVisitor to
it? And if you can provide JUnit tests, so much the better.
Eventually, EMFT OCL will have to provide a specific public API for
transforming expression models to text. That will be a more "correct"
solution. Until then, of course, we only have toString().
Cheers,
Christian
P.S. - there are other issues in the fidelity of the string rendered by
ToStringVisitorImpl, for which help would be appreciated:
- rendering operators with infix notation (not, e.g., "a.+(b)"), which
would incidentally require parenthesization
- eliding implicit iterator variables (no ugly "temp4"s)
- simplifying type references, to use unqualified names where possible
- (I'm sure there are more)
|
|
|
| Re: ToStringVisitorImpl.toString returning null [message #578975 is a reply to message #34939] |
Fri, 26 May 2006 01:16 |
| Eclipse User |
|
|
|
Hi Christian
> In my experience, Object.toString() isn't an API that production code
> should use.
I agree. My usage/problems arose while developing code that
generated OCL models and then attempted to persist them fully. My
code was not entirely bug free especially as OCL drifted towards strict
compliance. So I was particularly sensitive to the quality of the
toString() method as invoked by JDT, which has also improved. The
NPEs hiding debug output and sometimes even disrupting debug operation
were very unhelpful.
My RobustToStringVisitor was a pragmatic hack fixing apparent hazards
intuitively. It certainly didn't fix all problems, it had no tests.
But it did help me discover which 'optional' OCL attributes were
actually mandatory. It has been attached to Bug 143882.
Custom formatters are indeed a better approach.
Perhaps you should regard maximising utility within JDT as the design
goal for toString(). This might suggest retaining a.+(b) to more
clearly reflect the object structure.
Regards
Ed Willink
|
|
|
| Re: ToStringVisitorImpl.toString returning null [message #579028 is a reply to message #35293] |
Fri, 26 May 2006 07:30 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Ed Willink wrote:
> Hi Christian
>
>
>> In my experience, Object.toString() isn't an API that production code
>> should use.
>
> I agree. My usage/problems arose while developing code that
> generated OCL models and then attempted to persist them fully. My
> code was not entirely bug free especially as OCL drifted towards strict
> compliance. So I was particularly sensitive to the quality of the
> toString() method as invoked by JDT, which has also improved. The
> NPEs hiding debug output and sometimes even disrupting debug operation
> were very unhelpful.
I agree. The toString() works great for well-formed OCL and debugging
problems with well-formed expressions, but was rather useless for debugging
bad OCL expressions, themselves!
>
> My RobustToStringVisitor was a pragmatic hack fixing apparent hazards
> intuitively. It certainly didn't fix all problems, it had no tests.
> But it did help me discover which 'optional' OCL attributes were
> actually mandatory. It has been attached to Bug 143882.
Great! Thanks. I'll have a look at it ASAP. I have an idea how to work it
into our tests to ensure that well-formed expressions, at least, will
always succeed in producing a toString.
BTW, would you happen to know off-hand (or have a list in your back pocket)
of which properties are optional in the Ecore model but actually mandatory?
It's quite probable that there are still some mismatches in this regard
between the Ecore and the spec.
>
> Custom formatters are indeed a better approach.
>
> Perhaps you should regard maximising utility within JDT as the design
> goal for toString(). This might suggest retaining a.+(b) to more
> clearly reflect the object structure.
Good point. That sounds like the right approach.
Thanks again!
Christian
>
> Regards
>
> Ed Willink
|
|
|
| Re: ToStringVisitorImpl.toString returning null [message #579052 is a reply to message #35360] |
Fri, 26 May 2006 07:54 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------090502000709080501010905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
Wilson, our new co-op student, is starting to work on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933 so we should be in
much better shape next release to weed out Ecore model badness before it
breaks downstream code that expects well-formed Ecore models...
Christian W. Damus wrote:
> Ed Willink wrote:
>
>
>> Hi Christian
>>
>>
>>
>>> In my experience, Object.toString() isn't an API that production code
>>> should use.
>>>
>> I agree. My usage/problems arose while developing code that
>> generated OCL models and then attempted to persist them fully. My
>> code was not entirely bug free especially as OCL drifted towards strict
>> compliance. So I was particularly sensitive to the quality of the
>> toString() method as invoked by JDT, which has also improved. The
>> NPEs hiding debug output and sometimes even disrupting debug operation
>> were very unhelpful.
>>
>
> I agree. The toString() works great for well-formed OCL and debugging
> problems with well-formed expressions, but was rather useless for debugging
> bad OCL expressions, themselves!
>
>
>> My RobustToStringVisitor was a pragmatic hack fixing apparent hazards
>> intuitively. It certainly didn't fix all problems, it had no tests.
>> But it did help me discover which 'optional' OCL attributes were
>> actually mandatory. It has been attached to Bug 143882.
>>
>
> Great! Thanks. I'll have a look at it ASAP. I have an idea how to work it
> into our tests to ensure that well-formed expressions, at least, will
> always succeed in producing a toString.
>
> BTW, would you happen to know off-hand (or have a list in your back pocket)
> of which properties are optional in the Ecore model but actually mandatory?
> It's quite probable that there are still some mismatches in this regard
> between the Ecore and the spec.
>
>
>> Custom formatters are indeed a better approach.
>>
>> Perhaps you should regard maximising utility within JDT as the design
>> goal for toString(). This might suggest retaining a.+(b) to more
>> clearly reflect the object structure.
>>
>
> Good point. That sounds like the right approach.
>
> Thanks again!
>
> Christian
>
>
>> Regards
>>
>> Ed Willink
>>
>
>
--------------090502000709080501010905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
Wilson, our new co-op student, is starting to work on <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933">https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933</a>
so we should be in much better shape next release to weed out Ecore
model badness before it breaks downstream code that expects well-formed
Ecore models...<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mide56ort$icc$1@utils.eclipse.org" type="cite">
<pre wrap="">Ed Willink wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Christian
</pre>
<blockquote type="cite">
<pre wrap="">In my experience, Object.toString() isn't an API that production code
should use.
</pre>
</blockquote>
<pre wrap="">I agree. My usage/problems arose while developing code that
generated OCL models and then attempted to persist them fully. My
code was not entirely bug free especially as OCL drifted towards strict
compliance. So I was particularly sensitive to the quality of the
toString() method as invoked by JDT, which has also improved. The
NPEs hiding debug output and sometimes even disrupting debug operation
were very unhelpful.
</pre>
</blockquote>
<pre wrap=""><!---->
I agree. The toString() works great for well-formed OCL and debugging
problems with well-formed expressions, but was rather useless for debugging
bad OCL expressions, themselves!
</pre>
<blockquote type="cite">
<pre wrap="">My RobustToStringVisitor was a pragmatic hack fixing apparent hazards
intuitively. It certainly didn't fix all problems, it had no tests.
But it did help me discover which 'optional' OCL attributes were
actually mandatory. It has been attached to Bug 143882.
</pre>
</blockquote>
<pre wrap=""><!---->
Great! Thanks. I'll have a look at it ASAP. I have an idea how to work it
into our tests to ensure that well-formed expressions, at least, will
always succeed in producing a toString.
BTW, would you happen to know off-hand (or have a list in your back pocket)
of which properties are optional in the Ecore model but actually mandatory?
It's quite probable that there are still some mismatches in this regard
between the Ecore and the spec.
</pre>
<blockquote type="cite">
<pre wrap="">Custom formatters are indeed a better approach.
Perhaps you should regard maximising utility within JDT as the design
goal for toString(). This might suggest retaining a.+(b) to more
clearly reflect the object structure.
</pre>
</blockquote>
<pre wrap=""><!---->
Good point. That sounds like the right approach.
Thanks again!
Christian
</pre>
<blockquote type="cite">
<pre wrap="">Regards
Ed Willink
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------090502000709080501010905--
|
|
|
| Re: ToStringVisitorImpl.toString returning null [message #579502 is a reply to message #35360] |
Sun, 04 June 2006 04:27 |
| Eclipse User |
|
|
|
Christian W. Damus wrote:
> BTW, would you happen to know off-hand (or have a list in your back pocket)
> of which properties are optional in the Ecore model but actually mandatory?
> It's quite probable that there are still some mismatches in this regard
> between the Ecore and the spec.
The following is a vaguely remembered list of nightmare debugs that I have had over
the past couple of years. EMF error handling has improved dramatically in that time and
I have reported a fair number of bugs so it may well be that some of the following
no longer apply.
XMI semantic errors used to be catastrophic, now bad references are often
correctly diagnosed, but I still end up in the attempt to use the null feature
NPE more often than I like, and it's very hard to diagnose.
Derived Java code for a model can enforce a stricter type on a model element, and
it works just fine until a model is read that explicitly xsi:type="...:... ..." provides
an insufficiently strict class. The resulting CCE occurs in subsequent usage rather
than during the model read. I no longer try to use stricter types, though I think
MOF would allow it.
A null ENamedElement.name can be quite unforgiving.
A null ETypedElement.eType/EReference.eReferenceType/EAttribute/eAt tributeType can be very unforgiving.
EMF itself (create/loadResource is pretty good) it's genModel where the nightmares
begin. Bad models can/could variously cause models to be unloadable, or for
referenced genmodels to be unconfigurable or for code generation to fail sometimes
silently. It is unhelpful that the genmodel progress monitor is far from
uniform rate; the last bits are very quick especially for a silent failure.
A null EDataType.instanceClassName is really bad, and quite reasonable when
EMF is perceived as a generic modeling capability rather than a Java code generator.
A null EPackage.nsURI is similarly bad and reasonable.
It would be nice if genModel could automatically provide defaults for everything that
is missing from a model only file.
- offer java.lang elements for EDataTypes
- offer default URIs
rather than barf.
Incorrect containment is one of my regular problems. Using the Ecore editor, it is very
hard to check that relationships are correct. It is only when a UML-like presentation is
used that stipidities are self evident. I suspect that there are some useful diagnostics
that a nanny-mode might support - for instance, perhaps no model element other than the
root should lack a potential container.
|
|
|
| Re: ToStringVisitorImpl.toString returning null [message #579541 is a reply to message #35915] |
Sun, 04 June 2006 08:13 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------000703020008020207090602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
The problems you list will be diagnosed as constraint violations when
this is done:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933
We've started work on it so it will be available early in the next
development cycle.
Keep in mind that in an open source community it's also possible to help
yourself by helping the community, i.e., donations will accomplish more
than will hand wringing...
Ed Willink wrote:
> Christian W. Damus wrote:
>
>> BTW, would you happen to know off-hand (or have a list in your back
>> pocket)
>> of which properties are optional in the Ecore model but actually
>> mandatory? It's quite probable that there are still some mismatches
>> in this regard
>> between the Ecore and the spec.
>
> The following is a vaguely remembered list of nightmare debugs that I
> have had over
> the past couple of years. EMF error handling has improved dramatically
> in that time and
> I have reported a fair number of bugs so it may well be that some of
> the following
> no longer apply.
>
> XMI semantic errors used to be catastrophic, now bad references are often
> correctly diagnosed, but I still end up in the attempt to use the null
> feature
> NPE more often than I like, and it's very hard to diagnose.
>
> Derived Java code for a model can enforce a stricter type on a model
> element, and
> it works just fine until a model is read that explicitly
> xsi:type="...:... ..." provides
> an insufficiently strict class. The resulting CCE occurs in subsequent
> usage rather
> than during the model read. I no longer try to use stricter types,
> though I think
> MOF would allow it.
>
> A null ENamedElement.name can be quite unforgiving.
>
> A null
> ETypedElement.eType/EReference.eReferenceType/EAttribute/eAt tributeType
> can be very unforgiving.
>
> EMF itself (create/loadResource is pretty good) it's genModel where
> the nightmares
> begin. Bad models can/could variously cause models to be unloadable,
> or for
> referenced genmodels to be unconfigurable or for code generation to
> fail sometimes
> silently. It is unhelpful that the genmodel progress monitor is far from
> uniform rate; the last bits are very quick especially for a silent
> failure.
>
> A null EDataType.instanceClassName is really bad, and quite reasonable
> when
> EMF is perceived as a generic modeling capability rather than a Java
> code generator.
>
> A null EPackage.nsURI is similarly bad and reasonable.
>
> It would be nice if genModel could automatically provide defaults for
> everything that
> is missing from a model only file.
> - offer java.lang elements for EDataTypes
> - offer default URIs
> rather than barf.
>
> Incorrect containment is one of my regular problems. Using the Ecore
> editor, it is very
> hard to check that relationships are correct. It is only when a
> UML-like presentation is
> used that stipidities are self evident. I suspect that there are some
> useful diagnostics
> that a nanny-mode might support - for instance, perhaps no model
> element other than the
> root should lack a potential container.
>
--------------000703020008020207090602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed,<br>
<br>
The problems you list will be diagnosed as constraint violations when
this is done:<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933">https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933</a><br>
</blockquote>
We've started work on it so it will be available early in the next
development cycle.<br>
<br>
Keep in mind that in an open source community it's also possible to
help yourself by helping the community, i.e., donations will accomplish
more than will hand wringing...<br>
<br>
<br>
Ed Willink wrote:
<blockquote cite="mide5u5h5$530$1@utils.eclipse.org" type="cite">Christian
W. Damus wrote:
<br>
<br>
<blockquote type="cite">BTW, would you happen to know off-hand (or
have a list in your back pocket)
<br>
of which properties are optional in the Ecore model but actually
mandatory? It's quite probable that there are still some mismatches in
this regard
<br>
between the Ecore and the spec.
<br>
</blockquote>
<br>
The following is a vaguely remembered list of nightmare debugs that I
have had over
<br>
the past couple of years. EMF error handling has improved dramatically
in that time and
<br>
I have reported a fair number of bugs so it may well be that some of
the following
<br>
no longer apply.
<br>
<br>
XMI semantic errors used to be catastrophic, now bad references are
often
<br>
correctly diagnosed, but I still end up in the attempt to use the null
feature
<br>
NPE more often than I like, and it's very hard to diagnose.
<br>
<br>
Derived Java code for a model can enforce a stricter type on a model
element, and
<br>
it works just fine until a model is read that explicitly
xsi:type="...:... ..." provides
<br>
an insufficiently strict class. The resulting CCE occurs in subsequent
usage rather
<br>
than during the model read. I no longer try to use stricter types,
though I think
<br>
MOF would allow it.
<br>
<br>
A null ENamedElement.name can be quite unforgiving.
<br>
<br>
A null
ETypedElement.eType/EReference.eReferenceType/EAttribute/eAt tributeType
can be very unforgiving.
<br>
<br>
EMF itself (create/loadResource is pretty good) it's genModel where the
nightmares
<br>
begin. Bad models can/could variously cause models to be unloadable, or
for
<br>
referenced genmodels to be unconfigurable or for code generation to
fail sometimes
<br>
silently. It is unhelpful that the genmodel progress monitor is far
from
<br>
uniform rate; the last bits are very quick especially for a silent
failure.
<br>
<br>
A null EDataType.instanceClassName is really bad, and quite reasonable
when
<br>
EMF is perceived as a generic modeling capability rather than a Java
code generator.
<br>
<br>
A null EPackage.nsURI is similarly bad and reasonable.
<br>
<br>
It would be nice if genModel could automatically provide defaults for
everything that
<br>
is missing from a model only file.
<br>
- offer java.lang elements for EDataTypes
<br>
- offer default URIs
<br>
rather than barf.
<br>
<br>
Incorrect containment is one of my regular problems. Using the Ecore
editor, it is very
<br>
hard to check that relationships are correct. It is only when a
UML-like presentation is
<br>
used that stipidities are self evident. I suspect that there are some
useful diagnostics
<br>
that a nanny-mode might support - for instance, perhaps no model
element other than the
<br>
root should lack a potential container.
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------000703020008020207090602--
|
|
|
Goto Forum:
Current Time: Sat May 17 18:27:21 EDT 2025
Powered by FUDForum. Page generated in 0.04423 seconds |
Home