World: r3wp

its not dynamic inheritance

It's not. We do dynamic inheritance manually in REBOL. Our objects 
are object-oriented in a different way than class-based langs.

but having classes is MUCH faster. I mean exponentially.  as in liquid 
we are talking about 100 times on large datasets.

and with huge datasets it becomes wholly impossible to work with 
rebol's object system.

accessors would allow us to build ANY OOP theory within.

You optimize your code differently for prototype-based object-oriented 
languages than you do with class-based.

even hiding liquid's dataflow engine to make it completely invisible 
  :-)

you can't optimise the fact that rebol's static binding has to be. 
 this is both slow and memory intensive.

using classes in liquid I was able to go over 1 million nodes in 
a decent time frame, under 400MB.  using prototypes, I wasn't even 
able to allocate 100000 nodes.

and at 10000 nodes, IIRC it already takes like 10 minutes.

Accessors are one proposal for the upcoming object revamp. Class-based 
is unlikely, since we can emulate classes just as fast as any other 
non-compiled language.

10000 (concurrent) nodes in current liquid takes a few seconds to 
allocate  :-)

You don't have the R3 tricks.

then the liquid classes will be Even faster in R3?  ;-D

if they didn't crash it outright  :-(

Of course, but only if you get involved in the development discussion 
when we do the object revamp :)

is there a target on when that will happen?

No, we are working on modualrizing and codecs right now. I'll keep 
you in the loop :)

if someones give me a ping when the discussions will start, I'll 
be most happy to add my 2 cents.   I hate OOP, but I love to use 
objects.

and I think liquid is a great test bed of one of the most advanced 
object usage in R2 to date.

one of its strengths, is the fact that I can switch classes on the 
fly  :-)

I want accessors for other reasons (interoperability with other object 
systems).

I want accessors to provide virtualised internals.

The R3 GUI is class-based with dynamic inheritance (and switchable 
classes), so you can be sure that we will make that fast.

cool.

And modules use object! contexts, so we will be adding access controls 
to objects so modules can use them :)

that is cool  :-)

contextualise module methods based on state  :-)

btw, I'm really sorry if I'm not participating in the R3 GUI effort... 
I'm just elsewhere in the GUI world... what you guys are doing, I've 
done so many times, on too many platforms, for it to be still *fun*.


a lot of people don't get that I use (and occasionally abuse) rebol 
for my own long-term goals.  its just the fastest prototyper out 
there.  Now that GLASS has officially started, the (eventual) end 
goals for it are sort of beyond current desktop/window/button/menu 
 concepts of GUI, even if that is what I am starting with, cause 
I need the bricks before building the wall.

but when R3 gets a bit more stable, most of the work done in R2 will 
go over R3.  I'll only have to recode one or two core libs for all 
the rest to function.

Keep in mind that I am not really participating in the R3 GUI effort 
right now either - I've been working at a lower level. I write LOAD 
:)

Maxim - you have strange aproach. On one hand, you claim you did 
GUI and object stuff so many times it is no more fun for you, but 
on the other hand you complain, that R3 does not allow OOP functionality 
x or y?

And other mezzanine and intrinsic functions too, but I'm the author 
and designer of LOAD right now, and it doesn't get much lower :)

pekr:  I rely on objects for much of my work.   I hate the profound 
OOP theory (polymorphism and some of the dark OOP concepts), but 
like carl and most rebolers, agree that the primitive object is a 
very worthwile concept.  As is the case for many paradigm, they sometimes 
evolve themselves into such a complex form, that they lose sight 
of their original DNA.  


have you ever tried to support traditional OOP applications with 
multi-level inheritance and accross the board polymorphism, double 
inheritance and some other things like templates and more... it all 
starts out nice, then it locks you in.  you eventually get stuck 
by the framework being so much work to evolve, that you just keep 
adding new things instead of fixing the old.

I didn't say I did object stuff many times, only the gui part of 
things.  I've been implementing gui apis for like 15 years, at various 
levels... all with the end goal of getting to GLASS.

I worked with CA Visual Objects, which is trongly typed OOP. Most 
of the time you are trying to find out your way of how to obey system 
limitations. I hate that stuff. But - my question is different - 
with your  strong experience - why don't you just help with R3 GUI? 
;-)

AND for the record... I didnt complain  ;-) just said that having 
accessors would allow us to make R3-based apis much more fun and 
easy to use  :-)

... there is very few ppl contributing. Most of guys from here being 
invited to R3-gui showed no real input to Carl.

hum,  tough answer... it would be a mix of time, desire, and past 
history.

my vision of computing has always been deeply rooted in dataflow. 
 I have talked to Carl about it, even shown him some of it at devcon, 
but it was decided at some point in the R3 circle that dataflow was 
an overkill for R3.

I do agree, in fact.

that is, until I get a solution that works end to end.  Ubiquitous 
application of dataflow at this point, is still an experiment.

my prototypes encourage me to continue, since, I am always amazed 
at how it behaves in the end, but I have still to merge all of the 
solution into one bundle.  and no, its not simple, and yes it takes 
more code than what Carl will build in R3.  but in the end, I'll 
be able to interconnect a field directly to a web-servers' cgi-like 
page online, without actually needing to code anything.   one litlte 
line of code will allow both to interact with each other.


once all is done it will be easy to grasp, but currently, even I 
have some "challenges".  good thing is that in keeping with dataflow's 
programmatic simplicity, porting GLASS to R3 will be dead easy.  

so long as liquid works on R3. the most work will be adapting liquid 
globs to R3's gob! type, and even there, it could be pretty simple, 
if R3 has draw and its similar...

There is no reason, GLASS and R3 VID can't co-exist, in any case. 
 Choice is always good.

re contributing to 3.4 GUI - in the beginning I did testing and some 
creating but it became frustrating creating controls/widgets by always 
working around the various gotchya's that I decided to test only 
and wait for beta until trying to create complex widgets.  In the 
meantime i'm toying with my old onyx system and converting it to 
use geomal's GLServer.  I program for fun these days and if im not 
having 'fun' i move on to something that interests me more.

Maxim: please explain what you mean for accessors and why rebol has 
no accessors

For the others: if I have the following piece of code

Rebol []
o: make object! [
	a: 1
	b: 2
	]
x: make o [
	C: does [print [a + b]]
	]
o/a: 2
x/c


I expect that changing o/a also its value is inherithed in the object 
X and X/C should give 4 as results.

Isn't that a bug?

giuseppe no, it will give you 3.

o and x are unrelated after the make o.

it would work if you change o/a before you create the x object.