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

[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