Inheritance documentation

Forum for discussion about the documentation project.
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Inheritance documentation

Post by counting_pine »

I've stubbed pages for KeyPgExtends and KeyPgBase. I think Is will probably also need a new page. Perhaps KeyPgIstype or something?

So I think the tasks now that need doing are:
- Making a new page for Is (or sharing with the current KeyPgIs?)
- Linking pages to the necessary CatPg pages (CatPgFullIndex, CatPgFuncIndex, CatPgUserDefTypes; and probably CatPgOpConditional for Is?)
- Filling out stubbed sections with necessary sections
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Inheritance documentation

Post by dkl »

Great, let's see. How about KeyPgIsTypeOf (that's similar to what it's called in the FB source) or KeyPgIsRtti? There is Is (Select Case), and Is (Type) or Is (Rtti).
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

Where define the keyword 'Object'?

- 'Object' is a predefined type which allows (by inheritance) to access to the Run-Time Type Info (RTTI), authorizing the use of the keyword 'Is' to compare the instance 'This' with type symbols.
- Consequently, 'Object' must be called by keyword 'Extends', and keyword 'Is' requests 'Object' as base type.
- A separated page for 'Object' should be the rule (one page at least for each keyword)?
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Inheritance documentation

Post by counting_pine »

I must admit I haven't experimented with Is before, and I had in fact forgotten there were two new meanings. Were they both added together in the Inheritance branch?

