New fbc branch ('inheritance') on sourceforge (fbc SVN)

[marcov]

The OOP of Delphi going way back is conceptually based on C++. VB before .NET didn't really do OOP at all.

This is incorrect. Delphi's Object Pascal has been based on an Apple standard draft from 1989. They modernized the keywords a bit, which might give a C++ look (Borland compiler development is a C++ shop mostly, despite a Pascal being the flagship product), but the core choices are from the object pascal draft. Including stuff like reference based classes.

VB classic could use COM objects afaik, and had some limited ways to implement COM objects. It was limited sure, but nobody said you had to be up to Delphi level to be "OO". (and what exactly is OO is a long discussion, but it is most certainly not defined as whatever C++ implements)

C++ is in my mind the standard reference on how OOP is done.

Odd, since it is the only popular language with a static memory model and manual pointer syntax for classes. I don't see that at all. Not even if I try to regard it from a neutral point of view. C++ is more a branch apart from the mainline of language development, because its long conception time and its strict C backwards compatibility requirements.

This is even more prominent on the generics front, where the C++ implementation (the compiler bits) are an island also, since based on token replay technology due to the preprocessor. While Java, C# and Delphi implemented checked generics. OTOH, the library side was heavily influenced by C++ STL, because of Stephanov (Mr. STL) enormous influence. Though strictly ADA had generics way before C++ had templates.

[agamemnus]

In last few month I play with different open source languages: Vala, FreePascal, FreeBasic

I really like FB!!!!! It is excellent!!
--------------------------------------------
I am just confused with version number. What does it mean 0.21.1

How far is it from 1.00?

That's how most open-source projects operate. I guess it'll be at 1.00 when all or almost all the desired features are implemented and it has been stable (no major bug reports) for a while.

[robertsconley]

VB before .NET didn't really do OOP at all.

The class structure Visual Basic 4,5, & 6 was a thin wrapper around COM. Whatever COM supported Visual Basic supported. And what COM supported were interfaces.

C++ is in my mind the standard reference on how OOP is done.

Having programed in C++, I created a simulation of the Mercury Space Capsule down to the switch, and in various flavors of Visual Basic, a shape creation, metal cutting software, there are far more things you can do with COM style Object Oriented Programming than C++.

This is because C++ focused on reuse of behavior, inheritance, and COM focused on reuse, polymorphism. The reason it was an issues is that COM had no inheritance support and C++ Polymorphism support was a pain to use as it was all mixed in with the inheritance syntax. So it create a bit of either or situation and depending on what type of project you did which was important.

In my metal cutting software I don't have much reuse of behavior, instead I am interfacing with various libraries of similar objects. For example the shapes that can be created, the machine controllers I can run, and the files that I can save or read. Putting these behind common interfaces is the only way to manage this so polymorphism is of particular importance.

I also found that polymorphism is more flexible than inheritance as polymorphism and simulate inheritance by using aggregation. But the reverse isn't true.

You don't have to take my word for it either. The authors of Design Patterns say as much in their books. Many of the patterns including many complex ones rely on polymorphism not inheritance.

But the trend these days is to support both equally well like C# or other programming languages. Combined with generics, inheritances comes useful at the low level of the framework.

As for freebasic inheritance is needed but polymorphism be of far more importance when it is implemented. My recommendation that interfaces and inheritances should be strictly separated and not done through c++ like syntax. It fine how inheritance is being implement now. But there should be a interface structure, interface .. end interface, that types can implement.

[fxm]

After testing, I believe I am correct in finding that static procedure member inheritance is well supported by this new branch as non static procedure member, what is good in my opinion.

Am I right and what is your opinion?

[fxm]

POST OF RECALL

Having had no response to some previous posts, and before this topic is permanently disabled, let me remind you the two precise questions I posed about the inheritance branch:

1.
In this short example:

Code: Select all

Type UDT1
  name as string
End Type

Type UDT2 extends UDT1
  name as string
End Type

Type UDT3 extends UDT2
  name as string
  declare constructor()
  declare constructor(Byref Nom As String)
End Type

constructor UDT3 (Byref Nom As String)
  base.name = Nom
End constructor

Dim test as UDT3 = UDT3("Tom")
Print test.name
Print cast(UDT2, test).name
Print cast(UDT1, test).name

Why compilation error?
- error 22: Internal!, ASTINCOFFSET in 'Print cast(UDT2, test).name'
when 'Print cast(UDT1, test).name' compile successfully.

Only UDT3/UDT2 member function can access to member data 'name' of UDT2 (UDT2 beeing the middle UDT of the inheritance structure)?

But the same example runs via pointer use!
Print cast(UDT2 ptr, @test)->name
or
Print *cast(UDT2 ptr, @test).name


2.
It might be nice to have a list of the keywords (with their meanings) specific to this extension: 'Extends', 'Base', 'Object', 'Is', ...?

[agamemnus]

Why compilation error?
- error 22: Internal!, ASTINCOFFSET in 'Print cast(UDT2, test).name'
when 'Print cast(UDT1, test).name' compile successfully.

Only UDT3/UDT2 member function can access to member data 'name' of UDT2 (UDT2 beeing the middle UDT of the inheritance structure)?

But the same example runs via pointer use!
Print cast(UDT2 ptr, @test)->name
or
Print *cast(UDT2 ptr, @test).name

