World: r3wp

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.

And what do you think of modules like properties for objects? I mean 
e.g. export property? I think that complicate the case further probably 
does not make sense?

Modules are higher end, and I can replace the code if I had to (and 
have more than once). We don't need export-like properties for objects, 
we can easily just use modules for that, even modules constructed 
at runtime. The main advantage to objects over modules is that they 
are fast and simple.

Most of the module-like stuff we used to do with objects can be done 
with modules instead. We should be conservative about what goes in 
an object spec.

You'd be surprised at how easy it is to add a keyword to make module! 
syntax. Having done it once, doing it again was mostly copy-paste 
of the first keyword's code, and figuring out the interactions and 
priorities. And the code is (intentionally) small and simple.

Can someone tell me the current state of R3?  I'm a bit confused 
as I don't keep up with the news enough.  Can we do graphics yet? 
 What are we looking at from a performance perspective, etc..?

R3 Core is quite usable, but it still heavily depends on your needs 
(some areas are rougher than others). Basic graphics (draw) work 
on Win32 for hostkit builds. Performance on a script level was comparable 
to R2 (sometimes R3 a bit slower) for my uses, last time I did some 
measurements.

In many cases R3 is a lot faster. The whole balance of optimizations 
was shifted.

R3-optimized code is often faster than the equivalent R2-optimized 
code, and it looks nicer too most of the time, both due to native 
changes that make nicer-looking code more efficient.

BrianH, Ladislav, still have not understood why automatic delegation 
is so bad and not used in REBOL. From time to time this discussion 
arises again and again. Seems people are used to constructors and 
destructors and want them in rebol too.

Automatic delegation: sorry, that is not a question for me. I never 
told automatic delegation was bad.

What is bad, though, is writing a code sample in a question, obtaining 
a translation in Rebol working the same way, and saying: "Your code 
doesn't reflect the same intent as my js code..." - it is enough 
that he obtained a working translation of his code, if his "intent" 
was different, he should have written the code in accordance with 
it, this is exactly how it should *not* be done.

As far as automatic delegation is concerned: I am not missing it, 
but, certainly, your mileage may vary.

The fact is, that I can live without it, being able to implement 
a similar system in Rebol when needed (did not need it yet, though), 
so there is nothing I could miss.

...people are used to constructors and destructors

 - that has nothing in common with automatic delegation, though, at 
 least I feel it that way

Well, we were only wandering, discussing about how things could be 
done. There were no complaints in such.

In fact, there is complain. My whish is to read a statement from 
Carl to undestand which advantages he sees and the phylosophic choices 
made for REBOL.

*there is NO complain

Regarding the: "...why automatic delegation is ... not used in REBOL." 
- that looks as a question I could answer, though. Reasons (as I 
see them):


* the present system of independent objects is safer (no need to 
worry about somebody changing the prototype used to define your object)

* the present system of independent objects is simpler (no need to 
worry about such things as multiple inheritance)

There may be other factors as the ease to implement such a feature, 
or the speed of the interpreter, etc.

Ladislav, I have another question: why there are no SET/GET accessors 
in REBOL objects ?

SET works with objects in R3 (if that is what your question was about)

Similarly for GET

(may be handy)

How ? Could you make an example ?

>> o: make object! [a: 11 b: 12]
== make object! [
    a: 11
    b: 12
]

>> p: make object! [a: b: none]
== make object! [
    a: none
    b: none
]

>> set p get o
== [11 12]

>> p
== make object! [
    a: 11
    b: 12
]