[REBOL] objects: overhead, private data, naming conventions
From: greggirwin::starband::net at: 18-Sep-2001 11:27
Hi All,
I know it's often futile to ask for consensus among developers so consider
this a "solicitation for opinions". :)
For the sake of discussion, let's use something simple like rgb-color. In a
small app, dealing directly with tuples is manageable. Coming from a world
where projects are sometimes large, I'm accustomed to using as much
abstraction as possible to ease long term maintenance. This would mean
creating an rgb-color class. Like everything else in life and software
development, there's not always a black and white answer. 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.
I guess a valid stance with REBOL could also be "You don't need to build
large applications. You can build small, manageable, apps and avoid 90% of
the overhead a large system requires (as exemplified by the IOS model). Has
anyone built any large systems with REBOL that can speak about the pros and
cons?
OK, on to the object-related questions.
Overhead:
Objects in REBOL get a copy of the entire spec block for that object,
correct? So, if I have 100,000 pixels to deal with, I probably don't want to
create an rgb-color object for each of them. I would either just deal with
them as tuples or, perhaps, write functions to access each part of the tuple
with a human-friendly name rather than the index in the tuple. E.g.
rgb: context [
red?: func [value[tuple!]][value/1]
green?: func [value[tuple!]][value/2]
blue?: func [value[tuple!]][value/3]
red: func [value[tuple!] new-value[integer!]][
value/1: new-value
return value
]
green: func [value[tuple!] new-value[integer!]][
value/2: new-value
return value
]
blue: func [value[tuple!] new-value[integer!]][
value/3: new-value
return value
]
]
If this line of thinking is completely whacked, let me know.
Private Data:
There doesn't seem to be any way to create private members in objects. Am I
missing something or is this not considered an issue? If there are members
that an object relies on, in order to be in a valid state for example, you
don't want people messing with them and breaking the object. I'm guessing
the solution to this is to use protect and unprotect. Has anyone done
anything like this? Am I being too paranoid? :)
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. For example:
rgb-color: context [
_val: 0.0.0
get-red: does [_val/1]
get-green: does [_val/2]
get-blue: does [_val/3]
get-value: does [_val]
set-red: func [new-value[integer!]][_val/1: new-value]
set-green: func [new-value[integer!]][_val/2: new-value]
set-blue: func [new-value[integer!]][_val/3: new-value]
set-value: func [new-value[tuple!]] [_val: new-value]
]
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]
]
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?
Thanks for any comments! ...and sorry for the lengthy message.
--Gregg
