World: r3wp

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 ...

Basically, you want message-not-defined from Smalltalk and Self (I 
know it's got a different name, bear with me).

path notation for blocks returns none, if the element is not existant, 
but it returns error for the object type ...

That fits our need...

Steeve - but it looks strange to dispatch object access method via 
intrinsic general error dispatcher ...

The reason everything gets shoehorned into (the local equivalent 
of) path notation in most OOP languages is because they are OOP, 
and thus don't have free definitions of functions outside of objects. 
We don't have that problem in REBOL - we can just call functions.

Pekr, It's strange only because it"s a new paradigm ;-)

Not that hard to implement to my mind

we are now apparently close to the object redefinition, maybe we 
could change a semantic, but not sure we want that :-)

We don't have to make everything act like OOP languages. If you are 
looking to other languages for ideas for REBOL, OOP languages are 
generally a bad choice (says the guy who wrote FUNCT based on ideas 
from Ruby).

... but then I don't know what Carl has in mind for object spec block

The spec is apparently intended to retrofit certain aspects of class-like 
behavior into objects, such as type specs and (internally) inheritance. 
Beyond that we don't know, because the discussion stalled due to 
lack of feedback.

And we can't get it started again until the blog starts working again.

Steeve, it's not a new paradigm, it's a paradigm from 70's-80's OOP 
languages. And it works for them :)

Let those who never spoke emphatically cast the first stone :-)

It's not hard to implement, but it's *slow*. There was more than 
a decade of research before they figured out how to compile and optimize 
languages to make messageNotUnderstood efficient, but it is still 
not that fast. And we don't even have compilation. Optimization of 
Smalltalk-like languages requires static analysis to determine when 
the message *will be* understood, in order to remove calls to the 
dynamic dispatcher.

(I wrote an implementation of a Smalltalk-like language back in the 
90s)

Current optimization strategies for JS also use analysis to remove 
the dynamism. Remember, JS used to be really slow too.

I don't know if the "slowish" argument is applicable in the Rebol's 
world.

I would limit the use cases to objects construction only, so that 
the "slowness" whould not be that much a burden.

Maybe something is better than nothing, even if it's slow

We already know that the DO function can be slow as hell because 
of its intrinsic mezz in R3.
So that, we reduce the use cases logically.

We don't have the option of using compilation or static analysis 
(except in dialects with more overhead). REBOL's speed depends on 
direct binding. We could (and can now) use path-based dynamic lookup, 
even if it's slower, and can refer to fields that weren't there when 
our functions were created through that notation. We can even do 
a version of messageNotUnderstood using IN tests and accessor methods. 
But remember that this:
    a
is faster than this:
    self/a
which is faster than this:
    either in self 'a [self/a] [something-else]


And "something is better than nothing" is not a factor, because REBOL 
is the way it is for really good reasons, and because the "nothing" 
is something we can do easily already.

DO of string! can be slow, but DO of block! is much faster. It was 
a tradeoff to increase the overall speed.

We do miss typical OOP facilities as being able to hook into init, 
pre-init, post-init, access phases ... E.g. Visual Objects I used 
in the past define:


You can prevent a runtime error from occurring when an
instance variable 
name is not found by defining methods called
NoIVarGet() and NoIVarPut(). 
These methods, if present, will
be automatically invoked whenever 
an instance variable cannot
be found. They are called with the instance 
variable name as a
parameter, in the form of a symbol and, in the 
case of
NoIVarPut(), with the value to be assigned as a second
parameter. 
This feature is useful in detecting and preventing a
runtime error 
and also for creating virtual variables
dynamically at runtime.