Home » Modeling » EMF » Debug Variables view and EObject Logical Structure
| |
Re: Debug Variables view and EObject Logical Structure [message #644287 is a reply to message #644163] |
Fri, 10 December 2010 12:07 |
Hallvard Traetteberg Messages: 673 Registered: July 2009 Location: Trondheim, Norway |
Senior Member |
|
|
On 09.12.10 18.30, Ed Merks wrote:
>>
> Yes, I know that IBM did such a thing internally.
>> I have tried myself, but haven't been able to create a working
>> snippet. The following gives the error that the package
>> org.eclipse.emf.js4emf cannot be found:
>>
> What's giving that error. Are you missing a dependency in the
> MANIFEST.MF for this? Do you really need a special implementation of the
> map entry? I.e., why not just use a linked hash map?
I also thought the problem was a missing dependency, but the package is
exported and in the same plugin as the extension point. The strange
thing is that the MapEntryImpl is in org.eclipse.emf.js4emf.ui, not
org.eclipse.emf.js4emf. I don't know exactly in what context the code
snippet is evaluated in, so it's difficult to interpret to message.
The snippet should return the logical contents of the EObject, so I
though it needed to return an array of entries, rather than a Map. But
you're right, it works with a map, as follows:
org.eclipse.emf.common.util.ELis<org.eclipse.emf.ecore.EStructuralFeature >
features = this.eClass().getEAllStructuralFeatures();
java.util.Map map = new java.util.HashMap();
for (int i = 0; i < features.size(); i++) {
org.eclipse.emf.ecore.EStructuralFeature feature = features.get(i);
map.put(feature.getName(), this.eGet(feature));
}
return map;
You get the look & feel of an array of key/value pairs, though, not a
list of fields like in the native case.
I guess registering this snippet for
org.eclipse.emf.ecore.impl.DynamicEObjectImpl is best, although it may
also be used for subclasses with dynamic features.
Hallvard
|
|
|
Re: Debug Variables view and EObject Logical Structure [message #644301 is a reply to message #644287] |
Fri, 10 December 2010 13:09 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
Hallvard Trætteberg wrote:
> On 09.12.10 18.30, Ed Merks wrote:
>>>
>> Yes, I know that IBM did such a thing internally.
>>> I have tried myself, but haven't been able to create a working
>>> snippet. The following gives the error that the package
>>> org.eclipse.emf.js4emf cannot be found:
>>>
>> What's giving that error. Are you missing a dependency in the
>> MANIFEST.MF for this? Do you really need a special implementation of the
>> map entry? I.e., why not just use a linked hash map?
>
> I also thought the problem was a missing dependency, but the package
> is exported and in the same plugin as the extension point. The strange
> thing is that the MapEntryImpl is in org.eclipse.emf.js4emf.ui, not
> org.eclipse.emf.js4emf. I don't know exactly in what context the code
> snippet is evaluated in, so it's difficult to interpret to message.
You can't run it under debug control to set breakpoints?
>
> The snippet should return the logical contents of the EObject, so I
> though it needed to return an array of entries, rather than a Map. But
> you're right, it works with a map, as follows:
>
> org.eclipse.emf.common.util.ELis<org.eclipse.emf.ecore.EStructuralFeature >
> features = this.eClass().getEAllStructuralFeatures();
> java.util.Map map = new java.util.HashMap();
> for (int i = 0; i < features.size(); i++) {
> org.eclipse.emf.ecore.EStructuralFeature feature = features.get(i);
> map.put(feature.getName(), this.eGet(feature));
> }
> return map;
A LinkedHashMap is likely to give you a more predictable/determinstic
feature order.
>
> You get the look & feel of an array of key/value pairs, though, not a
> list of fields like in the native case.
Yes, it's nice to hide lots of the implementation details. One might
test for things like being a proxy and show things like the eContainer
or eDirectResource; stuff that's lurking in the properties holder or the
array of slots in MinimalEObjectImpl...
>
> I guess registering this snippet for
> org.eclipse.emf.ecore.impl.DynamicEObjectImpl is best, although it may
> also be used for subclasses with dynamic features.
Not sure how the registration works (you can't register it against an
interface like InternalEObject?) but it's expected that all
implementations of EObject ultimately extend BasicEObjectImpl.
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Sun Apr 28 03:00:41 GMT 2024
Powered by FUDForum. Page generated in 0.03794 seconds
|