Jump to content
Excelsior Forums
akarl

Is this a known compiler bug?

Recommended Posts

[src]$ cat Module.ob2

MODULE Module;

  TYPE

     T0* = POINTER TO T0Desc;

     T0Desc* = RECORD

        n: LONGINT

     END;

END Module.

[src]$ cat Test.ob2

MODULE Test;

  IMPORT Module;

  TYPE

     T1 = POINTER TO T1Desc;

     T1Desc = RECORD (Module.T0Desc)

        n: LONGINT

     END;

END Test.

[kalle src]$ xc =m Test.ob2

O2/M2 development system v2.51 TS © 1999-2003 Excelsior, LLC. (build 10.05.2005)

XDS Oberon-2 v2.40 [x86, v1.50] - build 10.05.2005

Compiling "Module.ob2"

no errors, no warnings, lines    7, time  0.00, new symfile

XDS Oberon-2 v2.40 [x86, v1.50] - build 10.05.2005

Compiling "Test.ob2"

* [Test.ob2 6.10 E022]

* identifier "n" was already defined at Test.ob2[6.10]

        $n: LONGINT

errors  1, no warnings, lines    8, time  0.01

-------------------------------------------------------------------

files: 2  errors: 1(0)  lines 15  time: 0:00  speed 10000 l/m

Share this post


Link to post
Share on other sites

But how do you imagine referencing to two fields "n" in the same record type? (one inherited from the parent object and another one added)

Share this post


Link to post
Share on other sites

I think that akarl is right.

It looks like a bug, because n from T0Desc is not exported from Module and cannot be accessed outside it.

Share this post


Link to post
Share on other sites

I have probably found the reason for this bug in XDS compiler.

I think it takes after Oberon-2 report where it is said:

extension

of another record type. In the example

T0 = RECORD x: INTEGER END

T1 = RECORD (T0) y: REAL END

T1 is a (direct) extension of T0 and T0 is the (direct) base type of T1 (see section

12). An extended type T1 consists of the fields of its base type and of the fields

which are declared in T1 (see section 6). All identifiers declared in the extended

record must be different from the identifiers declared in its base type record(s).

It is possible that compiler writers took it literally.

I believe that it would be better to append:

except private fields of imported base records.

Share this post


Link to post
Share on other sites

This restriction sounds natural to me, because:

Imagine a general case: somebody have written a program where a series of types T0, T1, T2, etc., are defined in modules A0, A1, A2, etc., respectively, so that Tn+1 extends Tn, and each of Tn has a private field named "f". Now, suppose you decide that for some reason you need a certain field Ti.f exposed for use in some other modules B0, B1, B2, etc. The program won't compile until you refactor either the module Ai, or all modules Aj where j>i.

Share this post


Link to post
Share on other sites

If we follow your argument it shouldn't be possible to do the following either.

$ cat M0.ob2

MODULE M0;

  TYPE

     T0* = POINTER TO T0Desc;

     T0Desc* = RECORD END;

  PROCEDURE (self: T0) P;

  END P;

END M0.

$ cat M1.ob2

MODULE M1;

  IMPORT M0;

  TYPE

     T1* = POINTER TO T1Desc;

     T1Desc* = RECORD (M0.T0Desc) END;

  PROCEDURE (self: T1) P*;

  END P;

END M1.

Share this post


Link to post
Share on other sites

Unnatural and violating the incapsulation principle is that in an derived type we need to know all the private fields of the whole hierarchy ofl base types. From one hand, we cannot access these fields. From another hand, we cannot reuse their names. Thus if we wish to override cordinates names x and y in a base type, we need to introduce x1 and y1 in a derived type.

The reason of "making exported" a formerly private field does not sound convincing: any change in an interface of a base type causes necessity to revise all derived types! What if I wish just to add a NEW field in a base type that is already used in some of its derivatives?? This is the problem of versioning better approached in COM...

Share this post


Link to post
Share on other sites
Guest poki

This is a strange behaviour, and as far as i know only XDS do this way.

The 'problem' becames serious when a base record is changed adding a new private field: then is likely to produce a name clashing conflict in derivated records in client module.

XDS is now free: I think Excelsior will not spent time or resource to fix this or any

other bug, cause will not produce any money returns.

Regards 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×