World: r3wp

With selfless contexts it wouldn't work. In certain circumstances 
this can be useful.

but if SELFLESS simply ignored the self word, then self would be 
bound to object SELFLESS was called in... which is very nice to allow 
loops which can access contexts.

that does not look right to me at all

Loops in OO code can be helpful :)

aha, maybe I misunderstood again

Ladislav, you are right.
>> a: context [a: 1]  same? a first do bind [self] a
== true

Dammit.
>> a: context [a: 1]  same? a do bind [self] a
== true

Q: would SELFLESS rebind values given with /set  ?

that is what I would expect, but its not defined in your ticket.

though maybe its better if it didn't.

No, it wouldn't rebind the values. For that matter it doesn't bind 
the original words.

It just uses SET semantics for the values.

I am thinking that SELFLESS could be used to build classes if we 
specified self as a word.

since self could be set to another context... it would be interesting 
since 

a  and  self/a  would effectively be different values  :-)

Yup, though that is likely not as good an idea as other words other 
than self. Regular object self binding is really helpful for OOP, 
even class-based OOP.

and since we have full control over the self word, because we are 
supplying/setting it then our class builder could properly bind the 
class methods to our instance selfless context.

idea here is just that self is the accepted rebol term for object 
member setup.

the selfless object would be class and its self would point to the 
instance... something which is impossible with selfish contexts.

hum... nope, it would have to be the other way round.  otherwise 
you can't safely have more than one instance per class.

Yup :)

anyhow... I think that SELFLESS is an enabler.  they allow us to 
evolve the language in specific domains while keeping the standard 
terms in our code.

Added this to the SELFLESS ticket: "The values would not be bound 
to the context."

Because that would be presumptuous and usually wrong :)

yes, like aggressive block evaluation  :-)

remember that mistake?  ;-)

Not really, but that sounds like a bad one. Got to go now, later! 
:)

I'm realizing that I coudn't really implement what I want.  because 
the selfless? AFAIK isn't a state flag, its the actuall fact of having 
self inside.   the code would still be subject to object's  limitiations 
on the access of self, which means you can't set it.

does context/make object!  simply protect/hide the self word when 
it creates the context?

You are able to make me feel so ignorant reading your discussion...

Maxim, the self word in object contexts doesn't actually exist. The 
word self that you see is a keyword of the BIND function. A selfless 
context has a flag in it (that you can't set with MAKE object!) that 
tells BIND to not set that keyword.

So if a selfless object actually has a real self field in it, it 
is still selfless.
>> selfless? foreach self [1] [bind? 'self]
== true
>> foreach self [1] [bind? 'self]
== make object! [
    self: 1
]

You can add a self field to a selfless context and it can be used 
like any other field. That is the whole point to selfless contexts.

Added an alternative BIND/CREATE to the #1758

Regarding the above "self issue", I am still a bit at odds, whether 
it wouldn't be preferable to have it as in R2, where all contexts 
were selfless, objects just containing the word 'self.

I must be somewhat "dense" not understanding the benefits of the 
change.

To make myself clear, I do not object against the word 'self being 
protected..., the only thing I mind about is the "keywordness" of 
the word.

When I think about it, it is funny, since I neither object against 
the fact, that the 'self word is a keyword of the object specification 
dialect, as it was in R2.

Benefits of the change:
- No overhead for the self field.

- No more blowing the stack accidentally because of circular references, 
or other annoying bugs.
- No problems with printing.
- No more settable self security hole.

Also, in R2 self is a predefined word in the object context, not 
a keyword. It's a keyword in R3.

If you like you can think of self as being a binding artifact in 
R3. At least it's not as much a keyword as 'export and 'hidden in 
module bodies :)

{- No more blowing the stack accidentally because of circular references, 
or other annoying bugs.} - interpreter bugs, if not corrected, they 
may be still "lurking"
{ - No problems with printing} - the same case

{- No more settable self security hole.} - that is not related to 
"keywordness", just to "protectedness"

{in R2 self is a predefined word in the object context, not a keyword.} 
- 'self is a keyword of the object specification dialect. Actually, 
it is a keyword of the object spec dialect in R3 as well. The introduction 
of the selfless contexts cured the problem of making 'self a keyword 
of other dialects, like FOREACH.

So, the main advantage to stay is the "no overhead for the self field"

coming at the price of needing the "sefless flag" for all contexts

(not that bad, I admit)

But, the second price is how to explain such property to beginners

On the other hand, we probably don't have to say to beginers that 
"there is no spoon" (ah, pardon, self), it suffices to say "self 
is protected".

The article

http://www.rebol.net/wiki/Exception_proposals

updated. Changes:

- LET function
- SELFLESS function
- readabilty improved

(the BIND-TO-NEW function was removed, which enhances source readability 
in my opinion)

Ladislav, those disadvantages applied to the self field. Of course 
there is other code that still has those disadvantages. That doesn't 
make R2's self field have them any less.

Agreed on the readability improvements of using the LET function. 
You didn't get the whole SELFLESS function.

And you might want to get into the habit of using CAUSE-ERROR, since 
it makes your code look simpler and hides the differences between 
R2 and R3 errors.