[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goops - guile-clutter unexpected bug while using #:virtual slot allo
From: |
David Pirotte |
Subject: |
Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass |
Date: |
Sat, 7 Feb 2015 15:13:51 -0200 |
> Hello again :)
Yes, hello,
Saturday greetings!
> ... So let us not argue over that. Let us instead treat your concern as
> request
> that the behavior should be different.
Perfect, let's talk about ... should we, how, how much :) ...
> > we should follow the clos spec here
> That said I think the CLOS way is usually better
Agreed, definitely: I'm well aware that it is a very complex task to implement
it
correctly [and fully, but I don't need the full protocol either, 1 day
maybe...], and
very 'frustrating' too, since it is almost impossible to make it run 'fast', by
definition, as you know. of course ... But I really need the subset we have in
goops
to implement the corresponding clos subset protocol, especially what we are
talking
about.
> but we are limited by two things: compatibility with past behavior (not a
> terrible concern in this instance, given the lack of outcry when I broke
> things),
> and secondly by hack-power. In particular I do not have any additional free
> time to spend on GOOPS features in the near future.
Would you have some available pay time? If so, could you send me a private
quote, I
need this change asap, and if the quote is reasonable, you could start
immediately.
If you [guilers] think it should also be in goops, fine, I am happy to 'fund
that part of the protocol for all' :) If not, could you include in the quote a
bit of time to implement a git branch with goops only, name it gclos or what
ever
is [more] appropriate , if that is possible [?], so that I can always and in a
very
easy way, track stable-2 [master in the near future] but apply 'my' goops [I
mjean (re)configure/make/make install 'my' goops...
> This feature you are asking for requires:
>
> * more logic in method-applicable? for accessor methods that would
> 1. check the list of effective slot definitions in the target object
> 2. for each slot, get the direct slot definition
> - currently there is no long from effective to direct, we'd have
> to add that
> 3. if the target object has a slot with the same direct slot
> definition as the one associated with the accessor method, then
> the method applies, otherwise not
>
> * compile-time specialization for methods, as in
> 583a23bf104c84d9617222856e188f3f3af4934d which was later reverted
>
> Open questions would be, do we expose method-applicable? as a generic,
> there's some gnarly circularity because these methods are part of the
> method dispatch protocol, do we expose more of the slot protocol to
> users (it's currently somewhat opaque and unfinished), how to document
> all of this, we need a bunch of tests too, how do you relate effective
> slots to direct slots in the CLOS case where you can make composite
> slots, etc.
I will answer this part a bit latter, I need to think about it :)
> It's a bit of work and I need to do other things :)
Sure,
I have too,
Let's see if you are interested and has pay time available...
Cheers,
David
pgpCmlqSQZY0H.pgp
Description: OpenPGP digital signature