World: r3wp

Hidden fields are weird.

Well Brian, Your words have no self meanings outside this discussion 
either

Very existential of you: self has no meaning :)

until it's bound to something

to a context for instance

I feel like that sometimes whenever I'm single.

too selfish :)

The funny part of all this is that if the "hidden 'self field" is 
mandatory and not modifiable, R3 doesn't necessarily have to have 
a physical field to store it: It could be implicit. It's just a matter 
of whether having the physical field there is more efficient to implement 
than an implicit field (which I suspect it is).

Oh, Ladislav, you're going to hate this worse that THROW not throwing: 
What we call "contexts" in REBOL aren't contextual :)

well in R2 it is explicit and modifiable

well in R2 it is explicit and modifiable
 And a security hole because of this.

(Did I just say that out loud? Stupid web-public groups.)

I must admit, I don't really understant that claim. Why is it a security 
hole ?

Because 'self is *used*, by code that expects it to refer to the 
same object that it is bound to. So if it is changed to refer to 
another object, that code fails. And if that change of referent is 
carefully done on purpose it can break the code in ways that it wouldn't 
detect. And that can be bad in some cases. Admittedly, it's not a 
big hole. BIND? doesn't have this problem: It doesn't return self, 
it returns the real context reference.

BIND? was originally added to R2 to deal with that security problem 
- we used to use 'self more often. And in R3 the 'self is protected, 
and not unprotectable by UNPROTECT in a special case. So it's not 
just BIND that special-cases 'self.

And once the context is created and extends beyond the function of 
its initial creation, there is no standard for which is more common.

 - actually, there is a standard, successfully used in R2: always 
 do the same, which is both consistent and "what is needed", since 
 that is, what the programmer asked for

Amen

Ah, but in R2 those contexts were broken when they extended beyond 
the life of the function that created them. The first field was treated 
like 'self, and hidden.

I like reading the scriptures.
The Gospel according to St. Ladislav.

And the programmer that matters when it comes to BIND is the one 
that is calling BIND, and providing the code block. Not the one that 
made the context. It's different with internal use of BIND, functions 
that make, use and discard a context. If the context persists then 
it needs to behave in a predictable matter. R2 is not a good example 
to cite when deciding what is good coding practices; we made the 
decision to change things in R3 for *many* good reasons.

If the context persists then it needs to behave in a predictable 
matter.

  - and I mean predictable by someone who didn't make the context in 
  the first place.

Otherwise we won't be able to write generic code that works with 
all contexts.

And once again, I regret that we decided to use the term "context" 
so badly here in the REBOL community. It's really inappropriate.

It's much better to call them objects; the Lisp community calls them 
environments.

And the programmer that matters when it comes to BIND is the one 
that is calling BIND, and providing the code block. Not the one that 
made the context.

 - this is interesting, again. My note is, that if the context was 
 created to support e.g. the functionality of For, then any subsequent 
 binding is meaningful for me, only if the functionality remains supported. 
 I think this way, even when I am the one calling Bind and providing 
 the block, unfortunately, I may not know, which alternative mentioned 
 by you to use, not knowing the type of the context I obtained.


As opposed to that, when I see a context without 'self, I know, that 
the context was created so, that it is not meant to support 'self 
binding, and that is all I need to know. How would you do it obtaining 
a context of unknown origin, that would contain '"unsolicited" self? 
(of course, not knowing that information, since there is no way how 
you can find that out)

I meant the above as a contribution to the "predictability" issue 
- how can you predict, whether the block would behave as originally 
intended, not knowing, what the original intent was?

(unfortunately, the same objection applies to #1544, since then, 
again, "the original intent" is lost)

Generic functions that work on objects don't see the code that originated 
them. They can only tell how the objects are supposed to behave with 
their own code. Original intent was contextual (using the term correctly 
this time). Current behavior is a different context.

It's like that quote from The Incredibles: "I know what I said before! 
Listen to what I'm saying *now*."

I provided above a specific example, that demonstratd clearly what 
I meant. The support for code like that is missing in R3 and remains 
missing, even if any of #1544 or #1543 will be accepted.

What you want is for objects created by loops and functions for their 
local variables, but persisting after their creators are finished 
with them, to *break* all other code that expects objects to behave 
like objects. Same as in R2. It was a bad idea in R2 (which we can't 
fix) and it's a bad idea in R3.

This is what we get for calling objects "contexts": It makes us think 
they are contextual, when they aren't.

If you don't like the hidden 'self field in objects in R3, fine, 
but it was a fix to major problems in R2. Problems we don't want 
to come back.

...to *break* all other code that expects objects to behave like 
objects...

 - this has been demonstrated by Andreas to be false - I do not want 
 to break any behaviour of objects, I do want to not break behaviour 
 of other contexts than objects

...and, besides, my code example above is not of the kind "after 
their creators are finished with them"

Only the function! type creates other "contexts" than objects: It 
creates a stack-relative objects. All other contexts *are* objects, 
internally. Even those used by closures and loop functions. There 
is no difference.

yes, harm already done, the closure, For, Use, Repeat, Foreach, etc. 
contexts already broken

They were broken in R2. Problem solved for R3 - we just have to manage 
the binding trick.

as demonstrated by my code, already broken, my code works in R2

Oh, and module and script contexts are objects too (internally in 
the case of modules).

Your code does what you want it to in R2. That is not the same thing 
as not being broken.

OK, I say it differently: the functionality demonstrated by my code 
is not broken in R2. The functionality demonstrated by my code is 
broken in R3.

Your car has a broken axle that makes it go left.
 "Oh, don't worry, I only want to go left anyways."

There should have been a :) in there somewhere I guess.

OK, playing with you: "my car has a broken axle that makes it go 
left, therefore, I can easily demonstrate, that the functional ability 
of my car to go left is not broken". how can I call a car, that does 
not have this functionality, i.e. it cannot go left?" - I call it 
broken

Sorry, i meant "go left only in a 20ft radius circle", I didn't mean 
something most people would want to do when they aren't showing off.

Once again, this issue could easily overcome by having to separate 
types

Imagine that your DO-IN-CONTEXT function was written by someone else, 
to take any object, and depended on the 'self override. That is the 
most common case for functions that operate on objects they did not 
create and use 'self. Those would be broken if there is no 'self 
.

If you want an context! to behave like an object!, convert the former 
to the latter

yes, that is very reasonable for me, as a clean solution