[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A mess with GOOPS

From: Panicz Maciej Godek
Subject: Re: A mess with GOOPS
Date: Tue, 6 Sep 2011 00:47:20 +0200

OK, you were right :)
I made a small change -- instead of namiing my new class
<generalized-array>, I simply named it <array>, so that the smob name
overlaps with the class name. I don't know if it's a proper
programming style, but it's simple and it works.

There is, however, another problem that I've observed. I don't know if
it is caused by my modification, but both array-shape and
array-dimensions return the following error:

While compiling expression:
ERROR: In procedure vector-length: Wrong type argument in position 1

Other than that, I could send the patch (if I only knew how to generate it).

Best regards,

2011/9/5, Panicz Maciej Godek <address@hidden>:
> I've been trying to add the superclass.
> Adding it to <vector> and <bytevector> turned out
> to be extremely simple, but the problem emerged
> when I was trying to generalize the <array> class.
> The thing is that <array> is implemented as a smob,
> and that there is no easy way to add a superclass
> to a class created from smob.
> I can think of a number of ways of making
> a workaround, but all of them are nasty. Each
> of them will require the modification of
> goops.c: create_smob_classes.
> The first way would be to check whether
> !strcmp (SCM_SMOBNAME (i), "array")
> and to behave appropriately when it happens.
> But that would be just ugly.
> The other two ways that come to my mind would be:
> 1. to modify the type `scm_smob_descriptor', adding
> SCM supers; /* list of superclasses */
> or, equivalently
> 2. to add a new global array,
> SCM_API SCM smob_supers[MAX_SMOB_COUNT], such
> that their default would either be SCM_EOL, or
> scm_list1(scm_class_top).
> The other idea would be to mess with
> scm_sys_inherit_magic_x and add a superclass
> after the creation of "<array>", but that doesn't
> sound too sound (at least for as long as this action
> is undocumented)
> So to me it seems that adding the <generalized-array>
> (or however should it be called) that would be the
> ancestor of "array" requires some changes in the
> guile API. I wouldn't do it without the overall approval.
> Best regards
> M.
> 2011/9/3, Andy Wingo <address@hidden>:
>> Hi Panicz,
>> On Fri 02 Sep 2011 21:53, Panicz Maciej Godek <address@hidden>
>> writes:
>>> In other words, classes <vector>, <uvec> and <array> have nothing in
>>> common, which requires me to triple the number of methods that could
>>> accept any of these types.
>> We should fix this.  We can probably do it in 2.0.  Interested in
>> sending a patch?
>> Currently this stuff is in C, unfortunately.  Perhaps it should move to
>> Scheme at some point, but if you just wanted to add an <array> or
>> <generalized-vector> superclass, see goops.c.  Look for the <uvec> stuff
>> and follow the patterns.
>> Andy
>> --

reply via email to

[Prev in Thread] Current Thread [Next in Thread]