From: Mark M. <mie...@gm...> - 2007-07-12 17:40:00
|
On 7/12/07, Rony G. Flatscher <Ron...@wu...> wrote: > Hi Mark, > > > I'm getting ready to commit some updates to the ooDialog ListControl > > and thought I'd post an outline of them for comment. > > > But, the methods could be condensed into fewer methods. For instance, Check > > could take a -1 to CheckAll, same for Uncheck. > > > ... cut ... > > If it simplifies understanding and interfacing, then I would suggest to > condense wherever possible. Well one of the things about Rexx that is usually pointed out is that the code reads more like English. So with the condensed (using fewer methods) you would have: listControl~check(-1) As opposed to: listControl~checkAll You could eliminate the uncheck methods by adding an option of true or false, meaning checked or not checked. You could also change the name to setCheck and make the default .true. Then you would have: listControl~setCheck(item) listControl~setCheck(item, .false) listControl~setCheck(-1) listControl~setCheck(-1, .false) As opposed to: listControl~check(item) listControl~uncheck(item) listControl~checkAll listControl~uncheckAll In my mind the second is better. listControl~uncheckAll is easy to understand and easier to remember I think, than: 'I need a -1 if I want all, is the .true required or not, what does .false mean in this case?' > > > > I have added the following notifications. Currently, I have them in a > > separate method. Separate from the existing ConnectListNotify. They > > could be all put in the existing method. > > > ... cut ... > > In general, I think it should be devised such that the "user" (i.e., the > ooRexx programmer) can easily understand, memorize and apply the > functionality. The fewer methods (names) he needs to memorize the > better, Here, I sort of agree that the new notifications could be put into the connectListNotify method. However, the new notifications pass several arguments to the connected methods, that contain specific information. The existing notifications pass some arguments, that are mostly meaningless. When calling the connect method for the new notifications, there are specific error codes returned that can help pinpoint an error in the method call. The existing notifications return a code that is usually meaningless. Having two methods, means that each method behaves in a consistent manner. Whereas putting everything in the same method would mean that: for some of the notifications the method call returns a meaningful return code, for others the return code does not mean anything. For some of the notifications good, usable arguments are passed to the connected methods, for others the supplied arguments have little use. Of course the existing notifications could 'fixed' to be more like the new notifications. Which has the potential of breaking someone's existing code. -- Mark Miesfeld |