Do Clarion Interfaces use Virtual, Proc, Name, Extends & Final?

RchdR · August 2, 2026, 12:56am

Havent tested with the compiler or IDE yet, but to save me a bit of work I’ll ask the question.

Do Clarion Interfaces support Virtual, Proc, Name, Extends & Final?

I can find anything in the help docs so I’m assuming they dont, but wanted to check first.

Screenshot also shows #Context pulling the #Procedure InterfaceMethod #Embed’s into the #Procedure: Interface edit source.

This makes its possible to edit embed code for multiple different #Procedure’s at the same time!

I think thats a nice touch.

Bruce · August 2, 2026, 4:34am

Do Clarion Interfaces support Virtual, Proc, Name, Extends & Final?

Those are all items in the Interface Declaration. Not in the method instance. Your screen shot is of the method instance, so they would have no purpose there.

Extends and Final are not part of the language. They are “special comments” which are added to the (class) declaration, which then allow the embed tree to behave (and color) things differently. They are a bit of a hack, and not part of the language. I’ve never used either.

The Interface declaration definitly supports VIRTUAL, PROC and NAME, just as it would for any method declaration.

All that said, there is a syntax quirk which is worth understanding when it comes to embedding in (aka deriving) an interface method. Usually if you embed into a method (aka create a derived version of that method) you have to declare it in the derived class;
For example;

ThisWindow           CLASS(WindowManager)
Init                   PROCEDURE(),BYTE,PROC,DERIVED
                     End 

ThisWindow.Init PROCEDURE
ReturnValue          BYTE,AUTO
  CODE
  ! whatever

You can derive into an interface method, but you don’t specify it in the derived class declaration - it’s implicily (optionally) there. For example;

iDriverField        INTERFACE
ToRecordField         Procedure(Byte pFieldType, Long pFieldAddress, Long pFieldSize, Long pSrcType, Long pSrcAddr, Long pSrcSize),LONG ,PROC,VIRTUAL
FromRecordField       Procedure(Byte pFieldType, Long pFieldAddress, Long pFieldSize, Long pWriteAddress, Long pWriteSize),LONG ,PROC,VIRTUAL
ClearRecordField      Procedure(Byte pFieldType, Long pFieldAddress,Long pFieldSize,String pValue),LONG,PROC,VIRTUAL
IsRecordFieldClear    Procedure(Byte pFieldType, Long pFieldAddress,Long pFieldSize,String pValue),LONG,PROC,VIRTUAL
GetSourceSize         Procedure(),LONG,VIRTUAL   ! source size is the "disk" record size. Not the Clarion Record size. Multiplied if array.
GetFieldType          Procedure(),STRING,VIRTUAL ! return a unique text identifier for the field type
GetSQLType            Procedure(),STRING,VIRTUAL ! SQL Data type to use in CREATE statements
                    End

DriverGUIDClass     Class,Implements(iDriverField), Type, MODULE('DriverFields.Clw'),LINK('DriverFields.Clw',DRVLM), DLL(DRVDM)
!!! nothing declared here
                    End

DriverGUIDClass.iDriverField.ClearRecordField  Procedure(Byte pFieldType, Long pFieldAddress,Long pFieldSize,String pValue)
  code
  ! whatever here, including possible parent call.

For a long time this was not known, so people (incorrectly) believed (myself included) that interface methods could not be easily derived. This lead to an unnecessary pattern where you have class methods of the same name, and all the interface method did was call the class method.

also · August 2, 2026, 1:16pm

To add.

INTERFACE methods are all implicitly VIRTUAL. So there is no necessity to use the VIRTUAL attribute in prototypes of INTERFACE methods.
The declaration of an INTERFACE introduces a new type. The explicit TYPE attribute is not required. There are no ways to instantiate an INTERFACE other than to use it as a parameter of the IMPLEMENTS attribute for some CLASS, implements its methods as a part of that CLASS and then create instances of that CLASS. A reference to an instance of declared INTERFACE can be obtained from outside world, usually as a result of some function call.
Because of (2) the NAME attribute for INTERFACE methods has no sense.
One INTERFACE can be derived from another one. The child INTERFACE can add some additional methods and produces a new type. It can “override” some methods of the parent INTERFACE but this has no sense because of (2).
Parent and derived CLASSes can use the same INTERFACE as a parameter of the IMPLEMENTS attribute. The derived CLASS may implement not all methods of INTERFACE in this case, others are being taken from the parent CLASS. At least one method must be implemented in the child CLASS if it has the IMPLEMENTS attribute with the same INTERFACE as its parent CLASS.
The parent and derived INTERFACEs are separate types. So, if the parent CLASS implements the parent INTERFACE and its derived CLASS implements the derived INTERFACE, the derived CLASS must implements all methods of the derived INTERFACE.
One CLASS may have multiple IMPLEMENTS attributes in its declaration.

RchdR · August 2, 2026, 7:52pm

I’ll be changing this then (not public yet).

https://github.com/Intelligent-Silicon/Clarion-Class-Writing-Template#oop-rules

An INTERFACE declares the required CLASS methods, parameters & return values to be IMPLEMENTed.

An INTERFACE can be IMPLEMENTed in one or more CLASSes.

A CLASS can IMPLEMENT more than one INTERFACE.

A CLASS must have a Construct and Deconstruct method when using THREAD (Clarion 6 versions or later).

A CLASS can have additional methods not used in the IMPLEMENTed INTERFACEs.

#3 Answer’s my question about Name.

Seeing an Interface as a (Data) Type (#2) like a Group or a “parameter of Class Method [Entrypoints|Addresses]” does make sense. Even though I’ve coded for it in the template but disabled it, I just treated it as a hack or way to write things and so disabled it but left it for visual reinforcement, without know why but wondering if there was a new Type.

@also Your response takes the pertinent info spread across a number of different help pages which is better imo because its all in one place. The help docs caught me out a while back because I thought the class only used one Interface, and when I found out otherwise when wrapping up thats when a template rewrite was forced again. Anyway I dont like the help docs sorry @PaulAttryde

There’s nothing mentioned in the help docs so I’m assuming its not used, but do you know if they are used in interface methods? For now I can leave the code in and then test it when the template produces the output. For now its something extra to go back and check in the different IDE’s.

I’m also assuming other languages will be pretty much the same albeit with their difference in writing out things like parameters so I had to get this template right so I only have to do minimal changes when porting this from Clarion.