Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[encompass.r]

 [1/7] from: maximo:meteorstudios at: 26-Nov-2003 12:34


Hi all, I just wanted to let everyone know of a nifty function I just uploaded to the rebol.r repository, it is called emcompass. I wanted to share it here, but its too large and will wordwrap pretty badly... http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=encompass.r There are a lot of comments in the code (per my usual coding style) It lets you add code around a function and wraps all refinements to it. It is a follow up to the question I asked a week ago about transfering all refinements to another function of the same/lesser template. 'ENCOMPASS can be used to modify behaviour of code, without actually tampering with the code itself. It is especially usefull in patching native! funcs. simply put you can: -extend the argument list by adding new parameters or refinements, -add pre-process code, executed before the function you are enclosing. -add pos-tprocess code, executed after the function you are enclosing. -the return value (if any) of the enclosed function can be created/modified in the post-process, which is in turn returned by the encompassing function. the example within the rebol.org encompass.r script show how you can add a confirm on every 'read done, in the case where you want to monitor and intercept what a script is about to read, just before it does. Canceling the read, terminates the script. the example even adds a refinement to read /safe which prevent any confirmation when you know the file is safe. the patch replaces the global read statement, so calling this at the begining of your code actually protects you from someone prying files on your disk and sending them over the net without your knowledge. good thing is that if the template to read changes in the future, you have nothing to edit, it just continues using the new template, because you do not have to tamper with it yourself. The example itself is simple, but it shows just how easy it is to extend/restrict functionality of any function, method, action or native. hope some of you find it usefull, I know I really am! ciao! -MAx PS: if some of you noticed it yesterday, I have severely updated it last night, its worth getting the newer version (1.0.2) ------------- Steel project coordinator http://www.rebol.it/~steel

 [2/7] from: antonr:iinet:au at: 27-Nov-2003 22:46


How about encompass stores the old function name and function definition in a list maintained within itself, so you can /restore later. Just an idea. Anton.

 [3/7] from: maximo:meteorstudios at: 27-Nov-2003 10:39


very good idea! but this would only work for global words. I often use the encompass return function in an object, in order to overide the default function only within the context of an object. thats basically what namespaces (contexts, objects) are for. Anyone... What is the best way for a function to detect if it is part of an object? -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [4/7] from: SunandaDH:aol at: 27-Nov-2003 11:33


Max:
> Anyone... What is the best way for a function to detect if it is part of an > object?
One way would be to check if 'self is defined. Sunanda.

 [5/7] from: maximo:meteorstudios at: 27-Nov-2003 12:30


> -----Original Message----- > From: [SunandaDH--aol--com] [mailto:[SunandaDH--aol--com]]
<<quoted lines omitted: 6>>
> > object? > One way would be to check if 'self is defined.
I though of that, but it is very possible that someone will use self in the global context. even checking if its type is object! isn't completely safe... isn't there a way to probe the current context, one which works whether we are in an object or the global namespace ? I might add a /bind refinement which forces a bind of the created function block to an object. When used, It would implicitly make /revert function differently than when defined 'globally'. As I don't need this functionality right now, I'll put it on the back burner, but if any one DOES need it, I'll raise the priority. I'm pushing slim as the only code I write on right now... so everything else is secondary. I want to start working on STEEL|FORGE SOOOOOO badly. I might start working on a Q&D forge prototype (a closed rebol-coding exclusive toolset with no api) to bootstrap the real application and improve liquid-vid coding speed. cheers! -MAx ------------- Steel project coordinator http://www.rebol.it/~steel

 [6/7] from: antonr:iinet:au at: 28-Nov-2003 14:11


There is no notion of current context. The same function can be referenced by words in two different objects, can't it? Therefore, which context is "current"? It's probably infeasible to add a complete undo function, but perhaps an /original refinement might be good so you don't have to remember the original function. It doesn't buy you much, though. Anton.

 [7/7] from: maximo::meteorstudios::com at: 28-Nov-2003 11:09


> > There is no notion of current context. > The same function can be referenced by words > in two different objects, can't it? > Therefore, which context is "current"?
yeah you're right, I'd forgotten that once bind is done, the function itself does not have any knowledge of context... each word stores its context by itself... funny I forgot, since I gave a demo on this list of how you can have a block with the same three words in it with each one containing differrent information... its amazing how one has to bang his head until you figure just how powerfull this really is. probe reduce [w w w] in rebol, can be made to print: something "something else" "yet another value" something which isn't possible in most other languages without inserting the reduced value in the block.
> It's probably infeasible to add a complete > undo function, but perhaps an /original > refinement
in theory, I already have the original function. a /context refinement might be good to, where you replace the default /system/words/ "context" by any path! value of your choosing. but, since the encompass returns the new function... the old one is not overidden until/unless YOU decide. IT does not overide the function it merely uses it. That is why in the example I backup read to old-read. So if I ever wanted to reset read back by default, I'd just need to do: read: :old-read so maybe this whole restore/revert thing really isn't usefull, for all the problems it would create (and asumptions it would need). like I said in one of my recent mails... Often, simple is longest to achieve. we can go round and round and eventually, realize that all the nice ideas aren't as simple as if they didn't even exist. ;-) -MAx

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted