Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Private/Public attributes

 [1/10] from: mlo::info::fundp::ac::be at: 15-Nov-2002 14:13


Hello the ML, I want to know if the concepts of private and public are implemented in Rebol? Thanx Miguel

 [2/10] from: joel:neely:fedex at: 15-Nov-2002 10:04


Hi, Miguel, No, AFAICT. An object's context/namespace is easily accessed from outside. (Likewise for locals of functions, if you push the point.) If you like, you can think of this as a virtue, as it supports introspection/reflection (or whatever other buzzword you prefer), which allows an evaluation in process to e.g. inquire about, and change behavior depending on, the composition of objects being used within the computation. Incidentally, I recently read a remark by someone who saw the following in a header file... #define private public ...for a language whose identity you can guess! ;-) -jn- Miguel Lopez wrote:
> Hello the ML, > I want to know if the concepts of private and public are
<<quoted lines omitted: 5>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446

 [3/10] from: greggirwin:mindspring at: 15-Nov-2002 10:26


Hi Miguel, ML> I want to know if the concepts of private and public are implemented in ML> Rebol? Not really; at least not in a way you might expect. As with most things in REBOL, you can find a way though. :) You can define a USE block in an object to create a private area of sorts. o: make object! [ a: 0 b: 1 fn-1: fn-2: none use [c d] [ c: "xyz" fn-1: does [print c] fn-2: does [a: 2 d: 4] ] ] -- Gregg

 [4/10] from: ingo:2b1 at: 15-Nov-2002 23:02


Gregg Irwin wrote:
> Hi Miguel, > > ML> I want to know if the concepts of private and public are > implemented in > ML> Rebol? > > Not really; at least not in a way you might expect. As with most > things in REBOL, you can find a way though.
And as most things, you can find more than one way ... o: make object! [ ; public goes here self: make object! [ set: func [val][ private_val: val ] get: func [][ private_val ] ] ; private goes here private_val: none ]
>> probe o
make object! [ set: func [val][ private_val: val ] get: func [][ private_val ] ]
>> o/private_val
** Script Error: Invalid path value: private_val ** Near: o/private_val
>> o/self/private_val
** Script Error: Invalid path value: private_val ** Near: o/self/private_val
>> o/get
== none
>> o/set 3
== 3
>> o/get
== 3 'self is normally a pointer to the object! itself, so by setting it to some other value, the object! does not point to itself anymore - or something like that. I don't know, if there may be some problems with the garbage collector, though. Kind regards, Ingo

 [5/10] from: joel:neely:fedex at: 15-Nov-2002 16:28


