On Apr 27, 2013, at 00:44 , Marvin Humphrey <[email protected]> wrote:
> On Fri, Apr 26, 2013 at 4:10 AM, Nick Wellnhofer <[email protected]> wrote:
>> That's a great solution. But this isn't implemented yet, right?
>
> The current type mapping code differentiates between `const CharBuf*` and
> `CharBuf*` (though I have discovered today that the implementation is buggy
> and wraps host strings more often than it should).
OK, I found it in the typemap. But the generated bindings define XSUBs
directly, so the typemaps aren't used. It seems that we still have to adjust
the code in CFCPerlSub.c in XSBind.c.
> Const methods can be pretty annoying though. If we were actually to make
> Hash_Sum() const, that would prevent subclass implementations which cache hash
> sums in the object lazily.
In that case, I would simply cast const away. Without const methods, const
Strings would be almost useless.
>> BTW, the INCREF macro should be changed so it
>> doesn't work with const objects, see example above.
>
> I think something like this can work on systems which support GNU extensions:
>
> #define CFISH_INCREF(_self) \
> ({ void *_vself = _self; lucy_Obj_incref((lucy_Obj*)_vself); })
>
> The `void *_vself = _self;` construct causes a compiler warning under GCC and
> an error under G++ if `_self` is a pointer to someting `const`.
Yes, that's how it's done in Perl5:
http://perl5.git.perl.org/perl.git/blob/HEAD:/handy.h#l49
> Nothing to do with Python bindings. It's that we have multiple behaviors
> which we've been trying to account for via inheritance: encoding and
> "zombie"-ness. The fact that we'd need not only StringUTF8 and StringUTF16,
> but also ZombieStringUTF8 and ZombieStringUTF16 suggests that we haven't got
> the abstraction quite right.
>
> Here's an excerpt from the GoF _Design Patterns_ book, in the "Motivation" for
> the Bridge Pattern, which describes a similar situation:
>
> Consider the implementation of a portable Window abstraction in a user
> interface toolkit. This abstraction should enable us to write applications
> that work on both the X Window System and IBM's Presentation Manager (PM),
> for example. Using inheritance, we could define an abstract class Window
> and subclasses XWindow and PMWindow that implement the Window interface
> for the different platforms. But this approach has two drawbacks:
>
> 1. It's inconvenient to extend the Window abstraction to cover different
> kinds of windows or new platforms. Imagine an IconWindow subclass of
> Window that specializes the Window abstraction for icons. To support
> IconWindows for both platforms, we have to implement two new classes,
> XIconWindow and PMIconWindow. Worse, we'll have to define two classes
> for every kind of window. Supporting a third platform requires yet
> another new Window subclass for every kind of window.
That's what motivated me to merge strings, substrings and zombie strings into a
single class. In my proposal, there isn't a separate ZombieString class anymore.
Nick
