...and you want me to put together a full-fledged error-free tool that generates clean modular reusable code with no variable collisons
No
It was really just a question.
Aruna, are you planning to extend the class skeleton generator?
I changed my mind, yes that is the plan now, to extend slowly as and when I fully understand things.
Let me ask out of curiosity why you changed your mind?
It will be a very slow process.
Definitely (mainly because of the need to perform a lot of different tests, but not only).
For example, with:
- field declaration section (private, protected),
- method declaration section (private, protected, public),
- property declaration section (protected, public, published),
- properties associated with fields in the class,
- fields (and associated with them properties) handling events (e.g. OnClick: TNotifyEvent),
- accessors for fields (GetX, SetX) and where to declare them (private, protected),
- indicating that the property being added is read-only,
- indicating that the read-only property being added has an accessor method (GetX),
- indicating that the method being added is overloaded,
- indicating that the method being added is virtual,
- indicating that the method being added is overrided.
Of course, this does not exhaust the needs of generating a class template.
VisualLab, would you please give me some more of the above which you feel are relevant or point me towards documentation a simple mind like mine can understand, please. And if you were me how would you go about doing this in the first place? IS what I have done a good start or ??
What I listed, I wrote from memory (i.e. basic elements of classes, of course not every class has to have all of them). As for documentation, when I was learning Object Pascal I used Delphi manuals. And I still do, but now I just supplement my knowledge with new elements. And I check the difference between what the FPC compiler (lazarus) supports (or doesn't support) and what the DCC compiler (Delphi) supports. I think a good manual to start with would be the one written by Marco Cantu "
Delphi Object Pascal Handbook". Details about classes are described on pages: 202 - 352. Unfortunately, the manual requires registration.
And if you were me how would you go about doing this in the first place? IS what I have done a good start or ??
Hmm, I can only write how I would do it (everyone probably has a slightly different approach when implementing a project). But just quickly...
In any case, I would take as a basis the guidelines that I have already mentioned (and these are only the basic elements of classes, because there are more of them). I would start by designing a GUI for a class skeleton generator. It should have extensive class skeleton configuration options and at the same time be easy to use. And this is where the difficulty lies, because these are contradictory requirements. Large configuration possibilities require an extensive GUI, which is usually not easy to use. When configuring the class skeleton, certain components should be blocked/inactive (or not displayed at all), because they can be mutually exclusive.
To start with, I would make the prototype as a separate program and avoid dialog boxes (they require too much clicking). The first versions of such a project would certainly be very temporary and the GUI would probably change significantly from version to version. What's more, I am afraid that the first few versions of the prototype would have to be devoted to testing several different concepts in order to check their ergonomics (which one is the most useful or the least inconvenient to use).
At the moment I don't have a clear idea of what the generator workspace (GUI) would look like. It would probably be a collection of controls placed in 2 columns. In the first column there would be labels. In the second there would be edit fields, drop-down lists (combo-boxes), view lists, check-boxes, etc.
The generator program created in this way would produce the class skeleton code. A preview of this code could be placed in a multi-line edit field (e.g. TMemo or better in TSynEdit associated with TSynFreePascalSyn). Then this class skeleton code would have to be tested in Lazarus. If it worked without errors, then we could start thinking about how to link it to Lazarus, that is, how to pass code from the class skeleton generator to the source code editor in Lazarus (here you would have to look into the Lazarus sources, which can be very time-consuming).
EDIT (13-09-2024): I forgot the most important thing – you need a data container (e.g. TClassSkeleton) that will:
- store the skeleton structure of the class (not the source code!),
- make the components available for editing,
- allow you to save the skeleton of the class from the container to a file (e.g. XML),
- allow you to load the skeleton of the class from a file to the container,
- be used to generate the source code of the class.
To do this, you would need to design sub-containers contained in the main container. Each sub-container would store some part of the skeleton of the class: a field, a method, a property, an event, a constructor, a destructor.
It would probably be advisable to also design a controller and views (dividing tasks between components based on the MVC pattern). Views would allow the content of the class skeleton elements to be made available for editing and viewing.
One of the views would be an editor of the class skeleton elements. It could be prepared as a platform (e.g. TGroupBox) on which there would be controls such as edit fields, drop-down lists, switches, buttons, etc. along with appropriate labels.
Another view could be in a tabular form (e.g. TListView set as a report). This list could display content retrieved from subcontainers. Selecting an item on the list would cause the content of such a subcontainer to be displayed in the editor controls. Buttons would also be needed to allow adding new elements of the class skeleton.
Perhaps it would also be necessary to prepare a source code generator. The generator would provide the source code to a preview control (e.g. TSynEdit), which would act as one of the views.
The controller would coordinate the whole operation, e.g. after committing changes in the editor it would force a refresh of content in the views: (1) the table of class elements and (2) the source code preview. The controller could be notified about the state of the container or views using events originating from them.
Recent
