A problem with interfaces

A problem with interfaces

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

GRASP is a  fairly large project (over 22k lines of code in 77 files), but
I ran into a problem.

Until recently, I had an interface called Tile in the (editor interfaces
elements) module, defined in the following way:

(define-interface Tile (Element)
  (extent)::Extent)

where define-interface is a macro that would expand to

(define-simple-class Tile (Element) interface: #t
  ((extent)::Extent #!abstract))

The (editor interfaces elements) module imports the module (editor
interfaces painting), and they are used in various places in the project.
Among others, those interfaces are implemented by the Atom class, which is
defined in the (editor types primitive) module (which imports both
aforementioned modules)

I tried refactoring this, by defining  a new interface:

(define-interface Extensive ()
  (extent)::Extent)

in the (editor interfaces painting) module, and changing the definition of
Tile to

(define-interface Tile (Extensive Element))

But when I do this, the system claims that Atom is not Extensive (even
though it implements a sub-interface of the Tile interface). How could that
be?

Also, during compilation I get warnings like this from one of the modules:

*type editor.interfaces.Painter is incompatible with required type
editor.interfaces.Painter.*

How are they supposed to be understood?

Re: A problem with interfaces

[Per Bothner]

On 12/19/23 14:23, Panicz Maciej Godek via Kawa wrote:
> But when I do this, the system claims that Atom is not Extensive (even
> though it implements a sub-interface of the Tile interface). How could that
> be?
I don't know - could be a bug.  There hasn't been a lot of testing of interfaces
defined this way.

If you can create a short (20 lines or so) self-contained test-case,
I can take a look. It might turn out to be a simple problem.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: A problem with interfaces

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

I think that isolating the bug could be a bit difficult at the moment,
but I might try that later (I feel that this would require a lot of work,
and I'm not sure if I would succeed at the end)

But I did publish the breaking change, in case you'd want to have a look
https://github.com/panicz/grasp/commit/c678761a788a0356c3ecd1caa9f2c7a8bc900f57

(if running with the X server available, it's best to run ./grasp-desktop,
because
all the diagnostic messages go to console But since the program just dies,
running ./grasp-terminal should also be OK. Running ./run-tests 3 also
reproduces
the bug)




wt., 19 gru 2023 o 23:46 Per Bothner <per@bothner.com> napisał(a):

>
>
> On 12/19/23 14:23, Panicz Maciej Godek via Kawa wrote:
> > But when I do this, the system claims that Atom is not Extensive (even
> > though it implements a sub-interface of the Tile interface). How could
> that
> > be?
> I don't know - could be a bug.  There hasn't been a lot of testing of
> interfaces
> defined this way.
>
> If you can create a short (20 lines or so) self-contained test-case,
> I can take a look. It might turn out to be a simple problem.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>