Community
Participate
Working Groups
Seeing "Anonymous Context" everywhere isn't helping anyone. I'll make some tweaks in the renderer.
Fixed in CVS HEAD.
Do you think it will make sense to remove EclipseContextFactory#create() and leave only EclipseContextFactory#create(String name) ?
(In reply to comment #2) > Do you think it will make sense to remove EclipseContextFactory#create() and > leave only EclipseContextFactory#create(String name) ? But then we can't be lazy in our tests. ;) In all honesty, I think it should be canned.
Sigh. See bug 264899. We originally required a name when creating contexts, but in an effort to make it easier to use, I removed it and instead introduced a context value (IContextConstants.DEBUG_STRING). This made the name optional for those who didn't really need it, but more importantly it allowed the debug string to contain information that was computed from other information in the context (by storing a function instead of a field in that property). You don't always know a good name for a context at the time you create it, but there might be a particular property in the context that helps to identify it. I.e., imagine Object.toString() was a field instead of a method, and you had to supply it at the moment the object was constructed. It would be much less useful as a debugging tool. But, I see now that in bug 292766 Oleg removed this concept and reintroduced a static name at creation time (also in an attempt to make contexts easier to use ;) Oleg, do you think having a toString function isn't useful or you just found that we weren't making much use of it?
(In reply to comment #4) > But, I see now that in bug 292766 Oleg removed this concept and reintroduced a > static name at creation time (also in an attempt to make contexts easier to use > ;) Oleg, do you think having a toString function isn't useful or you just found > that we weren't making much use of it? The implementation did not change in the bug 292766; we still use DEBUG_STRING variable to store the name. The OSGi context still provides the override. What changed is that we don't expose it as an API anymore as it was not used by the rest of e4. Should our comrades demand this functionality, we can always make it an API.
