Hello, I think the RBContainer has not seen to much use until now. In general, Ring was a bit too designed for flexibility that I guess was good in the past, but not needed now. E.g. it used to create every Ring entity via a factory. I started to simplify it a lot in Pharo5. This removed lots of code and even made things faster. With the âRemote Developmentâ project starting soon, we will do another pass over Ring, I think. We need to especially unify the âEnvironmentâ concepts of RB, the system and Ring. Marcus
On 02 Nov 2015, at 10:14, Thierry Goubier <thierry.goubier@gmail.com> wrote:
I'm trying to look into Ring implementation.
So I have a first question. Why is RGAbstractContainer and subclasses irregular? Is that on purpose?
Details: RGAbstractContainer delegates adding a new element to the element being added, via aRGElement>>#addInContainer:. This element is then expected to use RGContainer>>#addTrait:/#addPackage:/#addMethod: etc... However only a subset of the RGElements implement #addInContainer:; for example, RGTrait does not implement #addInContainer: (*).
(*) Ok, RGContainer>>#addTrait: calls RGContainer>>#addClass:, and RGTrait being a subclass of RGBehaviorDefinition, that works. But I'm still ??
Thierry