World: r3wp

So the behaviour you observe it's just another instance of missing 
COPY" :) `random/secure copy "abcdefghi"` will work as expected.

And yes, that is an incompatible change in R3 over R2. RANDOM in 
R2 was not modifying a series argument.

I expect that it was because we are trying to make R3 more efficient, 
so it is left up to the developer to decide whether a copy is appropriate 
rather than just assuming it is. But yes, incompatible, and without 
a change in function name, just like we rejected for UNIQUE and the 
other set functions. Oh well.

Actually a good example of how arbitrary those "efficiency" decisions 
can become.

As we could also choose to optimise for efficiency of the copying 
RANDOM.

It's not so bad when they are documented, at least in CureCode, but 
that particular change seems to predate CureCode by at least a year. 
And predate PROTECT, hence the bug with that.

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.