Mailing list home
  Find posts   Help

Latest messageRecent messages

Other threads:
 Prev: superformula
 Next: mac osx 10.3

 Random thread

Indexes:
 By topic
 By date
 By author
 By subject
Join the Mailing List....
AccessibilityAbout / FAQ
Member's loungeContact/FeedbackOther REBOL links
Membership:
member name

password

Remember?

Not a member? Please join
19-Apr 19:07 UTC
[0.091] 18.328k
Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Private words in objects?

 [1/12] from: alberto::origen::com::mx at: 4-Jul-2006 1:00


Hi all, Somebody can clarify to me why rebol "objects" does not support protected (read only) variables ? This question came to my mind after spent hours debbugin a large script... and well, I think I had been able to debug it faster if I could make protected variables inside the objects. I want to say, I'm not asking for an implementation to protect variables or functions, I just want an explanation :) Ciao Alberto

 [2/12] from: lmecir::mbox::vol::cz at: 5-Jul-2006 9:58


Alberto napsal(a):
> Hi all, > Somebody can clarify to me why rebol "objects" does not support
<<quoted lines omitted: 8>>
> Ciao > Alberto
For protected variables see the PROTECT function. -Ladislav

 [3/12] from: tim-johnsons:web at: 5-Jul-2006 7:19


* Ladislav Mecir <lmecir-mbox.vol.cz> [060705 00:09]:
> > > For protected variables see the PROTECT function.
Hi Ladislav: I've never been able to make protect operate on a context or a member of a context: see console session below:
>> help protect
USAGE: PROTECT value DESCRIPTION: Protect a word or block to prevent from being modified. PROTECT is a native value. ARGUMENTS: value -- The word or block of words to be protected (Type: word block)
>> d: context[a: 1] >> protect 'd >> d/a: 2
== 2
>> probe d
make object! [ a: 2 ]
>> protect in d 'a >> d/a: 3
== 3
>> probe d
make object! [ a: 3 ]
>> ;; Doesn't work!! >> protect d/a
** Script Error: protect expected value argument of type: word block ** Near: protect d/a tim -- Tim Johnson <tim-johnsons-web.com> http://www.alaska-internet-solutions.com

 [4/12] from: greggirwin:mindspring at: 5-Jul-2006 10:16


Hi Alberto, A> Somebody can clarify to me why rebol "objects" does not support A> protected (read only) variables ? REBOL was designed for building small systems, so choices like this lean towards making things as simple as possible, and may also have been due to implementation choices. REBOL 3 may offer something along these lines, since a lot of people have come to expect it from OO languages. You *can* do it today, but it takes extra effort. I thought I would do it a lot, once I figured out how (with the help of people here), but I've never used it in a production system. In your case, how would private words have helped? Did a word in an object get reset accidentally? -- Gregg

 [5/12] from: alberto:origen:mx at: 5-Jul-2006 11:35


Hi Ladislav,
>> >> > For protected variables see the PROTECT function. > > -Ladislav >
Yes, you are right. But you didn't understand my question, but was MY FAULT because I mixed terminology used in oop with terminology used in rebol programing. Sorry for That. When I said "protected" variables I mean: (using oop terminology) a property that is read-only for the "client" (normal code), but is read/write for methods (code inside the class/object) If I could write it in rebol (hypothetical code) would be: obj: make object! [ field: 0 protect-this 'field ;; **** NOT REBOL CODE: pretect only for client inc-field: func [][field: field + 1] ] Now, if you write
>> obj/inc-field >> obj/field
== 1 'field was incremented but
>> obj/field: 0
Would throw an error, because obj/field is protected to the "client" code Ciao -- alberto

 [6/12] from: alberto:origen:mx at: 5-Jul-2006 11:39


Hi Tim,
>> > >> For protected variables see the PROTECT function. > > Hi Ladislav: I've never been able to make protect operate on > a context or a member of a context:
I also notice that, but even if your code worked, then a "method" still would be unable to modify the variable (see my response to Ladislav) ciao -- alberto

 [7/12] from: alberto::origen::com::mx at: 5-Jul-2006 12:08


