Actually the bag concept is general to computer science, and at least used to be covered in computer science courses back in my day. You can put things in the bag, but when you pull something out of the bag you don't know what you're going to get out in what order.
Of course bags didn't get a lot of air time, because lists, sets, stacks,
and queues were all sexier.
You wizened old Smalltalk dudes don't get to claim ownership over
everything ya know ;-)
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
John
Arthorne/Ottawa/I
b...@ibmca To
Sent by: E4 Project developer mailing list
e4-dev-boun...@ec <[email protected]>
lipse.org cc
Subject
01/08/2009 09:58 Re: [e4-dev] A missing framework
AM piece: contexts?
Please respond to
E4 Project
developer mailing
list
<[email protected]
rg>
"Bag" is just a Smalltalk term for an unordered collection. Essentially a
context is just a map, with extra logic for tracking dynamic changes,
injection, and a notion of a parent context. If the most local context
can't supply a value, it delegates to the parent. As Kevin suggested this
allows modeling of things like the widget hierarchy where a tab in a view
might be one context, the view itself another context, another context for
the window, etc, up to a global application context. You're right that the
injection logic can (and probably should) be separated from the context
logic since it's unlikely to change.
Ed Merks <[email protected]>
Sent by:
[email protected] To
E4 Project developer
mailing list
01/07/2009 04:41 PM <[email protected]>
cc
Please respond to Subject
E4 Project developer mailing list Re: [e4-dev] A missing
<[email protected]> framework piece:
contexts?
Oleg,
Comments below.
Oleg Besedin wrote:
?Progress is made by lazy men looking for easier ways to do things?.
I'm exceedingly lazy...
I think this is exactly how the concept of contexts came to life. Our code
runs in some environment; way too often we need to pass tens of arguments
from method to method and from class to class just to keep them aware of
the environment.
To make it easier we are considering adding a concept of "context". At the
conceptual level a "context" is a combination of:
- a bag that could be stuffed with elements that compose environment, and
Couldn't we just use Map<String, Object>? What's the significance of the
term "bag"?
- a mechanism to inject elements from the bag into your POJO objects
Such a mechanism could be independent of how the "bag" itself is
implemented.
The contexts are organized in a hierarchy. Child context can add service
objects that make sense at their level:
IEquinoxContext myContext = ApplicationContext.newChild();
Will we expect people to create context with specialized behavior? Which
parts will be specialized and why?
myContext.addObject("log", myLog);
The service objects from the context can be injected into POJO objects
using field and method injection:
myContext.injectInto(object)
resulting in the field object.equinoxLog being set to "myLog".
I could imagine a static Injector.inject(Map<String, Object> values, Object
target) utility doing all this type of work with no additional interfaces
or implementations of those interfaces. Of course then there's be only one
implementation of this, which conceptually seems less flexible, but that's
the question earlier. What parts of which mechanisms would clients be
trying to specialize?
Contexts support dynamic events and multiple service objects per ID.
What are those? :-P
In addition, contexts can be tied into creation of objects from the
extension registry and help access OSGi services.
I think I'm missing a lot of the picture even looking in the bugzilla. It
sounds interesting though...
I'd like to raise this subject at the E4 call to see what people think
about it. The details of this work can be found in the enhancement request
259423:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=259423
Sincerely,
Oleg Besedin
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
<<inline: graycol.gif>>
<<inline: pic08464.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
