Object Oriented Learning of Prima
Object orientation is a great benefit for programming but also a key for learning.
Prima offers a very large set of objects to the needs of development. As the human brain can group together a quite limited number of objects (four to seven depending on individuals), having a large number of objects can make the whole stuff unmanageable. That is the reason that makes our brain starting with one topic, then a first level of some different groups of things, and then puts at the bottom of each one, the objects that can be a kind of that. This is the way we can manage large sets of objects, buy putting them in a hierarchy. This way the mind works inspired the pyramid principle by B. Minto, as a way to produce documents while validating the ideas.
So, to get off of the numerosity that affects Prima as any other real world tool, we have to depict what type of objects we have, at first.
Prima deals with graphics, so the first decomposition is about the objects that are concerned in the process of building a Prima application:
- Windows are the main objects we deal in Prima, the ones we expect to see starting an application;
- Menus are used to give the user the ability to use the application in some useful way, putting the application functionalities available to the user;
- Widgets add many ways for the user to interact with the application and for the developer to give back results to the user. Examples of widgets are the already seen combo box, the scroll bar, a button;
- Standard dialogs are used to perform some common tasks as opening a file, o putting a message on the screen. In this sense they implement a single functionality, generally using under the hood, more than a single widget.
- Images and shapes also play an important role in Prima; A part of Prima deals with image loading and management and with direct production of drawing.
I would remark again that menus are a separate concept and that what is seen on screen is combination of a window and a menu.
Coming back to our pyramid, in Prima there are about 30 widgets and 10 standard dialogs, but actually that doesn't matter, knowing the common way they are used in an application as widgets or standard dialogs. We would only further expect some specific parameter or event coming naturally from the specific function of the particular standard dialog or widget.
A blog about Perl and Prima.
I would write about Perl and Prima the way I would like to read about them.
Judging by the title, I thought that you were going to talk about something different. As you did not, I will. :-)
Prima has a novel object model implemented in C. You specify a class in a stand-alone source file (typically with a .cls extension) and then run gencls on your specification. gencls generates the C code that includes vtable management and appropriate Perl hooks, even allowing Perl-level subclassing that is easily accessible at the C level. If I were to ever rewrite PDL, I would use Prima's C-based object system as my starting point.
At a higher level, lots of Prima object interaction occurs through callbacks, and you can associate multiple callbacks with a single event. It's almost like Moose's before or after blocks, except that it's per-object instead of per-class.
In all, it boils down to an extraordinarily solid object foundation upon which is built a flexible and powerful gui toolkit.
Hi,
thanks for your comment. The aim of this posts is to simplify the adoption of Prima. With this spirit I am trying to depict concepts that I found for myself relevant to step forward. I generally need concepts first and details later.
Internals are probably not the best way to start; it is different if you are already where I would be.
Thanks
Fabio D'Alfonso
I would add some think after the previous comment.
It is a common issue that any toolkit as Prima or PDL, where no effort was made by some publisher to make some publishable stuff, there are two different kinds of actors:
- developers that already know all about the toolkit and are concerned with internals and upfront problems.
- users that need to start, generally have only reference material, but no path to navigate.
As it is natural for developers not needing what a user would need, the effort to make a resource adoptable by users is a completely different task.
That is what a publisher numerous staff make is directing the writing of a book, and where the value of the result is.
Meanwhile, I am just trying to writing something roughly going in this second category.
Fabio -
Of course! Your post is absolutely correct in its approach. My comment is merely a footnote for the interested reader. Please, keep up these beginner-targeted posts!