On 11 September 2010 16:23, Seth Hetu <[email protected]> wrote: >>> menuitem.caption >>> instead of >>> get menu item caption (menuitem) >>> >>> heroes[who].stats[stat.hp] += x >>> instead of >>> set hero stat(who, stat:hp, get hero stat(who, stat:hp) + x) >>> and so on. >> >> *James falls on the floor and twitches with joy* > > > Definitely this. It can even function just as syntactic sugar, > translating "menuitem.caption" to "get menu item caption (menuitem)"; > that alone would be much more self-documenting. > > Since you are approaching object-oriented programming a little bit, > what about accessing methods this way? Like: > heroes[who].moveTo(x, y) > > It seems like Ralph implied this in his comments, but the examples > given were just for data (not methods). Where you planning on > extending this to methods too? > > -->Seth
Methods on built-in types aren't necessary, but why not. I suppose that when documenting built-in objects, for each property we describe what it means, and any special effects of modifying it and dependence on other properties. When documenting methods, we would just say what function it is equivalent to, and link to that. I doubt we'd stop adding functions/scripts equivalent to new methods. However, I'm not sure we should add methods equivalent to every function that acts on that type of object due to duplication. For example, clearly you'd be able to set the X and Y coordinates of a slice by setting the .x and .y properties (which would map to 'set slice x' and 'set slice y'), but then do we need a .put(x, y) method (mapping to 'put slice')? (However (when we add automatic slice movement) .move(x, y, speed) (probably) isn't equivalent to changing some properties.) _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
