World: r3wp

es5 adds a lot of new tricks for playing around with values.  the 
args list can be retrived, applied, changed, etc.  I'll admit the 
part about the code body is a bit fuzzy in my mind, but I seem to 
remember that you could play around with it in some way too.
 

playing around with the functions isn't exactly the same but the 
end results are very similar IMHO. 

especially since hot-patching isn't allowed in R3 anymore.

switched to the right channel

one thing that ES5 does which I still long for in REBOL is how they 
have opened up the accessors, for everything as well as management 
of object keys, and member attributes like writeable, replaceable, 
public, etc.

oops, yeah sorry.

When you make a new REBOL function without changing the body, the 
new function will have a deep copy of the body, not the original.
 - why the copy?

BrianH: maybe it was not practically usefull, but removing hot-patching 
capability from REBOL - haven't we lost some level of reflectivity?

Because it has to be rebound, and because inline series data is modifiable.

haven't we lost some level of reflectivity?
 - Yes. The unsafe parts have been removed.

I would prefer an optionnal mechanism

R3 is being built to be able to run untrusted code. Still a goal 
rather than a reality yet, but it's a *design* goal.

And you have an optional mechanism: You can derive a new function 
and replace the references to the original. If those references aren't 
protected.

not sure if hot patching was any usefull. I used it just to show 
my friends, that I can modify my func from inside its code block. 
But you can dynamically eventually build copy of function, etc., 
so not sure not having a hot-patching is a problem ...

If the references *are* protected, then that means that the code 
using those references expects the code to be the same, to run the 
same, or else. The ability to hot-patch that code destroys that trust.

hot patched code can be difficult to read :-)

Ugh, agreed Henrik :(

Pekr: "when is A98 going to be released?"

I don't know. I thought soon, but then Carl went wild with fixes 
and core semantic changes like the 'self stuff. It may still be soon, 
since those are done. It depends on how many more magic tricks Carl 
wants to pack into this release.

rebol 3 are you around ?
shandwolf pokes rebol 3 .. hum ? still breathing ?

OH COMON I WANT R3 FULL RELEASE BEFORE XMAS 2010 !!

in advance thank you

Funny :)  We missed your input in the huge flurry of R3 development 
last week though.

There is an ongoing discussion about REBOL3 objects and accessors 
ongoing into the "Other Languages" section. BrianH and Maxim have 
discussed and a proposal has been made at http://www.rebol.net/wiki/Objects_enhancements.

This proposal is only of their side and we request the other GURUs 
to partecipate to build up other POV.
Then the proposals will be submitted to Carl.

Please partecipate ! The object  heart is open right now and in the 
hands of Carl ! :-)

I see it as a matter of priorities, and declare, that it is not my 
priority.

Ladislav,  we see Carl focusing on some or some other part of REBOL. 
This time he is working on the object part of the language. It would 
be good to have your (and the other) respected opinion about this 
topic now. Maybe we will be able to close this topic which has been 
opened in the blog in the distant year of 2006.
However, no one is forcing anyone to do anything...

what's 'filter-error? It's undefined in R3 .... http://www.rebol.com/r3/docs/errors/internal-bad-path.html

I expect that it is just some adhoc function that Carl rigged up 
in order to be able to generate the examples on the error pages.

Yes, Giuseppe, understood, what I wanted to say (to not sound rude) 
is, that I prefer to not "distract" Carl with this, seeing other, 
more "urgent" problems in CureCode...

I would especially like to see is the problem of Throw, Break, etc. 
solved, and the problem of function Return (comprising other issues) 
solved.

Don't worry Ladislav, the Parse project took a few months to sort 
out before there was a need to involve Carl. It should take some 
time to just search through the blog and comments for ideas (minus 
the inappropriate ones of course).

And, maybe surprisingly, I really do not feel an urgent need to solve 
this, being pretty content with the current state of affairs

And that few months was with just two main participants, some historical 
suggestions and a few helpful souls. The object debate would affect 
more people.

Regarding Parse: I am quite surprised, that only two people (in esence) 
edited the enhancement proposal in a substantial way, while others 
(surely having their wishes, or opinions) did not "dare" to commit 
more changes to the document...

I don't mind the current state of affairs either, as the current 
(post 'self debate) object model (including the PROTECT tickets) 
works great, and is more general than object models with explicit 
support for classes and properties. It would help if you could look 
over the PROTECT tickets though, Ladislav.

OK, I will take a look

For the Parse proposals, I was collecting them from here, resolving 
the debates ahead of time. The only person who didn't participate 
in that way was Peta, whose contributions were greatly appreciated.

I admit that i participated only a little in the PARSE debate cause 
brian did such a great job at doing all the PR about it, and because 
I was mostly in agreement with all proposals.

I still wish we could use functions as dynamic rules.

The PROTECT tickets to look over are #1014, #1015, #1141, #1142, 
#1143 and #1148. Though in theory SECURE 'protect (#1143) was implemented 
already, the actual setting that it is meant to secure (#1141 and 
#1142) has not been implemented, so there's no way to test it.

BTW, although I had the access to the R3 docs, and having edited 
some parts (Random e.g.), now I cannot log in. Even though I posted 
Carl a msg in R3 chat, the situation looks unchanged, so I cannot 
edit the TO-BINARY to finish the #1539

I already brought this up to Carl in a private message. He apparently 
forgot that we lost that ability in the website redo.

Ok Ladislav, I have understood your position. The discussion about 
accessors will take some time then we will submit it to Carl. I am 
sure you has already noticed the TOC page change via Wiki notification.

Sorry: you -> he has already noticed

Good night to everyone. I have to recover from the short sleep night 
of monday.

Keep in mind that accessors aren't the onlt thing under discussion. 
I can recall at least a dozen proposals made in the blog, and all 
of the interesting ones will need to be considered.

init and destructor accessors too.

might be nice to support print accessors... what do you think?

Accessor syntax on its own is too inefficient to implement. It might 
be worth it if combined with Carl's class suggestion though.

I woudn't mind if accessors where reserved for classed based OOP. 
 the controler and model are separate so its a logical match.

As for Maxim's suggestions above: init and destructor methods (use 
the right terms, Maxim), maybe; print accessors, no. REBOL is not 
an OOP language, so we don't need the workarounds that OOP languages 
need.

Not all methods are accessors.

Print accessors are like those asString() methods that many other 
languages' OOP systems have.

well, in some places they use the terms accessors when supply your 
own init/destructor pairs.  python for example

Python is an excellent example of the kind of term misuse that comes 
from rampant misunderstanding of most CS.

fdel is a property in python, but init is a method

you don't specify them them the same way.