Actually, thinking about it, should the names be KeyPgIstypeof/KeyPgIsrtti, or should they be Op pages, e.g. KeyPgOpIstypeof/KeyPgOpIsrtti? I guess they're not overloadable but then neither are the short-circuit ops.
(Also, there is a slight question of CamelCase usage. I don't think the wiki pages have been very consistent but I think the most common one is that after KeyPg/KeyPgOp only the next one letter is a capitalised.)

... Do we have an Object keyword as well?
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Inheritance documentation

Post by dkl »

It's only one Is operator, but I'm not sure whether it should be called something with type or typeof in it, or something with RTTI in it. In the rtlib source it's called fb_IsTypeOf() but perhaps for the documentation it's better to mention its relationship to RTTI?!

The second usage of the Is keyword is in Select Case checks like Case Is >= 1, so we'll want to disambiguate the Is operator from the Case Is statement.

Yep, Object is a new built-in data type, it's a new keyword.
MOD
Posts: 555
Joined: Jun 11, 2009 20:15

Re: Inheritance documentation

Post by MOD »

Maybe you can use this:
BASE
EXTENDS
OBJECT
IS
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

counting_pine wrote:Actually, thinking about it, should the names be KeyPgIstypeof/KeyPgIsrtti, or should they be Op pages, e.g. KeyPgOpIstypeof/KeyPgOpIsrtti? I guess they're not overloadable but then neither are the short-circuit ops.
And why not: KeyPgIsObject
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Inheritance documentation

Post by marcov »

I would keep a possible future extension to MI or interfaces in mind.
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Inheritance documentation

Post by counting_pine »

dkl wrote:It's only one Is operator, but I'm not sure whether it should be called something with type or typeof in it, or something with RTTI in it. In the rtlib source it's called fb_IsTypeOf() but perhaps for the documentation it's better to mention its relationship to RTTI?!

The second usage of the Is keyword is in Select Case checks like Case Is >= 1, so we'll want to disambiguate the Is operator from the Case Is statement.

Yep, Object is a new built-in data type, it's a new keyword.
OK, sorry. I got confused, I thought maybe we'd added an 'a Is b' that functioned like Java's '==' and doing '@a = @b', but then that makes much more sense in a language like Java where references are everywhere.

OK, so regarding the name, would "KeyPgIsrtti" be the most sensible choice, all things considered?
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

Documentation KeyPgOpIs: Operator Is (Run-time type information)

I think that we should also precise the 'Operator Is' behavior relating to derived types as parents/childes:
In that case, the result of 'Operator Is' is successful not only for its own type, but also successful for all its parent types (by inheritance) and not for its child types.

Modified example from documentation, with in addition a type 'A1' derived form the type 'A':

Code: Select all

Type A extends object
    As Integer a
End Type

Type A1 extends A
    As Double a1
End Type

Type B extends object
    As String b
End Type

Sub identify(ByVal p As object Ptr)
    If *p Is A Then
        '' If it's an A, then the cast is safe
        Print "A", CPtr(A Ptr, p)->a
    ElseIf *p Is B Then
        Print "B", CPtr(B Ptr, p)->b
    Else
        Print "unknown"
    End If
End Sub

Dim As A aa
Dim As B bb
Dim As object cc
Dim As A1 aa1

aa.a = 1
bb.b = "hello"
aa1.a1 = 3.14
aa1.a = 11

identify(@aa)
identify(@bb)
identify(@cc)
identify(@aa1)
In order to find the exact type (and not only a parent type), we must test it with 'Operator Is' respecting the following test order: (greatest) child -> (greatest) parent:

Code: Select all

Type A extends object
    As Integer a
End Type

Type A1 extends A
    As Double a1
End Type

Type B extends object
    As String b
End Type

Sub identify(ByVal p As object Ptr)
    If *p Is A1 Then
        '' If it's an A1, then the cast is safe
        Print "A1", CPtr(A1 Ptr, p)->a1, CPtr(A1 Ptr, p)->a
    ElseIf *p Is A Then
        '' If it's an A, then the cast is safe
        Print "A", CPtr(A Ptr, p)->a
    ElseIf *p Is B Then
        '' If it's an B, then the cast is safe
        Print "B", CPtr(B Ptr, p)->b
    Else
        Print "unknown"
    End If
End Sub

Dim As A aa
Dim As B bb
Dim As object cc
Dim As A1 aa1

aa.a = 1
bb.b = "hello"
aa1.a1 = 3.14
aa1.a = 11

identify(@aa)
identify(@bb)
identify(@cc)
identify(@aa1)
Remark:
I do not understand the second part of the description of the parameter 'typename':
The type to check against. This type must be derived from the expression's type.
(In documentation example, type 'A' is not derived from the type 'B', but both are derived from the built-in 'Object' type)
I would write instead:
The type to check against. This type must be derived from the built-in Object type (directly or by inheritance).


Warning:
About the syntax:
result = expression Is typename
- If typename is a type not derived from the built-in Object type,
then compile error:
error 244: Symbol type has no Run-Time Type Info (RTTI).
- If expression is not an instance of a type with run-time type information,
then no compiler error (normal because compiler cannot test it), but runtime error:
Aborting due to runtime error 12 ("segmentation violation" signal).
Last edited by fxm on Jan 24, 2012 15:01, edited 8 times in total.
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

Documentation KeyPgObject: OBJECT

Similarly to my previous post, I propose to complete the description text:
Object is a built-in type which provides run-time type information for all types derived from it using Extends, allowing them to be used with Operator Is.
with:
Object is a built-in type which provides run-time type information for all types derived from it (directly or by inheritance) using Extends, allowing them to be used with Operator Is.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: Inheritance documentation

Post by VANYA »

Thank you for what you are doing!
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

VANYA wrote:Thank you for what you are doing!
Thank you especially to DKL for his great and good drafting.
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Inheritance documentation

Post by dkl »

The KeyPgExtends, KeyPgBase, KeyPgOpIs, KeyPgObject pages should have some basic useful documentation now, but feel free to improve it, as usual. (Yea, I went for just KeyPgOpIs now, seemed like Operator Is is a pretty good name for it, and enough to distinguish it)
fxm wrote:I do not understand the second part of the description of the parameter 'typename':
The type to check against. This type must be derived from the expression's type.
(In documentation example, type 'A' is not derived from the type 'B', but both are derived from the built-in 'Object' type)
I would write instead:
The type to check against. This type must be derived from the built-in Object type (directly or by inheritance).
typename must be a child type of the expression's type. Operator Is only allows checking downwards in the inheritance hierarchy. Upwards checks can be solved at compile-time, and they cause an Types have no hierarchical relation error, for example here:

Code: Select all

type Parent extends Object
end type

type Child extends Parent
end type

dim as Child x
print x is Parent
fxm wrote:- If expression is not an instance of a type with run-time type information,
then no compiler error (normal because compiler cannot test it), but runtime error:
Aborting due to runtime error 12 ("segmentation violation" signal).
While experimenting I think I found some compiler issues aswell... fxm, could you post an example that crashes when using Operator Is? As far as I understand it now, it should not allow to use an object that doesn't have RTTI.
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

Yes, thank you DKL, I understood my confusion:

In all my previous test cases (above), the 'Operator Is' is used inside a procedure, and the instance to test is passed as an pointer parameter, declared 'As Object Ptr' in the procedure.
This is equivalent in fact to:
passed_instance = *Cast(Object Ptr, @instance)

1st example:

Code: Select all

type Parent extends Object
end type

type Child extends Parent
end type

dim as Parent p
dim as Child c

print p is child                      ' 0
print
print *cast(Object Ptr, @p) is Parent ' -1
print *cast(Object Ptr, @p) is Child  ' 0
print *cast(Object Ptr, @c) is Parent ' -1
print *cast(Object Ptr, @c) is Child  ' -1
print
print *cast(Parent Ptr, @c) is Child  ' -1
Nevertheless, *cast(Object Ptr, @c) is Parent = -1

2nd example:

Code: Select all

type Parent extends Object
end type

type Orphan
  notused as Integer
end type

dim As Orphan o
Print *cast(Object Ptr, @o) is Parent
Aborting due to runtime error 12 ("segmentation violation" signal)
Post Reply