Recent

Author Topic: Generics and form/frame inheritance  (Read 6570 times)

CCRDude

  • Hero Member
  • *****
  • Posts: 596
Generics and form/frame inheritance
« on: October 24, 2018, 12:24:46 pm »
When opening my project (using 1.8 up to 2.1 trunk), I receive error message about frames and forms derived from customized classes. The challenge are generics! The message:

Code: Pascal  [Select][+][-]
  1. Error
  2. Unable  to find the component class "specialize".
  3. It is not registered via RegisterClass and no lfm was found.
  4. It is needed by unit:
  5. ...
  6. [Cancel loading component] [Ignore, use TForm as ancestor]
  7.  

The custom frame inside the unit:

Code: Pascal  [Select][+][-]
  1.   { TFrameSpybot3License }
  2.  
  3.    TFrameSomething = class(specialize TCustomAppFrameworkFullTableFrame<TTableSomething>)
  4.    ...
  5.    end;

The generic used above:

Code: Pascal  [Select][+][-]
  1.    generic TCustomAppFrameworkFullTableFrame<T> = class(TFrame)
  2.    ...
  3.    end;

If TCustomAppFrameworkFullTableFrame would be a simple class, I would create a corresponding lfm and add it.

Obviously, I can't do it with generics, since it thinks "specialize" is the class name!

I think that either:
1. The IDE should be aware of generics (in the context that they can be used for LCL classes).
2. The IDE should at least recognize the class correctly ("TCustomAppFrameworkFullTableFrame" here instead of "specialize") so that a corresponding fake LFM could be created.
3. The IDE should simply not look for LFMs for generics based classes (and continue down the ancestry).
4. The IDE should at least have a parameter to hide these warnings, like {%H-} could be used on unused parameters etc.
5. Or even better than above, one {%AncestorClass TFrame} that could specify the class to use as ancestor instead.

Does anyone have suggestions other than "solve it differently and use standard TFrame"?

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: Generics and form/frame inheritance
« Reply #1 on: October 24, 2018, 12:43:59 pm »
The IDE probably agrees with me there is little use for silly syntax. :D {$mode delphi} helps a little here..
Specialize a type, not a var.

CCRDude

  • Hero Member
  • *****
  • Posts: 596
Re: Generics and form/frame inheritance
« Reply #2 on: October 24, 2018, 02:05:25 pm »
{$MODE Delphi} doesn't change a thing ;) This is an IDE message on loading, not on building.

My personal thing with comments like your first sentence is that it might help you relieve stress to make a joke comment, but it leaves more questions than answers. What do you regard as silly syntax? All generics? Just this use of generics?

Avoiding duplicate code is an important coding paradigm. How to do that is of course a different question. Using generics here avoids
1. that I have to enter duplicate code
2. thereby removing the chance that I make a mistake in one of the duplicates
3. thereby removing the chance that I miss an implementation (specialize) when making changes to the parent (generic) class - which happens in real life ;)
4. keeps the code short and thus easy to understand and maintain
5. once I start connection the functionality backend to the user interface, simple UI code makes it much easier to maintain and really keep separated.

In most cases, everything that takes place happens within the table class now. Then the definition of such a frame is completely without an implementation part in the source code file.

* A helper class to set up the form / frame would mean additional defining and constructing code in each child class.
* An interface would not allow me custom object fields easily.
* not using TFrame/TForm for the final class would mean I would have to give up RAD (I still add a TPopupMenu or some other custom component to a frame sometimes).

Feel free to suggest me a syntax or other method to keep the code that handles a certain frame type in just one place.

I wasn't a fan of generics for a long time, but have learned to overcome my hesitance, understanding that they can avoid repetitive code and bugs arising of writing repetitive code with a bored mind ;)

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Generics and form/frame inheritance
« Reply #3 on: October 24, 2018, 02:39:22 pm »
Thaddy's "silly syntax" remark is aimed at {$mode objfpc}, not so much at generics per se, though of course the difference between the two modes is nowhere more clear than over the syntax differences for generic declarations.
I think to characterise an FPC compiler mode as "silly" is both unhelpful, inaccurate and an affront to the developers who devised and maintain the various modes.
It is fine to ignore objfpc, and not use it, to dislike it or hate it.

It is OK to hold a variety of opinions about the value and use of the various FPC modes.
But to be so utterly dismissive, publicly, of a mode which an FPC developer recently wrote in this forum was his preferred mode (precisely because it offers generic possibilities that Delphi mode does not allow or support) is to my mind unnecessary, and unwarranted.
« Last Edit: October 24, 2018, 02:42:55 pm by howardpc »

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: Generics and form/frame inheritance
« Reply #4 on: October 24, 2018, 03:15:12 pm »
Thaddy's "silly syntax" remark is aimed at {$mode objfpc}, not so much at generics per se, though of course the difference between the two modes is nowhere more clear than over the syntax differences for generic declarations.
I think to characterise an FPC compiler mode as "silly" is both unhelpful, inaccurate and an affront to the developers who devised and maintain the various modes.
It is fine to ignore objfpc, and not use it, to dislike it or hate it.

It is OK to hold a variety of opinions about the value and use of the various FPC modes.
But to be so utterly dismissive, publicly, of a mode which an FPC developer recently wrote in this forum was his preferred mode (precisely because it offers generic possibilities that Delphi mode does not allow or support) is to my mind unnecessary, and unwarranted.
Well indeed. But opinionated should not be taken as an affront. It clearly isn't. Note the Delphi mode also has specific advantages that mode objfpc does not allow. I followed the developments and am well aware what the historic time line is.
Why I call it silly mode is because it is rather verbose where it should not be. Btw I even use it and submit patches written in objfpc generics syntax towards the rtl.All were accepted.

To be on topic: yes, the IDE parser needs work.
« Last Edit: October 24, 2018, 03:17:43 pm by Thaddy »
Specialize a type, not a var.

 

TinyPortal © 2005-2018