World: r3wp

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
]

(It was not the question, I guess)

In fact, it was not the question.

I mean as GET the automatic function called by an object  to return 
its value..

using the path notation ?

(back the topic)

There was a lenghty discussion in OTHER LANGUGES from 3rd of MAY 
of this year.
It led to http://www.rebol.net/wiki/Objects_enhancements

Giuseppe, part of the reason that there are no set accessors (what 
I called "properties" above) in REBOL is that there are no classes 
either, so such accessors would need to be defined on a per-object 
basis. This makes them quite a lot less useful. The other part of 
your question is that we *do* have get accessors: We use the same 
syntax for variable getting as we do for function calls, so you can 
just assign a function to a word and it will act like a get accessor. 
You only need real get accessors in a language that puts parens around 
arguments or in some other way distinguishes function calls. However, 
let's for the moment assume that you mean get-word accessors, functions 
that will still be called even if you use the GET function, a get-word 
or get-path to access the value.


But one of the main reasons is to avoid hidden unexpected overhead 
and security issues. Assignment is fast in REBOL, because it does 
basically the same thing every time (with some variation in set-path 
assignment). If we had properties, that would add overhead to every 
single assignment statement whether to a property or not just because 
we would have to check for that every time. In languages with native 
properties their compiler makes this determination and generates 
the underlying function calls. With REBOL that overhead is at runtime 
because we don't have a compiler. We could compile our own dialects 
to make set-word accessors - Gregg's COLLECT, or R2/Forward's APPLY 
or MAP-EACH do this - but it is slower.


The security issue is that at the moment assignment and get-word 
access is safe. Set-path assignment and get-path access is at least 
safe with the built-in datatypes. Accessor assignment is not safe: 
it can have side effects or unexpected overhead. If we had accessors 
then you could not safely use words that you got from unknown locations. 
We wouldn't even be able to screen for functions, which a lot of 
the mezzanine code does now. Combined with get-word arguments and 
that means that there would be no way to avoid code injection exploits, 
and thus no way to make even a secure subset of REBOL. 


Now with path syntax the behavior is (apparently) type-specific, 
so with the appropriate datatypes we can do accessor functions; .NET 
object wrappers would benefit from this, for instance. But that requires 
utypes, because there is no point to making built-in types have that 
behavior. Then for security we could just disallow utypes from a 
function that might otherwise be exploitable.

Ok Brian, I have understood.

Somethimes I think that we should add this clarifications to DOCBASE 
for further referencing.