Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » ToStringVisitorImpl.toString returning null
ToStringVisitorImpl.toString returning null [message #34554] Fri, 19 May 2006 18:26 Go to next message
Eclipse UserFriend
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 14:23 Go to previous messageGo to next message
Eclipse UserFriend
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 #34861 is a reply to message #34689] Wed, 24 May 2006 17:48 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7658
Registered: July 2009
Senior Member
Christian W. Damus wrote:
> 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

Perhaps 125079 should be re-opened.

ToStringVisitor is just not fit for purpose as a debugging tool.

I created a RobustToStringVisitor to which I add more and more NPE fixes.

ToStringVisitor needs a major revision to assume that most things/anything
could be null.

Regards

Ed Willink
Re: ToStringVisitorImpl.toString returning null [message #34939 is a reply to message #34861] Thu, 25 May 2006 03:12 Go to previous messageGo to next message
Eclipse UserFriend
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 #35293 is a reply to message #34939] Fri, 26 May 2006 05:16 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7658
Registered: July 2009
Senior Member
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 #35360 is a reply to message #35293] Fri, 26 May 2006 11:30 Go to previous messageGo to next message
Eclipse UserFriend
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 #35393 is a reply to message #35360] Fri, 26 May 2006 11:54 Go to previous messageGo to next message
Eclipse UserFriend
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 08:27 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7658
Registered: July 2009
Senior Member
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 12:13 Go to previous message
Eclipse UserFriend
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>
&nbsp;&nbsp;&nbsp;&nbsp;- offer java.lang elements for EDataTypes
<br>
&nbsp;&nbsp;&nbsp;&nbsp;- 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 14:23 Go to previous message
Eclipse UserFriend
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 #578487 is a reply to message #34689] Wed, 24 May 2006 17:48 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7658
Registered: July 2009
Senior Member
Christian W. Damus wrote:
> 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

Perhaps 125079 should be re-opened.

ToStringVisitor is just not fit for purpose as a debugging tool.

I created a RobustToStringVisitor to which I add more and more NPE fixes.

ToStringVisitor needs a major revision to assume that most things/anything
could be null.

Regards

Ed Willink
Re: ToStringVisitorImpl.toString returning null [message #578544 is a reply to message #34861] Thu, 25 May 2006 03:12 Go to previous message
Eclipse UserFriend
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 05:16 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7658
Registered: July 2009
Senior Member
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 11:30 Go to previous message
Eclipse UserFriend
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 11:54 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33148
Registered: July 2009
Senior Member
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--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: ToStringVisitorImpl.toString returning null [message #579502 is a reply to message #35360] Sun, 04 June 2006 08:27 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7658
Registered: July 2009
Senior Member
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 12:13 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33148
Registered: July 2009
Senior Member
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>
&nbsp;&nbsp;&nbsp;&nbsp;- offer java.lang elements for EDataTypes
<br>
&nbsp;&nbsp;&nbsp;&nbsp;- 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--


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:QUERY for Eclipse 3.1.2
Next Topic:Grouping objects under a folder
Goto Forum:
  


Current Time: Sun May 19 05:28:07 GMT 2024

Powered by FUDForum. Page generated in 0.05791 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top