World: r3wp

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.

I'm just curious, why you need accessors in REBOL at all?

but I'm just being devil's advocate I agree that most OOP languages 
consider constructor and destructors specific method types.

Right. We shouldn't be using the term "accessor" anyways: Too vague. 
All OOP languages support accessors. Most languages with the syntax 
support you are requesting call that support "properties".

rebolek, the best use is to allow control of state within the object.

Which we can do already, but syntax support allows us to hide the 
overhead.

Ah, ok.

For that matter, accessors can be written in functional or procedural 
style, often more efficiently too, as they are in R3's GUI.

So it's that syntax sugar? I like me syntax

The SET-FACE and GET-FACE functions are procedural accessors without 
the syntax support.

sorry

liquid and by extension glass use function accessors exclusively. 
 but i would like the syntax within the language... it would allow 
one to use many liquids as ordinary objects and make lazy dataflow 
much more palatable for the casual user.

Brian, exactly, that's what I'm using without problem for some time. 
So I don't understand this discussion, that's why I'm asking.

So the main thing that the property feature does (from my extensive 
experience using that feature in other languages) is to hide complexity. 
Which is great, until you actually need to know what the heck is 
going on - something that happens almost immediately. At that point, 
hiding the complexity means destroying your ability to understand 
your own code by looking at it, even a simple assignment statement, 
and forcing you into a particular model of operation that may or 
may not be appropriate. So it's great for Delphi, which comes with 
a built-in GUI framework and is supposed to be easy for VB-level 
programmers to use; it's not so good for REBOL, where the GUI is 
swappable and our users are in some cases some of the smartest people 
I've ever met.

still, 

my-face/text: "this"

is more transparent and reusable than

set-face  my-face 'text "this"
or
set-face my-face [text "this"]


ironically glass supports both of the above (using its own set of 
accessors)

set-aspect/get-aspect  and specify

transparent -> blackbox

my-face/text: "this" supports every REBOL object that has 'text, 
or not?

brian, api builders might be smart, but end-users might not (within 
a specific field of programming), and its not their place to have 
to try and resolve much of that.


if your api works, then it shouldn't cause side-effects break... 
using accessors or not.


accessors are for users of APIs which have a lot to manage which 
isn't going to be delt by the user anyways.  

my two cents.

The problem is that my-face/text: "this" would no longer be doing 
what you think it is doing.

I'll do a simple: 
text: "this"
:)

Brian, If I do something evil as my-face/text: :delete-your-hd ? 
or when?

brianh exactly... it would actually make sure the draw-block 'my-face 
 to is up-to date and make sure:

my-face/text: :delete-your-hd  

is refused

oops....    'my-face  to   ==   'my-face *refers* to

Hm, so to lower it to my level of understanding, what you want want 
is basically something like this? : ctx: context [a: 1 [integer!] 
b: "blabla" [string! block!]]

Darn, Steeve, you just deleted my hard drive and bombed Cambodia!

for example, liquid, uses processed fields.   most of my liquids 
will normalize input, and make sure the output conforms to the spec.


the value might even be converted to a default or a generally accepted 
unknown value like an error! or none!

rebolek, that is one thing that can be enforced with accessors... 
but it might also make sure that two cooperative fields are always 
reflecitve.


if text is updated, maybe I want to set another field which rememebers 
what changed, so that the next refresh doesn't have to rebuild the 
whole face, only what is related to text.

Max, you can still use ctx: [a: 1 set-a: func [v][a: do-maxs-magic 
v]] , no?

sure, but then you have two references to the same attribute and 
setting the field doesn't use the rebol syntax for setting the field.


I do agree that in R3, since we can protect fields, at least we can 
now enforce the use of set-a and be sure its not replaced as-well.

this is already a HUGE improvement over R2, where you can haphazardly 
replace the functional accessor without realizing it.