Option 1 would only work if SDO implementation never needs to expose any
internal EMF properties. I am not sure whether there is a possibility that we
need to map the internal EMF properties to something so the SDO users can
control some EMF like behavior.
What kind of internal EMF properties are we talking about here? Can you
share them? Thanks.
Best regards,
Fuhwei Lwo
Yang ZHONG <[EMAIL PROTECTED]> wrote: Current SDO impl bases on EMF, EMF may
produce INTERNAL Properties besides
user designation.
It may be nice for SDO not to expose the INTERNAL Properties.
Here lists some thoughts JUST as a START, it's much more important if YOU
brainstorm please.
Frank has provided options such as
1. SDOXSDEcoreBuilder builds user Properties at the beginning of
getEStructuralFeatures() List and INTERNAL properties at the end of
getEStructuralFeatures().
SDO can simply hide high-index INTERNAL Properties without too much
performance sacrifice.
2. SDO maintains a seperated List from getEStructuralFeatures()
I agree with either of the two options and feel like it may be another
option to extend getEAllStructuralFeatures() to change the property List in
effect.
Really hope to see your comment on any of the options even more options from
you.
No matter what option, an interesting thing to consider is the order of
INTERNAL Properties from SUPER typeS and user Properties from subtype.
Really hope to see good solution to that concern so that List decoration
(index translation) can be evitable.
Thanks in advance.
--
Yang ZHONG
