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
