World: r3wp

Why do you bother to try to help Tutorial translate a non-working 
code example?

It is working example.

OK, but then it is a trivial example, as I see it

the only problem in R2 is the extension of prototype object  for 
new fields imo

this is not worth discussing (I do not use JS at all, using only 
Java from time to time), but where did he use that in his code?

He is just imo trying to say, that rebol is incapable crap, as he 
does most of the time ...

I think that in REBOL we are not able to use path accessors to get 
redirected to prototype subobject. Other than that, with special 
accessors, it might be possible ...

Where in his original code did he do such a thing?

I guess, that the main difference which he is showing is, that in 
REBOL we must specify field names, like:
person: context [
	firstName: secondName: none
	whoAreYou: does [print [firstName secondName]]
	WhatIsYourSex: does [print sex]
]
extend person 'sex "male"
JaneDoe: make person [firstName: "Jane" secondName: "Doe"]
JaneDoe/whoAreYou
JaneDoe/WhatIsYourSex
ask "Are you sure?"
JaneDoe/sex: "female"
JaneDoe/WhatIsYourSex

Is that what he is requesting? We can implement semantically equivalent 
code in REBOL, but that exact code can't be made to work.

I don't know what he is requesting.

It's just the only difference I can see.

We can implement semantically equivalent code in REBOL, but that 
exact code can't be made to work.

 - I do not understand - that code works, what does "that exact code 
 can't be made to work" mean?

It looks like a question, based on the object model of JavaScript. 
REBOL objects don't have "children" in that way, as we don't do delegation, 
just prototyping.

WhatIsYourSex has a function that is bound to the object *before* 
the word 'sex is added to it, so the 'sex it is getting is not person/sex. 
It only works for objects derived from it. Unless I missed Oldes' 
point, and only working in derived objects was intended.

Of course this has no sense even in the JS version. The only difference 
is, that JS would return undefined, REBOL throw an error. The second 
is better for me.

OK, so, generally - a nonsense, that actually works the way he wants 
it to, so what?

He wants to show this:
    JaneDoe = new Person("Jane", "Doe");
    DoeJane = new Person("Doe", "Jane");
    Person.prototype.sex = "Man";
    JaneDoe.WhatIsYourSex();
    JaneDoe.WhatIsYourSex();

in JS if you extend the prototype, you extend the already existing 
objects as well.

The equivalent to what RT requests would be to extend person *after* 
JaneDoe is created, and then have JaneDoe work. JS supports this 
(in some circumstances).

The equivalent to what RT requests would be to extend person *after* 
JaneDoe is created, and then have JaneDoe work.

 - why do you suspect him not being able to demonstrate the code he 
 wants to work?

Unless I missed Oldes' point
.

I suspect that RT can't demonstrate the code that he wants to work 
because he doesn't even seem to be able to understand the difference 
between R2 and R3 objects, calling it syntactic sugar when it's not, 
even after it is explained to him. If he can't understand that, it 
is less likely that he will understand the difference between REBOL's 
and JS's object models.

I make a distinction between "doesn't" and "can't" when it comes 
to understanding. Only close-minded people "can't".

I'm pretty sure he wants to show above functionality.. as he says: 
"extending an object instance from another one with make in rebol 
isn't exactly like javascript prototype property as js prototype 
allows to extend ALL instances at once."

To get this functionality, the prototypes would need to know it's 
childrens. And extend them as well. The JS model is simply different.

In ActionScript it's common that you, for example, add functionality 
to all existing buttons.

That can be done in REBOL, but it requires planning for it ahead 
of time and a bit of explicit redirection. This is done in the R3 
GUI.

Although I use above from time to time, I don't like heavy class 
based code as I consider it very unreadable.. I've seen many such 
a (ActionScript) projects.

GUI frameworks tend to be a good place to use class-based or delegation-based 
OOP, as we do in the R3 GUI.

And to a lesser extent in VID as well.

Styles are classes, which we explicitly delegate to.

I did not read all your discussion, so sorry, but do you guys understand, 
what the JS prototype means? It simply means, that each object can 
have (or has), its prototype

REBOL has prototypes already. The JS .prototype also implements automatic 
delegation, and it was that feature he was asking about.

Also in JS, the newly created object hold the parent information 
- in __proto__ value:
	alert(DoeJane.__proto__);

That is not consistently so - it depends on the engine.

obj: context [
    name: "Jane Dow"
    proto: context [
       sex: 'male
    ]
]

So, in above case, JS allows you to query:

obj/sex


... and if no 'sex object field is found, then the accessor looks 
into the prototype subobject, which can be referenced ... and the 
chain continues. Just see:

http://mckoss.com/jscript/object.htm

Yes, but that feature is not the "prototype" feature of JS's prototype-based 
OOP, it is the delegation feature. REBOL is prototype-based without 
delegation.

The above is wrong, the 'proto must be a pointer to the parent which 
you used to make the object.. in my REBOL code above it's the person 
object.

I really wish that JS had done a better job with its prototype model. 
Self and NewtonScript were better.

we could have something like:
new: func[obj /local newObj][
	newObj: make obj []
	extend newObj '__proto__ obj
	newObj
]
p: new person


but as a native so as Pekr said, if value is not found in the object 
itself, it would look in the parent.

the __proto__ should be hidden so it would not be visible on probe.. 
but again... I'm not sure we need it at all.

Implicit anything is helpfull(?) for hiding stuff from developers, 
but since we can do stuff explicitly its lack doesn't make us disabled. 
And every implicit thing that we can't turn off reduces our flexibility 
- as demonstrated in the selfless debate.

Well, so maybe you educated guys could answer him ... but my opinion 
is, that I am not sure he will understand, he tends to be pretty 
stubborn to change his mind, even if things are explained to him 
 ...

One could simulate a simple delagation behavior if Rebol had an intrinsic 
mezz when and error is processed.

So that, in the intrinsic do-error, one could discard some errors 
and return a useful computed value in replacement.
See what I mean ?

Direct binding, remember: Objects are independant of their prototypes. 
But we will see once object specs are implemented.

I don't really see the point though. Explicit delegation is not hard 
to do, especially when you write accessor functions, like in the 
R3 GUI.

BrianH - you can't solve it for the path notation though. If what 
Steeve writes would be possible, then it would be workable, because 
obj/nonexistant would be catched by the intristic mezz, where the 
error would be processed ...

That's the idea

However - I see it nearly as a coiccidence, that obj/nonexistant 
does not return none. IIRC, in some other cases, for the R2->R3 transition, 
we decided to return none instead an error ...