Er, don't you mean "Only UDT3/UDT1 member functions can access the member data of UDT3"? From what you say the error is, it seems "print cast(UDT2, test).name" is the problem..

The code seems OK, so I dunno why either "print cast(UDT2, test).name" or "print cast(UDT1, test).name" would error.

-----

The reason why the pointer method works is because it has always worked. It doesn't have to do with the inheritance code, I think.

[fxm]

Er, don't you mean "Only UDT3/UDT1 member functions can access the member data of UDT3"? From what you say the error is, it seems "print cast(UDT2, test).name" is the problem..

The code seems OK, so I dunno why either "print cast(UDT2, test).name" or "print cast(UDT1, test).name" would error.

I added some code to my previous example, in order to be more explicit:

Code: Select all

Type UDT1
  name as string
End Type

Type UDT2 extends UDT1
  name as string
End Type

Type UDT3 extends UDT2
  name as string
  declare constructor()
  declare constructor(Byref Nom As string)
  declare function read_name_UDT2 () as string
End Type

constructor UDT3 (Byref Nom As String)
  base.name = Nom
End constructor

function UDT3.read_name_UDT2 () as string
  return base.name
end function

Dim test as UDT3 = UDT3("Tom") ' "Tom" is written in name of UDT2

Print test.name
'Print cast(UDT2, test).name ' compiler error
Print test.read_name_UDT2
Print cast(UDT1, test).name

("Tom" is written only in name of UDT2)

Print cast(UDT1, test).name
is valid

Print cast(UDT2, test).name
is invalid : error 22: Internal!, ASTINCOFFSET in 'Print cast(UDT2, test).name ' compiler error'.
What means 'ASTINCOFFSET'?

But, by means of one member function 'read_name_UDT2' of UDT3, we can read the member data 'name' of UDT2 from test (instance of UDT3):
Print test.read_name_UDT2

You can also modify the member function 'read_name_UDT2' as:
function UDT3.read_name_UDT2 () as string
return cast(UDT2, This).name
end function
and it always runs:
'cast(UDT2, This).name' is valid for a member function of UDT3
'cast(UDT2, test).name' is invalid for an instance of UDT3
Why?
It is as if 'name' of UDT2 was 'Protected' and not 'name' of UDT1!

The reason why the pointer method works is because it has always worked. It doesn't have to do with the inheritance code, I think.

OK.
In general, there is no control on access by pointer.

[eodor]

see at : http://www.mediafire.com/?vjffzddd6po3r3u

[agamemnus]

It is as if 'name' of UDT2 was 'Protected' and not 'name' of UDT1!

Idk... it does look like a bug to me.

The reason why the pointer method works is because it has always worked. It doesn't have to do with the inheritance code, I think.

OK.
In general, there is no control on access by pointer.

What do you mean by: "In general, there is no control on access by pointer."

??

[fxm]

What do you mean by: "In general, there is no control on access by pointer."

??

I only thought to the different compiler warnings, enhanced with the option '-w pedantic'.

[agamemnus]

What warnings does the pointer code give?

[fxm]

'cast(UDT2, This).name' is valid for a member function of UDT3
'cast(UDT2, test).name' is invalid for an instance of UDT3
Why?
It is as if 'name' of UDT2 was 'Protected' and not 'name' of UDT1!

If I increase the number of UDTs, chained by inheritance:
UDT1 (base) <--extends-- UDT2 <--extends-- UDT3 <--extends-- UDT4
each with the identical field-name 'name',
then the problem concerns all the intermediary UDT: UDT2 and UDT3 in that case.

Dim Test As UDT4
cast(UDT4, test).name ' valid (evidently) and runs
cast(UDT3, test).name ' invalid : error 22: Internal!, ASTINCOFFSET
cast(UDT2, test).name ' invalid : error 22: Internal!, ASTINCOFFSET
cast(UDT1, test).name ' valid and runs

but any other cast, using pointer (@test) runs well,
for example, for UDT2 name access:
*cast(UDT2 ptr, @test).name ' valid and runs
cast(UDT2 ptr, @test)->name ' valid and runs
and even
cast(UDT2, *@test).name ' valid and runs

Besides, inside code of any member procedure of UDT4:
cast(UDT2, This).name' is valid and runs

It is as if 'name' of UDT2 (or UDT3) was 'Protected member' (abnormal), and 'name' of UDT1 'Public member' (normal)!

[fxm]

What warnings does the pointer code give?

I think it is a misunderstanding (I spoke about pointer compiler warning in general):

- In my previous program example,
Print cast(UDT2 ptr, @test)->name
or
Print *cast(UDT2 ptr, @test).name
induces no compiler warning

- But I don't know because with the 'fbc-oop-snapshot-win32.zip' of dkl, there is practically no more compiler warning concerning pointers.
For example:
dim pt1 as Integer ptr
dim pt2 as sub()
pt1 = pt2
induces : 'Suspicious pointer assignment' with official fbc 0.22.0
induces no compiler warning with 'fbc-oop-snapshot-win32'
why?

[agamemnus]

Erm....

Well that could also be a bug since the warning should be there..

[fxm]

@dkl

Can you tell us why there is practically no more pointer warning from the compiler, when using 'fbc-oop-snapshot-win32.zip' that you provided (see the bottom of my previous post)?
Besides, I use the compiler option '-w pedantic'.

Is it because the code is still not well cleaned?