Invalid object "toString" readability

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 290228 | | Status | CLOSED DUPLICATE of bug 152207 | | Importance | P3 enhancement | | Reported | Sep 23, 2009 05:22 EDT | | Modified | Sep 25, 2009 15:44 EDT | | Version | 1.3.0 | | Depends on | 152207 | | Reporter | Laurent Goubet |

Description

Created attachment 147871\ addition of a toString() implementation for the invalid instance

The invalid instance is currently displayed as a String under the form\ "org.eclipse.emf.ecore.impl.DynamicEObjectImpl@1c8f59c (eClass:\ org.eclipse.emf.ecore.impl.EClassImpl@74f160 (name: Invalid_Class)\ (instanceClassName: null) (abstract: false, interface: false))".

This makes reading error messages, unit test failures, or anywhere where user\ feedback is needed for the invalid instance really painful.

The "null" instance is nicely printed out as "null" as it is simply reflected\ internaly as java's null.

We should provide a pretty printer that displays "invalid" instead of the\ lengthy dynamic EObject's toString implementation for the invalid Object. The\ attached patch aims at doing so by providing an EFactoryInstance to the\ standard library package (for ecore). This seems like overkill, but as long as\ the standard library's code isn't generated, the only other way I can think of\ is to change the invalid instance creation from\ "stdlibPackage.getEFactoryInstance().create(..)" to "new\ DynamicEObjectImpl(...)" which seems a lot more error-prone.

I couldn't find a way to do the same for the UML implementation of the standard\ library. Any idea?

:notepad_spiral: StandardLibraryInvalid.patch

[eclipse-ocl-bot]

By Ed Willink on Sep 23, 2009 15:52

Ow! Bug 290315, OCL's null should be printed the same way as invalid since OCL's null should be the singleton instance of OclVoid.

Bug 152207 anticipates OCL 2.1's toString().

In 152207, I suggest a toValidString (Java) helper function.

I suggest implementing 152207 to fix this. This will then work for UML too.

[eclipse-ocl-bot]

By Laurent Goubet on Sep 24, 2009 03:58

Didn't see bug 152207; this would indeed be way better than my attempt in the attached patch. I implemented a toString() method on OclAny for Acceleo, I'll look into ripping this code from Acceleo to insert it in OCL instead.

Do we want a toString() defined for each distinct type (Integer, Real, String, Boolean, Collection, Sequence, ...) or defining it on OclAny will suffice (that's the approach I used in Acceleo)?

[eclipse-ocl-bot]

By Ed Willink on Sep 24, 2009 04:46

Either approach could work for now.

In bug 259031 I observed that EvaluationVisitorImpl.visitOperationCallExp is\ impossibly large.

It appears to refactor best as a partition by irregular method name then partition by method type. Ideally all method names would be regular and just looked up in the operation lists of their types. This should certainly be true where I may wish to provide MyType::toString.

I'm inclined to recommend doing whatever is necessary to simplify visitOperationalCallExp and ensure that it correctly invokes whatever versions of toString() it can find.

[eclipse-ocl-bot]

By Ed Willink on Sep 25, 2009 15:44

This bug has been marked as a duplicate of bug 152207