I'd start out by saying that, in my opinion, OOP isn't the right paradigm for every situation.
If you're talking about a picklist, where you display the picklist and the user picks the desired item, then I think OOP is a pretty good paradigm because it matches the data. In this case, the picklist object has either an array of item objects or a doubly linked list of item objects, as well as some metadata and a few methods (probably implemented as contained pointers to functions.) If you want the picklist sortable, the list must have a sort method. You might also want to have a text trimming method so the text doesn't walk off the end of the screen (a problem with CLI and Curses). The picklist must also have properties relating keystrokes to functionalities, the functionalities being "Choose", "Cancel", "Drill down", "Change", "Delete", "Add". Not all functionalities are necessary on every list. An item object contains the original data, a string representation suitable for display, a unique identifier, and a distinct way to pass back the unique ID of the chosen item. For instance, in some situations you'd just return the unique identifier, in other situations you'd want to print the to stdout. The conversion of the original item to a display string is a pointer to a function taking a void pointer as an argument, and returning a string, because the original data can be in any conceivable form. I'd *highly* suggest you do not have any user interface information within either the picklist class or the item class, for the same reason you don't like systemd. Your software becomes a lot less pure and easy to repair if you mix heavy lifting like the picklist with other, unrelated heavy lifting like user interface. If the picklist and item classes know nothing about the user interface, then you can use them with *any* user interface. Of course, you'll eventually need the user to interact with your picklist via a user interface. There are probably a million ways of doing this. One way might be via two callback routines called acquire() and display(), where acquire() acquires a piece of user input, and display() displays a piece of output. Given the fact that picklist and item should know nothing about the user interface, and the fact that C makes you completely declare all types, these two callback functions need to be declared pretty creatively to cover all scenarios. HTH, SteveT Steve Litt November 2015 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques On Mon, 23 Nov 2015 07:42:17 +0100 Edward Bartolo <edb...@gmail.com> wrote: > Hi Aitor et al, > > Thinking a little bit about C, and recalling what Reiner explained > earlier, I should think, we can create our own C library to handle > lists as in classes without actually importing more dependencies: for > that we use a struct that has function members, just like a class. Our > implementation shouldn't require class inheritance, so simple > structures should suffice. > > What do you think? > > Edward > > On 23/11/2015, Edward Bartolo <edb...@gmail.com> wrote: > >> Have you a preference for using c++ in netman? > > > > The frontend is a complex piece of software using lists. Some parts > > were complicated to code even in Lazarus Pascal: imagine the > > complexity required to achieve the same thing in C. > > > > Edward > > > >> On 22/11/2015, Rainer Weikusat <rainerweiku...@virginmedia.com> > >> wrote: Rainer Weikusat <rainerweiku...@virginmedia.com> writes: > >> > >> [...] > >> > >>> This mechanism as certain tendency make C++ developers go bezerk > >>> with a particular type of strong rage, but it's entirely usuable > >>> in practice, although more work than having it all laid out for > >>> oneself. > >> > >> In the interest of fairness: This 'more work' of course translates > >> to 'more opportunities for getting stuff wrong' and there's the > >> additional problem of "get away with it"-ism, especially in closed > >> source software: At least some people will - either based on > >> principle[*] or because it saves them work or they at least > >> believe it will - break every 'softly imposed' rule the believe to > >> be able to get away with breaking. Hence, unless the language/ > >> compiler enforces access restrictions to supposed-to-be > >> internal-use only members of a data structure, people will ignore > >> them. > >> > >> [*] I've actually encountered people who refused to comply with > >> technical documentation on the ground that they aren't taking > >> orders from strangers ... > >> _______________________________________________ > >> Dng mailing list > >> Dng@lists.dyne.org > >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > >> > > > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng