lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Wellnhofer <wellnho...@aevum.de>
Subject Re: [lucy-dev] Extensibility of Clownfish runtime core
Date Mon, 30 Dec 2013 16:50:20 GMT
On 27/12/2013 04:28, Marvin Humphrey wrote:
> Let's consider the costs and benefits of extendability for String.
>
> Allowing the String class to be extended enables certain kinds of problem
> solving approaches.  For example, the build tool Rake monkey patches the
> Ruby
> String class to add the `ext` method, a feature which we use in our
> Rakefiles:
>
>      http://rake.rubyforge.org/classes/String.html
>
>      filepath_o = filepath_c.ext(".o")
>
> What we're contemplating for Clownfish is actually less powerful than what
> Ruby facilitates, because we'd only allow subclassed instances to run the
> additional methods, while Ruby allows you to add methods to the original
> class.  In any case, I don't think that use case is very compelling because
> a
> pefectly plausible alternative is available: instead of extending string
> with
> new instance methods, provide the same functionality via inert functions in
> string manipulation libraries.
>
>      filepath_o = MyPathTools.ext(filepath_c, ".o")

Yes, that should be good enough.

> The problem we're up against is that Clownfish does some inherently
> ambitious
> things with object creation and destruction.  It has to be compatible with
> the
> memory management regimes of multiple host languages.  It has to provide
> conversion routines to and from the host language data types which operate
> at
> the C/host boundary.  Round-tripping through the conversion routines is
> already complicated enough, because the mapping from Clownfish data types to
> host data types is always imperfect.  I don't see how you implement a sane
> conversion routine which preserves subclassing for core data types.

I agree that this wouldn't work. Subclassing is also restricted by the 
fact that we don't allow access to instance variables from other parcels.

But extending the core classes can still be useful at the C level. Just 
look at NoCloneHash and ZombieKeyedHash.

> So, if we're going case-by-case, I'd advocate that we work hard to design
> the
> following types for extensibility by users...
>
>      Obj
>      Err
>
> ... and work to close everything else off.
>
> Marvin Humphrey
>

+0 for making the core classes final.

We shouldn't encourage users to extend the core classes but it might 
sometimes be useful if you know what you're doing.

Nick

Mime
View raw message