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 <
[hidden email]> 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
Locked