Hi, Ingo, As I said... where there's a "won't" there's a "will"! See below! Ingo Hohmann wrote:
> And as most things, you can find more than one way ... > o: make object! [
<<quoted lines omitted: 31>>
> >> o/get > == 3
Now follow the above transcript with this:
>> set first second get in o 'get 7
== 7
>> o/get
== 7 ... to see that "private" really is still meaningless (although perhaps "obscure" applies! ;-) -jn- -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446

 [6/10] from: jan:skibinski:sympatico:ca at: 15-Nov-2002 23:51


Hi, This is probably too far off topic, but since Joel said <<where there's a "won't" there's a "will"! >>, I'd like to share this bit about information hiding. The only concept I know of that provides theoretical support for true privacy is ADT (Abstract Data Type) and a related to it existential quantification. Existentially quantified types were first described by Mitchell & Plotkin. There are some good papers by Luca Cardelli explaining the basic idea. In essence, objects described by abstract data types display some abstract behaviour that is independent of the representation type. Users should not be allowed to break the abstraction via the abstract data type interface. Once an abstract object is made, its representation type can never be rediscovered. There are many existential types that are too general to be useful. The only useful kind of existential objects are those packaged as pairs (cartesian products) made of an unknown value and a function from that value to something specific, such as integer. The corresponding signature of such an object 'x would be something like this: x :: Exists. a (a, a -> integer) which loosely means "The object 'x is a pair made of a value of unknown type 'a, and of a function from type 'a to integer". The type 'a is not universal - as it would be the case with FORALL 'a quantification, the above only means that there EXISTS SOME type a' taken from a universe supported by a language under consideration. We do not know what this type is, and we do not know how to discover the real structure of this packed object 'x (is it a tree, or an array or a stack?). But we can take advantage of its cartesian type to calculate the value of the integer, by applying the second part of 'x to the first one: second x first x == 43, say A programmer packaging such an object knew exactly what the first element was, say integer 5. But once packaged, its value remains a secret for the receiving party. Existential types have been introduced to Haskell quite recently, as one of the extensions. I played with them a bit and they seem quite convenient for certain kind of applications. Functional languages Clean and Caml and the functional-logical language Mercury also support existential types. Regards, Jan

 [7/10] from: reffy:ulrich at: 16-Nov-2002 8:32


A programmer packaging such an object knew exactly what the first element was, say integer 5. But once packaged, its value remains a secret for the receiving party. NOW, I can identify with this .. Dick

 [8/10] from: joel:neely:fedex at: 16-Nov-2002 18:28


Hi, Jan, and all, First, Jan, thanks for the thought-provoking posts! Much to ponder in your notes! (OBTW, off-topic, is there some reason you chose -+ instead of -> in your type analysis routines? Just curious...) Now on with my actual reply ;-) Jan Skibinski wrote:
...
> In essence, objects described by abstract data types > display some abstract behaviour that is independent > of the representation type. > > Users should not be allowed to break the abstraction via the > abstract data type interface. Once an abstract object is made, > its representation type can never be rediscovered. >
This sounds like an interesting direction for more work, but I must say I'm sympathetic toward Joel Spolsky's (no relation ;-) Law of Leak Abstractions http://www.joelonsoftware.com/articles/LeakyAbstractions.html which seems to be true for most languages and systems of which I'm aware (including REBOL, apropos the public/private discussion). -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [9/10] from: carl:cybercraft at: 17-Nov-2002 16:07


On 17-Nov-02, Joel Neely wrote:
> This sounds like an interesting direction for more work, but I > must say I'm sympathetic toward Joel Spolsky's (no relation ;-) > Law of Leak Abstractions > http://www.joelonsoftware.com/articles/LeakyAbstractions.html
Thankyou Joel. It gave me something to read in the spare moments this Windows/Linux install-loop I'm in allows me. (: -- Carl Read

 [10/10] from: jan:skibinski:sympatico:ca at: 16-Nov-2002 22:44


Hi Joel,
> First, Jan, thanks for the thought-provoking posts! Much to ponder > in your notes!
There is much more about it + included example with discussion in my Haskell Companion - ref: Wayback Machine.
> (OBTW, off-topic, is there some reason you chose -+ instead of -> > in your type analysis routines? Just curious...)
As I already explained, this is a poor man imitation of -> due to Rebol's resistance to accept it. Gabriele suggested using the Issue #-->.
> This sounds like an interesting direction for more work, but I > must say I'm sympathetic toward Joel Spolsky's (no relation ;-) > > Law of Leak Abstractions > > http://www.joelonsoftware.com/articles/LeakyAbstractions.html > > which seems to be true for most languages and systems of which I'm > aware (including REBOL, apropos the public/private discussion). >
No doubt about it. The weakest link problems! But the existential quantification stuff has nothing to do with real life failures that Spolsky concentrates on. EQ computing model fits extremelly well to the Haskell computing model: everything is safe as long as you stick to purely functional part of it (an provided that you are careful to bail out on overflows). Anything IO related is potentially dirty. Reading from disk, creating random numbers*, checking the clock - none of this can be passed to pure functions. But IO functions, including the Main, can call pure functions as often as they want to. Regards, Jan (*) Yes, yes - a call to a random number generator is not considered referentially transparent, because pure functions suppose to return the same results anytime you call them with the same arguments.

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted