World: r3wp

but making a shortcut or menu-entry instead, is that to difficult?

Then encap?

I will simply accept the rule that I should not develop outside my 
sandbox, or it gets denerving :-)

Or the cruel trick: put script in c:\ . then everything is in a subfolder. 
except of the 25 other letters.

I personally like the requesters. Its so easy to accidentally click. 
Then i can say "No dont delete this!"

(click and launch one of these half-baked test-script i mean)

For that total commander: is a bat to terrible?

ah, bat could be a solution, yes, thanks ...

Jaime: I checked your code above: first I thought it's not possible, 
then I thought wow, but I got one thing left that doesn't work:

You're using the 'class word to bind the code of the functions of 
an object later to the right object - this doesn't work, because 
'class is always bound to the function context and thus has the last 
object referenced - in your example no problem, because the code 
is the same - but with different code doesn't work anymore - maybe 
with one of the closures it would work - because 'class gets always 
bound to a new context (but I'm not sure yet whether I understand 
it right)

CounterClass2: context [
	d: 0
	bump2: does [d: d + 1]
	read2: does [d]
	bump-by2: func [inc][d: d + inc]
]

ctr1: make-instance CounterClass
ctr2: make-instance CounterClass2

ctr1/bump ctr1/bump ctr1/read
ctr2/bump2 ctr2/read2


fails, because at ctr1/bump, class is bound to object CounterClass2 
which has only bump2


so if this gets sorted out - it seams to be really difficult to access 
the hidden contexts (or impossible, because after invoking the function 
the contexts are gone)

Humm. This is strange. Let me check it here.

Solved. See below.

make-instance: func [
	class [object!]
	/local class-vars instance-data class-methods v
][
	class-vars: copy [*-private-*]
	class-methods: copy []
	instance-data: copy []
	foreach w next first class [
		either function! = type? v: get in class :w [
			append class-methods compose/deep [
				(to set-word! :w) func [(first :v)] [
					bind second get in (:class) (to lit-word! :w) '*-private-*
					do reduce [get in (:class) (to lit-word! :w) (first :v)]
				]
			]
		][	
			append class-vars :w
			append instance-data reduce [to set-word! :w :v]
		]
	]
	use class-vars compose/deep  [
		(instance-data)
		context [(class-methods)]
	]
]

The beaty of this is that you are able to change a class method, 
changing the behaviour of all instances at the same time.

While the private state vars are kept private, and current.

yes - that's good now. I just have to try to access the object in 
malicous ways - if it's not possible then this is the first time 
I see (doesn't have to mean anything of course) completely hidden 
data of an object.

So we could make some rules how to make data completely invisible:

a) all words to be used later have to be used indirect via words 
in the function (like the traversing of the objects words via [foreach 
w next first 'object ... ]

b) if that's not possible the words used in the function (if they 
expose any context) have to be cleaned by a use which doesn't return 
the context


b) is actually the really smart thing to me - the 'use and the returning 
of the new context in 'use - so one can't catch the 'use context 
and get the words with the usual means

Howver there is a way to access the private ctx. It is leave as an 
exercise to the reader.

If you have access to a function-body you can get the values of all 
words. Still it is a lot obfuscated.

Oops. Saw your last posting was to late, sorry.

I actually there is a way to improve this which will make it 100% 
secure, but it will lose a different property.

Ok, me as the reader is searching then, at least it's not too obvious 
or I'm too blind today. :-)

;-)

ctr1/read
== 2
>> ctr1/bump
== 3
bl: [c]
== [c]
>> f: get in ctr1 'read
>> o: third tenth second :f
>> bind bl first second get in o 'read
== [c]
>> set first bl 12
== 12
>> ctr1/read
== 12

:-)


But how you want to prevent this ? I mean what property you talked 
about would get lost ?

Good job. The property lost will be the ability  to change a class 
method and propagating the new behaviour to all instances at the 
same time.

Just saw - a little bit easier would have been to do it with *-private-*.

Now you got it completely. That is the backdoor.

I have access to global context, can patch functions there (which 
you use - or?) and traverse everything. Hmm, could clone all meazines 
and never return. then the only reference is from the stack, which 
is not traversable.

behavior change: you mean by copying the code and hiding it in a 
'use ?

or something like that ?

Yes.

That's my problem with Rebol, on the one side I hate this vulnerability, 
on the other side it's so nice to be able to bind around like wished.

Well ObjC allows you to bind to anything and instrospect anything. 
So I think is all is good.

Here is the safe version:

CounterClass: context [
	c: 0
	bump: does [c: c + 1]
	read: does [c]
	bump-by: func [inc][c: c + inc]
]

make-instance: func [
	class
	/local class-vars instance-data class-methods v
][
	class-vars: copy [*-private-*]
	class-methods: copy []
	instance-data: copy []
	foreach w next first class [
		either function! = type? v: get in class :w [
			append class-methods compose/deep [
				(to set-word! :w) func [(third :v)] [

     (bind copy second get in class (to lit-word! :w) '*-private-*)
				]
			]
		][	
			append class-vars :w
			append instance-data reduce [to set-word! :w :v]
		]
	]
	use class-vars compose/deep  [
		(instance-data)
		context [(class-methods)]
	]
]

ctr1: make-instance CounterClass
ctr2: make-instance CounterClass

ctr1/bump ctr1/bump ctr1/read
ctr2/bump ctr2/read

I didn't know this - thought always only a highly dynamic language 
would allow this - but never watched ObjC - thought it's also kind 
of C++ - just that they went into a different direction at some point, 
more pure OO.

The object-part is quite smalltalk afaik. Only they skip the bytecode-interpreter 
and "inline" the calls to c.

Correct.

unfortunately easier: :-(  so my thoughts seamed to be wrong as well

f: get in ctr1 'read
>> ctr1/read
== 2
>> set first second :f 12
== 12
>> ctr1/read
== 12

If the interpreter can find a way from the console to the access, 
a selfmade "interpreter" can find it too.

I think the problem is simply that one can't really prevent the use 
of the words in the code of the functions in the object.

Jep.

MichaelB. I thought I have done it. Ok. It was a good try. I like 
the first version though. I enables for some neat stuff. Even when 
having some holes.

Volker: actually you explanation sounds almost like a proof to forget 
it completely. Too simple - but Rebol is all about words getting 
interpreted.

I think that is no big problem. If you give code-control, you are 
doomed anyway. Hmm, could be used to have a password to login and 
destroy it reliable.

The secure way is to launch an external process to run user-code 
IMHO. Add 'secure unset 'struct! and hope there are no overflowes. 
Should be pretty save.

Jaime: I saved you code - it's nice nevertheless. :-)

Not completely - the code still needs access to the global context. 
if you bind every word in an own context and put selected functions 
there, it would work. Still tricky, for example 'second can not be 
exposed, else you get the functions body. I may forget other issues.

BTW would be nice if secure would support ulimit-calls.

That's one of my problems if I would like to have capability security 
in Rebol - all these omnipotent (is this the right word?) words, 
shouldn't be allowed - eg. only if my code gives out the right to 
introspect itself something like 'second should be calleable.

what does that mean ? the secure thing ?

something like
 secure [file quit %./public allow memory 2000 timeout 2]