World: r3wp

SELFLESS? -> SELFLESS ?

No problem

I did my best to argue for it by doing a thorough ticket and writing 
best-possible-without-it example code for LET and BIND-TO-NEW, to 
show how much it is needed.

I really like LET

especially when you put GET and SET besides it... all of a sudden 
I wondered... well, shoudn't LET have been the very first function 
evaluator  :-D

Yup. I've been meaning to write a LET for years, but this has been 
the first excuse :)

Gregg: thanks for the "inverted programming" notion, I like it a 
lot. (used it in the #1758 comment)

Brian, BTW, there is one reason why to prefer LET instead of CONTEXT: 
CONTEXT always yields the block it reates, while LET could yield 
a result that is wanted more.

I agree, especially when that is what you want more. SELFLESS is 
more comparable to CONTEXT.

err, block: :object, in my post

Q:  is the self word of a context something that can be bound to 
blocks within a method of that object?

did not understand your question probably; did you mean something 
like this?

>> same? 'self first bind [self] make object! [a: 1]
== false

Or, maybe more in the line with what you wrote:

make object! [method: func [block] [bind block self]]

yes that'ts it.

because with SELFLESS it would be interesting!

>> a: context [a: 1]  same? a first bind [self] a
== true

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.