[REBOL] Re: objects: overhead, private data, naming conventions
From: chrismorency:videotron:ca at: 18-Sep-2001 21:15
Hi,
<part of solicitation snipped, see original message>
> If I asked "Should I use objects?", the answer would probably be
> "sometimes". There will be times when I don't need them and times
> when I do. I just need to figure out what my own rules are about
> when to use them. If anyone else has guidelines that they use,
> I'd love to hear what they are.
This is part of what I like with Rebol, you can do procedural, "objectual"
or contextual programming. I personnally prefer to do OOP because I work
with OOP daily, however this is your choice ! It all depends on your need
and how you prefer to accomplish the task. I see programming language like a
methodology, you can have a lot of ways to do something, some are good some
are bad, some are better than others but doesn't mean they're the fastest,
easiest... I think programming from a human point of view is not an exact
science.
Your question reminds me of a discussion I had with a friend earlier this
week about OOP. This is farfetched, but given all the time, all the
ressources (human and material) and comprehension (human) about a model,
let's say the universe, your could code it in OOP.
I see contexts as a way to communicate with a computer from a human and
social POV. Now, even though a model is developped in OOP for the computer,
the interaction is done through communication with context. Now this is
where I think Rebol excels. Now I can be wrong, During the week-end I read
some articles with Carl Sassenrath, and I read one from the late 90's where
he indicated his view on OOP, these can be interesting for people interested
in going pure-rebol.
> Overhead:
>
> Objects in REBOL get a copy of the entire spec block for that object,
> correct?
True, the way object! is implemented currently in Rebol, you may end with a
lot of overhead and memory consumption. I'm currently working on a personal
re-implementation of inheritance under Rebol including using Classes and
Objects, part of which is coded and other in my mind... I was sitting at my
computer to write a document on it actually so I don't loose any idea...
while writing this email ;-)
> Private Data:
> There doesn't seem to be any way to create private members in
> objects. <snip> I'm guessing the solution to this is to use
> protect and unprotect. Has anyone done anything like this?
> Am I being too paranoid? :)
Some OOP programming language enforce the idea of public and private (C++,
Java?, VB), however some don't (SmallTalk (VA atleast), Rebol..) I
understand the reasons why you would like to protect things, however the
later languages adopt another POV which basically say : let the programmer
know how to code, enforce it's methods and do the right thing, which offers
you some freedom...
> Does anyone bother to use accessor functions for data members or is the
> general practice, as it appears, to just declare members as public?
> Naming Conventions:
> Many languages use the set/get prefix on accessor method names.
I usually do, even under Rebol, I use the prv- prefix for private word, set-
prefix for setters, val- for validations and no prefix for getters : for
example :
person: make object! [
prv-name: ""
set-name: func [a-name] [self prv-name: a-name]
name: func [] [return (self prv-name)]
]
person/set-name "John Doe"
print person/name
I personnally like the way it look + it simplify a lot of coding for the
getter ;-)
Regarding self, notice the way the person object is implemented above, which
seems to be the standard way to refer to self in Rebol in the majority of
scripts...
I personnally prefer the following, which remains true to how object and
methods are accessed in rebol... also it permits the developer to remove a
lot of parenthesis when doing OOP and returning value for getters.
person: make object! [
prv-name: ""
set-name: func [a-name] [self/prv-name: a-name]
name: func [] [return self/prv-name]
]
(notice also that I have removed the type validation in the function, which
at first may seem stupid, but I prefer to consider everything as an object
like in some other language and manually validate my input through declared
validation function... now all my methods usually returns something, or true
of false to indicate success or not... (especially for setters).
> I think REBOL gives us a better option, but I'd like to hear what others
> think about the following:
>
> rgb-color: context [
> _val: 0.0.0
> red?: does [_val/1]
> green?: does [_val/2]
> blue?: does [_val/3]
> value?: does [_val]
> red: func [new-value[integer!]][_val/1: new-value]
> green: func [new-value[integer!]][_val/2: new-value]
> blue: func [new-value[integer!]][_val/3: new-value]
> value: func [new-value[tuple!]] [_val: new-value]
> ]
Usually the methods or functions with ? at their end in standard rebol seems
to indicate a type-verification or validation of some-sort... and "does"
will translate to func with objects... I haven't tried with context though.
Here is how I would have done it... notice that the code is unfortunately
not as simple as yours, but however demonstrate local validation of type
without enforcing type in the func declaration, this is to illiminate error
;-) and use true or false for success... the set- red green blue methods
could have use a generic set- method that would have included a value to
indicate the tuple position etc ;)
rgb-color: make object! [
prv-rgb-color: 0.0.0
val-rgb-color?: func [a-rgb-color] [return tuple? a-rgb-color]
set-rgb-color: func [a-rgb-color] [
return either (self/val-rgb-color? a-rgb-color) [
self/prv-rgb-color: a-rgb-color
true
] [
false
]
]
rgb-color: func [] [return self/prv-rgb-color]
set-red: func [a-color] [
return either (self/val-color? a-color) [
self/prv-rgb-color/1: a-color
true
] [
false
]
]
set-green: func [a-color] [
return either (self/val-color? a-color) [
self/prv-rgb-color/2: a-color
true
] [
false
]
]
set-blue: func [a-color] [
return either (self/val-color? a-color) [
self/prv-rgb-color/3: a-color
true
] [
false
]
]
val-color?: func [a-color] [
return either (integer? a-color)
[
either ((a-color >= 0) and (a-color <= 255)) [
true
] [
false
]
] [
false
]
]
red: func [] [return self/prv-rgb-color/1]
green: func [] [return self/prv-rgb-color/2]
blue: func [] [return self/prv-rgb-color/3]
]
> In the above code _val is considered a private data member, identified as
> such by the leading underscore. Is this an acceptable convention
> or is there another one in use that I should consider?
I personnally prefer prv-... but _ seems to be becomming popular and I might
adopt it myself...
> Thanks for any comments! ...and sorry for the lengthy message.
Hope mine have been appreciated, however I maintain this how I do it, which
does not seem to be the current standard popular way objects are
implemented... or the best way to do it ;-)
Best,
Chris
