World: r3wp

I understand that there are limits to how efficient you can make 
copies. Making a copy is itself an inefficiency, since efficiency 
isn't just a CPU thing, memory usage matters too. However, this might 
not work as well when we are making a lot of series non-modifiable 
not just for protection, but in theory to make them sharable without 
conflicts. I'll put my concerns in the ticket.

Can we consider R3 being mature enough, to ask general R3 questions 
here? Or should we setup R3 Core (or Core R3) group?

I tried to look into Rebol Tutorial request for the JS 'prototype 
like functionality:


http://stackoverflow.com/questions/4272018/does-rebol-really-have-an-equivalent-for-javascript-prototype-property

Of course his speed claims are relative. I added some reaction to 
show how to extend objects, but studying JS prototype documentation, 
I wonder if something like that would be possible to simulate using 
REBOL? I know that we can have sub-objects shared/referenced. But 
JS Prototype is not just that - it is not about classes. It is more 
about the ability to have linked objects, and when querying a value, 
it is being looked-up down the road:

obj/value 


If 'value is not found in the object, then JS looks down to obj/prototype/value. 
And 'prototype here can be referenced from different constructor. 
I think, that it is similar to find/deep, but with simple/single 
accessor.

More is here - http://mckoss.com/jscript/object.htm

Generally I remember two enhancement requests in REBOL:


- find/first - from the list of objects find first one matching the 
query

- find/deep - look-up in nested structures. Most probably blocks 
were meant, so not sure it would work for objects ...

Any ideas if some enhancement request would be helpful (e.g. to allow 
JS 'prototype simulation) in that regard, to get us more flexibility? 
I am more interested in practical usefullness, than in some over-complicated 
object/class system ....

I wonder what is difficult to simulate on the JS prototyping? IMO 
it is possible to do it easily in REBOL.

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.