Inheritance documentation

Forum for discussion about the documentation project.
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Inheritance documentation

Post by dkl »

Ok I see, it's the pointer casting that allows it to compile. Well, since it's an explicit cast(), the compiler assumes you know what you're doing and doesn't complain.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

fxm wrote: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
Why *cast(Object Ptr, @c) is Parent = -1?
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

In order to be more general:

Code: Select all

type Parent extends Object
end type

type Child extends Parent
end type

type GreatChild extends Child
end type

dim as Child c
print *cast(Object Ptr, @c) is Parent     ' -1
print *cast(Object Ptr, @c) is Child      ' -1
print *cast(Object Ptr, @c) is GreatChild ' -0
print
dim as GreatChild gc
print *cast(Object Ptr, @gc) is Parent     ' -1
print *cast(Object Ptr, @gc) is Child      ' -1
print *cast(Object Ptr, @gc) is GreatChild ' -1
Why *cast(Object Ptr, @c) is Parent = -1?

Why *cast(Object Ptr, @gc) is Parent = -1?
Why *cast(Object Ptr, @gc) is Child = -1?
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Inheritance documentation

Post by dkl »

As you mentioned in your previous post, Operator Is is successful not only for the "lowest" type (GreatChild), but also for base types (Parent, Child), as long as they are still below the type used on left-hand side of Operator Is (in your example: Object).

I.e. in order to determine the real type, you need to check all possibilities from lowest to highest. I'll update the wiki page to mention this.

Code: Select all

type Parent extends object
end type

type Child extends Parent
end type

dim as Object ptr o = new Child()
print *o is Parent
print *o is Child
Why is cast(Object Ptr, @c) is Parent true? Well, probably because a Child is a Parent, in that example code (type Child extends Parent).
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

Here I am reassured.
I did not have it all wrong!
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Inheritance documentation

Post by counting_pine »

dkl wrote: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)
Nice work :) thanks.
I've just been through and made a couple minor formatting changes. I also clarified what Is does, so basically instead of saying "if it's of type T" it now says "if it's of type T or one of its derived types".

PS. It's a bit of a special case, but do we need to update the operator precedence tables (www.freebasic.net/wiki/OpPrecedence) for this?
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Inheritance documentation

Post by dkl »

Operator Is is already listed in the precedence table, in the compile source code I found it between the relational operators and the & concatenation. It's definitely a special case, it's kind of a binary operator yet it only takes one expression, and it can't be overloaded either.
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Re: Inheritance documentation

Post by anonymous1337 »

Anyone care to add the first version/compiler release date where this functionality became available? Not only are these new features, but they're big ones not available in the current official release (afaik).
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Inheritance documentation

Post by counting_pine »

It's been a work in progress for a while, but the big merge happened here, on 20 November 2011:
https://github.com/freebasic/fbc/commit/4170723
What do you think it would be the best way to add the information?
Ideally perhaps we should have a "changelog" section for every page, though it would be a massive undertaking, but that shouldn't stop us from adding info like that to specific pages where we feel it's necessary.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

Among the four keywords dedicated to inheritance: 'Extends', 'Base', 'Object' and 'Operator Is', I think the first 'Extends' is the main root, because it is always mandatory and can even be used alone.

I added at the end of paragraph 'Description:' of KeyPgExtends:
Warning: Before fbc version 0.24, these four keywords dedicated to inheritance Extends, Base, Object and Operator Is are not supported.
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Re: Inheritance documentation

Post by anonymous1337 »

I'm not sure changelog sections are necessary. Most of FreeBASIC's features have been present for a long time. Even when changes to a feature are frequent, features tend to stabilize. The latest version of FreeBASIC becomes the de facto standard for the community.

If we were Adobe or Microsoft and had 30%+ of our users waiting to upgrade to the latest version of our product, I would understand documenting such changes.

A simpler solution may be to, in the "Differences from QB" where it says "New to FreeBASIC", modify the text to say "New to FreeBASIC as of version X.XX" for major feature additions.
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Re: Inheritance documentation

Post by anonymous1337 »

PS: It looks like commit to the master branch aren't that frequent as of late. Is there anything being waited on before the official release of FBC 0.24?
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Inheritance documentation

Post by fxm »

Same case for 'Threadcall' available only from FBC version 0.24.
Even forgotten in current file 'changelog.txt'!
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Inheritance documentation

Post by dkl »

I don't think a changelog or "first added" is needed on each keyword. Basically if you're going to be using FB 0.18 forever, then please use the FB 0.18 documentation alongside, not the latest online wiki, which more or less corresponds to the latest development version. Luckily there is almost no difference, because FB doesn't change that much anymore.

Although, I'd like to see the FB project history to be extended/updated for big/important events, and anecdotes of course, that's the most fun part. Weird that Threadcall managed to stay out of the changelog.txt though, we'll have to add it. Well, I found myself forgetting changelog.txt entries repeatedly, and once even accidentially deleting some...
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Re: Inheritance documentation

Post by anonymous1337 »

You bring up a good point - the changelogs have always been available.

The reason I brought up this issue? I tried using inheritance features in my version of fbc. Wasn't there. I make sure I have the latest official release. I do.

The question I have is how the wikipedia's going to be more up to date than the official compiler release, yet there is no way for me to verify that I'm not simply "doing it wrong" without going into the repository's changelog.
Post Reply