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 <edbarx@???> 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 <edbarx@???> 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 <rainerweikusat@???>
> >> wrote: Rainer Weikusat <rainerweikusat@???> 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@???
> >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >>
> >
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng