Hi,
I'm playing with Slots and MethodWrappers to customize instVar reading/writing and method calls. In my experiments, Slots and MethodWrappers hold meta-description objects used at runtime to apply some filters, validations and to compose or delegate methods behavior. I'm really interested in the progress of MetaLink, I saw that it will be possible to use hooks like #instead or #arround. Are these hooks can replace the use of MethodWappers ? Will it be possible to call a MetaObject's method instead of a method's body and with the passed arguments ? The announcement of meta-levels gives me ideas, would not it be interesting to have something like meta-layers? For instance, in order to address a layer with no MetaObjects execution, a layer with MetaObjects for logging or breakpoints, an other layer with custom MetaObjects, etc. I don't see how it would be possible to limit the scope of the active layers configuration, just for a block evaluation for exemple... From RFMetaContext maybe, but how ?... It is just an idea on the fly, Maybe it's already possible to do something like that or it would be just useless in practice. Thanks a lot Marcus for your work on Slot and MetaLink. Best regards, Glenn.
Glenn Cavarlé
|
> On 29 Apr 2015, at 22:59, Glenn Cavarlé <[hidden email]> wrote: > > Hi, > > I'm playing with Slots and MethodWrappers to customize instVar > reading/writing and method calls. > In my experiments, Slots and MethodWrappers hold meta-description objects > used at runtime to apply some filters, validations and to compose or > delegate methods behavior. > > I'm really interested in the progress of MetaLink, I saw that it will be > possible to use hooks like #instead or #arround. > Are these hooks can replace the use of MethodWappers ? Yes! > Will it be possible to call a MetaObject's method instead of a method's body > and with the passed arguments ? > Yes, this will work very soon… in a simple version (only one replace link allowed). (Later this will be generalized AOP style as an #around with the possibility to “proceed” to the replaced node). What I am porting now from the prototypes is the functionality to hand arguments over to meta objects. before links on methods are already working: link := MetaLink new metaObject: [ self halt ]. (ReflectivityExamples>>#exampleMethod) ast link: link. execute it: ReflectivityExamples new exampleMethod. (ReflectivityExamples>>#exampleMethod) symbolic "'21 <20> pushConstant: [ self halt ] 22 <C9> send: value 23 <77> pushConstant: 2 24 <21> pushConstant: 3 25 <B0> send: + 26 <7C> returnTop’" (This example, too, shows that a block can be a meta object, this means that this can be used as a very easy to use instrumentation framework, too, without the need to create explicit classes and methods for meta objects). > The announcement of meta-levels gives me ideas, would not it be interesting > to have something like meta-layers? Yes! > For instance, in order to address a layer with no MetaObjects execution, a > layer with MetaObjects for logging or breakpoints, an other layer with > custom MetaObjects, etc. > I don't see how it would be possible to limit the scope of the active layers > configuration, just for a block evaluation for exemple... From RFMetaContext > maybe, but how ?… One thing I want to add is to make the condition (optionally) into an object and then allow reflectivitly to turn on/of links without having to actually change the #condition: itself. Then links themselves could target these control meta objects… It is definitly interesting. E.g. one might want to have break points active, yet run the tests with them disabled. Marcus |
> What I am porting now from the prototypes is the functionality to hand arguments
> over to meta objects. Cool, i'm very interested in your implementation for that ! > One thing I want to add is to make the condition (optionally) into an object > and then allow reflectivitly to turn on/of links That would be really great :) Thanks for your answer Marcus. Regards, Glenn.
Glenn Cavarlé
|
> On 30 Apr 2015, at 10:29, Glenn Cavarlé <[hidden email]> wrote: > >> What I am porting now from the prototypes is the functionality to hand > arguments >> over to meta objects. > > Cool, i'm very interested in your implementation for that ! > I hope to have it done next week.. but first my focus is on breakpoints. Marcus |
In reply to this post by Marcus Denker-4
>
>> For instance, in order to address a layer with no MetaObjects execution, a >> layer with MetaObjects for logging or breakpoints, an other layer with >> custom MetaObjects, etc. >> I don't see how it would be possible to limit the scope of the active layers >> configuration, just for a block evaluation for exemple... From RFMetaContext >> maybe, but how ?… > > One thing I want to add is to make the condition (optionally) into an object > and then allow reflectivitly to turn on/of links without having to actually change > the #condition: itself. > This is now in Pharo5… links can be turned on/off reflectively by using #enable and #disable. I works by wrapping the original condition into a RFCondition object. #disable puts just “false” as the outer condition, but one could put there more complex conditions, too Marcus |
Free forum by Nabble | Edit this page |