Hi Gregg,
> REBOL was designed for building small systems, so choices like this > lean towards making things as simple as possible, and may also have > been due to implementation choices.
Good point, that sounds logic for me!.
> In your case, how would private words have helped? Did a word in an > object get reset accidentally?
Exactly!, of course not in a simple way like "object/field: 0", but yes I was modifying some words accidentally. IMO a thrown error would helped a lot. Ah!, to be honest the code isn't very well written, and is much larger of what it would have to be :P Ciao -- alberto

 [8/12] from: cyphre:seznam:cz at: 5-Jul-2006 19:56


Hi Alberto, As Gregg said Rebol was designed for smaller projects so there is not much needs for full featured OOP. But I think such 'protected' feature can be easily replaced by simple rule (which can be applied even inside a group of developers which are working on the same project): -Use specific names for private members. For example: my-obj: context [ p_a: 10 p_b: 20 c: 30 d: 40 .... etc. ] so this way programmer knows what member of object is allowed to change. It all depends on the team/author discipline ;) From my exeprience I've never had problems with errors of this kind in Rebol projects (even though I worked also in strict OOP language based projects) but this is just my 2cents. Maybe there is lot of people who rely on this kind of 'error checking'. regards, Cyphre

 [9/12] from: greggirwin:mindspring at: 5-Jul-2006 12:09


C> -Use specific names for private members. For example: C> my-obj: context [ C> p_a: 10 C> p_b: 20 C> c: 30 C> d: 40 C> .... C> etc. C> ] I've done similar things, using a leading underscore to indicate private variables. This technique can be applied in many ways, and for many reasons, in REBOL. As an example, I use a naming convention for parse rules and their associated variables. -- Gregg

 [10/12] from: cyphre::seznam::cz at: 5-Jul-2006 20:15


Hi Tim, Yes, you are right. The PROTECT functionality has some quirks. It looks PROTECTed words are detected only when using set-word! and SET function:
>> d: context[a: 1] >> protect in d 'a >> set in d 'a 10
** Script Error: Word a is protected, cannot modify ** Near: set in d 'a 10
>> d/a: 10
== 10
>>
Besides set-path! it also doesn't work on series!:
>> b: [1 2 3 4 5]
== [1 2 3 4 5]
>> protect 'b >> b: 10
** Script Error: Word b is protected, cannot modify ** Near: b: 10
>> b/2: 10
== 10
>> b
== [1 10 3 4 5]
>> >> s: "abcd"
== "abcd"
>> protect 's >> s: 5
** Script Error: Word s is protected, cannot modify ** Near: s: 5
>> s/2: #"x"
== #"x"
>> s
== "axcd" I tried to submit it to RAMBO but it seems the system didn't record my submission(don't know the reason?!?) so feel free to try report it. Regards, Cyphre

 [11/12] from: gabriele::colellachiara::com at: 6-Jul-2006 11:05


Hi Gregg, On Wednesday, July 5, 2006, 6:16:09 PM, you wrote: GI> You *can* do it today, but it takes extra effort. I thought I would do GI> it a lot, once I figured out how (with the help of people here), but GI> I've never used it in a production system. The way Gregg is mentioning is just using a "hidden" context for your "protected" words. Example: use [private-field] [ private-field: 2 my-obj: context [ public-field: 1 set-field: func [val] [ private-field: val ] get-field: does [ private-field ] ] ] The disadvantage is that you can't easily clone the object (that wouldn't clone the other context, so that would be shared by all clones), so you need a constructor function. However there is no way for you to change PRIVATE-FIELD by mistake. (Note that there are many ways to achieve this result, so it really depends on what's best in your specific case.) Regards, Gabriele. -- Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/ Colella Chiara software division --- http://www.colellachiara.com/

 [12/12] from: tim-johnsons::web::com at: 6-Jul-2006 13:30


* Gabriele Santilli <gabriele-colellachiara.com> [060706 01:14]:
> Hi Gregg, > On Wednesday, July 5, 2006, 6:16:09 PM, you wrote:
<<quoted lines omitted: 16>>
> ] > ]
This is very 'use'ful to know! FYI: this is like the lisp use of 'let in the "upper level" Greg should put it in the cookbook..
> The disadvantage is that you can't easily clone the object (that > wouldn't clone the other context, so that would be shared by all > clones), so you need a constructor function. However there is no > way for you to change PRIVATE-FIELD by mistake. > (Note that there are many ways to achieve this result, so it > really depends on what's best in your specific case.)
It would be interesting to see other examples. cheers tim -- Tim Johnson <tim-johnsons-web.com> http://www.alaska-internet-solutions.com
Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted