On Mar 8, 2013, at 11:50 PM, Ciprian Teodorov <ciprian.teodo...@gmail.com>
wrote:
>
>
> On Fri, Mar 8, 2013 at 10:32 PM, stephane ducasse <stephane.duca...@free.fr>
> wrote:
>
> On Mar 8, 2013, at 7:57 PM, Ciprian Teodorov <ciprian.teodo...@gmail.com>
> wrote:
>
>> Hi guys,
>>
>> Can anyone give me some pointers on how to create traits dynamically?
>
> you mean with the refactoring engine?
> Yes something like it, I am little confused with all ring, rb stuff.
ring is simple: imagine that all the tools can manipulate objects that
represent objects that get executed.
for RB you have an engine to transform code.
Now to programmatically create traits you do not need RB nor ring
> But I know that I can build classes, add methods, and see changes (and apply
> them) using RBNamespace api... it does not seem to work with traits. Some
> time ago I have spend some time patching the RB thingy to accept trait
> also... but then I have run into other problems (i don't remember exactly
> what)... Moreover, it was just hacks to make it work... so I've lost them
> over time... and I don't like patching every new image that I download with
> my changes to make It work...
>
> So maybe, I don't use them right... or there are things that should be
> done... I'm willing to contribute, if it helps.
looking a the enhancements proposed to make rb handle traits would be good
>
> I know that one argentinian student added support for traits in RB but I
> never got the time to have a look and integrate it.
> cool, maybe we should have a look...
>
> Then again, it is not clear in my head what is the politics of traits and
> pharo... I know that there were some discussions about them being bad because
> their methods are copied to classes, not being well integrated….
it was just for implementors.
> how exactly do they fit in the big picture (next pharo versions). Can we use
> them as they are now, or the implementation is likely to change in the near
> future? -- stateful traits, or something else?
No stateful traits in the horizon.
For now traits will stay but we should have a look at the internal
implementation to simplify it.
Second the internal change should not impact external users and will be
transparent.
>
> cheers,
> ciprian
>
>
>> I have tried something like:
>>
>> model := RBNamespace new.
>>
>> model defineClass: ('Trait named: #TMyTrait
>> uses: {}
>> category: ''My-Tests''').
>>
>> and I get a DNU: RBAddTraitChange>>superclassName
>>
>> Cheers,
>> --
>> Dr. Ciprian TEODOROV
>> Ingénieur Développement CAO
>>
>> tél : 06 08 54 73 48
>> mail : ciprian.teodo...@gmail.com
>> www.teodorov.ro
>
>
>
>
> --
> Dr. Ciprian TEODOROV
> Ingénieur Développement CAO
>
> tél : 06 08 54 73 48
> mail : ciprian.teodo...@gmail.com
> www.teodorov.ro
