World: r3wp

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.

That second bit is the good part: "creating virtual variables dynamically 
at runtime". Detecting and preventing errors is often better done 
with local code because what needs to be done in the case of an error 
is usually dependent on local circumstances, rather than something 
that can be defined globally.

Fortunately we have a couple types that are good at creating variables 
dynamically ar runtime: map!, and with a little more work object!.

Nonetheless, the more advanced hacks that people do with messageNotUnderstood 
are the reason I wanted utypes. And we might get some of them with 
object specs - who can say at this point?

BrianH: if you don't have anything better to do, you could read one 
chapter from CA-VO language - chapter 25 - Classes, Objects, etc. 
I used it some 12 years ago, so I don't even properly remember it. 
But it allowed some nice tricks, as having access/asign methods, 
where you just used normal assignment operator, and if your child 
overrided the variable with virtual method, you still did not need 
to change the source code, you still used asignment.


What was also handy was various types of visibility - protect, hidden, 
export  .... in regards to class, inherited classes, and instantiated 
objects. I wonder if possible new object specs could work more like 
a modules, having exports too, etc. But maybe we don't need to complicated 
the stuff further ...


In case you would be interested - http://www.cavo.com/support/manuals/vo25pg.pdf

It's always amazing what people will do to avoid calling a function 
:)

I think it was done to unify assignment and function call :-)

I'm wary of adding mezzanine overhead to assignment, even set-path 
assignment, having seen the maintenance nightmare that such tricks 
cause (having worked for years as a developer using languages with 
"properties"). Still, more and more we need to integrate with APIs 
built for languages with "properties" (like Objective-C and .NET). 
Utypes would be helpful for that, and I have advocated their use 
for just that purpose; particularly .NET, where there is a theoretically 
compatible syntax and no efficient C equivalent API like there is 
for Objective-C dispatch.

that's the sole purpose: one syntax to rule them all

but it's also true that i don't like hidden cascading method invocations

I understand the desire to unify assignment and function calls, but 
it mostly leads to code that can't easily be understood. Having to 
read the entire source code of Delphi's VCL more than once just to 
understand what is supposed to be a simple assignment statement (this 
happened) is an inevitable consequence of this approach, eventually.

Objets language are a mess because of that.
We all know why we real programmer prefer C and hate C++ ;-)

ok - so what needs to be done to get us utypes? :-)

And you can screen function calls for security (we do this a lot 
in the mezzanines). It is much more difficult to screen assignment 
statements with other side effects.