World: r3wp

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.

Currently I use 'resolve a lot, to swap contexts so that I can use 
a light syntax in every functions because they are all bound to the 
same context.

I try to eradicate paths the most I can, It's uggly and slower than 
swapping contexts at some points.

Maxim your flow engine could use the same way I think

I used that technic in an GUI trial for R3, the syntax was pretty 
 light.

Paths are very slow. Using outside functions to set fields in objects 
seems much more sane from this POV.

yes, 'resolve will be extensively used in liquid R3, especially in 
my graphic kernel which uses labeled inputs exclusively.


but it still needs to use class based path access for simple speed 
and memory requirements.  each class currently gobgles up about 20k 
of ram once bound.  rebinding on the fly would be excessively slow.


liquid's lazy provides vastly supperior optimization in any case. 
 functions aren't even called in the first place ;-)

resolving is different grom binding

*from

and glass even uses the liquid (trans)mutation feature where you 
swap classes on the fly based on oranisation of GUI

resolving is just a way to pass a bunch of vars in one shot

*parameters

yes... it just copies the values as-is from on object to another 
 like:   set in obj 'a get in obj-b 'a

I meant... aahhh yes... (just read the complete help string)

but fast

but because functions aren't re-bound... I don't see a lot of use 
for this since my dependency mechanism allows unlabeled inputs. (its 
actually used more often than labels... cause its faster right now... 
but that might change with R3, because we have much nicer binding 
control.