Private Object Function

[ value: make integer! 1 [ ; some privatization code ... [ add-one: does [value: value + 1] [ get-value: does [add-one [ print value] [ ]

2

here I should get something like... ** Script Error: Invalid path value: add-one. ** Where: o/add-one Any idea ? Of course the principle could be extended to the privatization of variables... Thx a lot, Best Regards, chr==

[ok, I can also use this]

[yes, it should]

[I do not understand 'serializable' ?]

[yes they should. Although it should be interressant to me to have a mean to control this: some sort of 'protected function' which is known to the ancestor, but not to the child objects...]

[the 'private function' I meant is the opposite of a 'public function'. That is, a private function is a function only known and accessible from within the context of the object. A public one is part of the public interface of the object and is therefore accessible from outside the object, by another object from exemple]

[In the context of the project I'm working on I would like to implement a coherent OODBMS - which I announce in the list sometime ago. For this I need to restrict the access to the object's internal implementation. I should be able to determine which methods can be accessed from the outside, which not, which should be inherited or not. The solution should also be applicable for protecting object's properties. Regards, chr==]

[thanks for answering ! it works fine to me, but it does not simplify and clarify the writing of the code, in that way that the body of the 'public function' must be found back into the 'private' part, due to the runtime binding... Anyway, it's my best solution for now ;-) best regards, chr== ]

By "serializable" I mean that: If I have the object (including its private components) loaded in memory, should I be able to write the object including its private components to a file? Or is it sufficient if I only write the public components of the object to a file? I.e. o: make object! [something: none] write %filename.ext mold o will write this object to a file. If I add private components to this object, and I want to write the object to a file, should the private components be written along with the object? Or should the object be written without the private components, which means that when the object is subsequently loaded from this file, it will not include the private components.

Is this "protected" function in addition to the private function? If not, then I don't see how descendants can access the hidden function, if this hidden function is not known to descendants.

Basically, my question is, to what degree do you want to enforce this? Is it a) more an organizational principle to help you as a programmer organize your code; b) you don't want the private functions/words to show up in the block returned by first object, but if a non-member function absolutely wants to, then it will will be able to also access hidden words ... c) Under no circumstances must a non-member function be able to access private components? That's, basically what I'm asking Take Care, Elan

I just checked my REBOL folder, and I don't appear to have that one. Could you send me the email you are referring to offlist? It may help me understand where you are heading with this. If it's to be an OODBMS then my guess is that you won't be served with a solution that prevents you from storing the private components of an object together with the object? Take Care, Elan

[thanks, I didn't know this one. I used 'save to keep the object structure intact...]

[In the specific context of my try for OODBMS development, the persistence of the DBobject should indeed request to be written down INCLUDING the private methods, because those should contain some business intelligence needed to access/handle the contained data]

[you're right ! methods would be classified in three exclusives classes: public, private and protected Sample use of them could be: - public access : the method can be called from any script in the application. - private access : the method can be called only from scripts in the object for which the function was declared (including the sub-objects); the method cannot be called from descendant of the object. - protected access : the method can be called only from scripts for the object for which the function was declared, and its descendant. !!! ATTENTION !!! After studying some more documentation I collected, I've noticed that I interverted the meaning of the concept 'private' and 'protected' : that's why the definitions above doesn't mach anymore what I previously said. Sorry for the inconvenient. ]

[as I see the implementation for now, my meaning of it is to enforce the protection of the object's contain by keeping the protected/private part out-of-bound for the context from which the object is called. That is, using your words, your point c). Creating highly encapsulated objects organize for sure the code, but more important allows you to completely control any modification and access to properties and methods, which is important in the process of creating waterproof applications... ]

[I hope you'll find my answers satisfying.]

[Thank you for caring ;-)) ]

[ Best regards, chr== ]

[it was just my answer to a question of Mr. Gabriele Santilli, where he ask if anyone was interrested in building a DB system. I just mentionned my interess foran OODBMS ]

[right again ! for further details, please refer to my answer to your other mail of today]

[U2 :-) ]

[best regards, chr== ]

[I already read it. Great book. it taught me REBOL...]

[IMHO those are just general conventions within OO analysis and development. For sure I didn't find them out !]

[Do you mean by this it shouldn't be possible to implement it in REBOL ?]

[It's the way I already followed. I will couple this approach with subobject or 'use for enforcing privacy.]

[the meaning of all this is to protect code from accidental use, not to enforce paranoia ! So I think your approach is all OK ...]

[Thanks a lot for your good advises ! BTW is there anybody interested by the results I will get ? I do not want to spam the list with uninteresting stuff... Best Regards, chr== ]

to spam the list with uninteresting stuff... I'm interested. Andrew Martin Oo Look Rebool... ICQ: 26227169 http://members.nbci.com/AndrewMartin/

No, I mean that using REBOL's default inheritance mechanism, i.e.

p will have inherited foo as a functions that successfully calls bar just like o does. This leads to the following situation. Given:

foo: none set-bar: none make object! [ bar: none set 'foo does [bar] set 'set-bar func [value] [ bar: value ] ] ]

o/foo "I was set by o."

p/foo "I was set by o."

o/foo "I was set by p."

p/foo "I was set by p." Note that - unlike your requirements for private values - p and o share o's private value bar. REBOL's inheritance mechanism acts in a protected way with respect to children's access to hidden object properties. This means that you should really implement your own custom object mechanism, let's call it class mechanism to separate it from REBOL's objects, which may be built on top of objects. class!: make object! [ private: none published: none public: none ] some-class: class class! [ private [ pa: none pb: none ] published [ ua: none ub: none ] public [ la: none lb: none ] ] class: func [ spec [block!] /local new-class] [ set [_ private-block _ published-block _ public-block] spec return make object! [ private: make object! private-block published: make object! published-block public: make object! public-block ] ] some-child: clone some-class clone: func [parent [object!] /local result] [ ; has to be written. I don't have the time right now. ; what takes a little more time is that you must account ; for possible complex structures such as classes embedded ;in a class, or blocks of objects/classes embedded ... ; If nothing useful pops up on the mailing list perhaps I'll implement something this evening ]

Well, as you've guessed by now, I'd even be interested in contributing some code. I think it'd be an interesting ongoing public project. Take Care, Elan

You want strictly enforced privacy, and you want the ability to save objects including their private componenets. From the point of view of privacy enforcement REBOL's built-in storage functions (write, save) are non-members that are prohibited from accessing the private components. If they are prevented from accessing the private components, how should they be able to save these private components, unless they are used from within member functions? The OODBMSs I am aware of use two strategies to save objects: a) Each object includes serialization functions used to store the object. Since the serialization functions are members of the object, they do have access to private object conponents. This can be implemented in REBOL. b) The OODBMS uses runtime system information (RTTI) to invade the privacy of the object and automatically determine the components and component types of an object. This can also be implemented in REBOL.

You appear to follow the Object Pascal (Delphi) conventions.

This is supported in REBOL using paths, or GETting a value IN an object (i.e. get in object 'word).

Hidden objects or contexts are not protected from descendants. 

Hidden objects or contexts are exposed to descendants.

See what I wrote above. If you enforce c) then you cannot use REBOL's default functions for saving an object from outside of the object. The serialization functions included IN objects can - of course - make use of write and save. Example:

e: none save-me: func [filename] [write/append filename mold self] make object! [ h: does [print "I'm hidden."] set 'e does [h] append second save-me [write/append mold self] ] ]

make object! [ e: func [] [h] save-me: func [filename][write/append filename mold self write/append filename mold self] ] save-me looks like its saving self twice. These are two different selfs. The first self is bound in the context of the public object, the second self is bound int the object used to hide the h function. I.e. the second self evaluates to the "hidden" object. We can see that by retrieving the body of the save-me function: get second in o 'save-me, and then getting and displaying the two self words, using get second ... and get fourth ... respectively, to get the value associated with the second word (self), and the fourth word (self) in the block:

make object! [ e: func [][h] save-me: func [filename][write/append filename mold self write/append filename mold self] ]

make object! [ h: func [][print "I'm hidden."] ] Note that - as demonstrated - it is possible to get at the hidden stuff, if you go out of your way to do so. The solution IMHO is to implement your own objects and supporting function in which you enforce private/protected/public rules. As long as your code does not use REBOL's built-in functions to violate these rules, you're fine, provided you don't mind the extra overhead. Take Care, Elan

[Thanks, Elan, for this contribution. I will try to publish on a regular base the results I get. I will try to find a way to bypass the standard REBOL inheritence mechanism so I can implement private functions. BTW, I went to your site this sunday. Great look ! I like the letter type you use ;-) Kind Regards, chr== ]