On Tue, Aug 31, 2010 at 20:03, dsimcha <dsim...@yahoo.com> wrote:
> == Quote from Lutger (lutger.blijdest...@gmail.com)'s article
> > Instead of std.mixins, perhaps it is better to fold the code with
> std.typecons
> > or create new modules as needed (std.pattern?).
>
> I initially thought std.mixins would be a good idea, since it would be a
> one-stop
> shop for all kinds of misc. boilerplate code that doesn't really fit
> anywhere
> else, but the consensus seems to be that this is a bad way to define a
> module.
> I'll reconsider.
>
Dunno. I quite liked std.mixins. But then, std.pattern(s?) is good too,
except many people will think GoF-patterns.
btw, doesn't std.pattern already exist, to show some OOP-patterns already
coded in D?
We could show some humor and call it std.boilerplate :)
>
> > There is also some private
> > boilerplate code here and there in phobos that help with ctfe and
> > metaprogramming, some people may also find that useful if packaged as a
> seperate
> > utility module.
>
> Yea, that should probably be a todo.
>
std.typecons is full of good stuff. I learnt quite a lot reading it. The Any
code gave many hours of reading, compiling the resulting code in my head, so
to say. Then I went a little mad ;)
My initial suggestion for your OP was a mixin to put in a class/struct to
make it extensible: using opDispatch to transform a method call
a.foo(args...) into the free function foo(a, args). That way a library
author makes her class extensible, and I, as a user, add free
functions-passing-as-methods as I see fit.
template MakeExtensible()
{
auto opDispatch(string s, Args...)(Args args)
if(is(typeof(mixin(s~"(this, args)"))))
{
mixin("return "~s~"(this, args);");
}
}
It's a 3-line mixin, but it suffers from a nasty problem: opDispatch only
sees the symbols defined in the class modules, which forces the user to
define the free functions in the class module and that rather defeats the
point :(
The only solution I found was to make a wrapper template: struct (or class)
Extend!Type that will act as a Type in most cases and uses an opDispatch to
remain open. Note that 'alias this' has priority on opDispatch, so I
couldn't use alias this in this case: the free-functions-as-method calls
would be propagated to the wrapped struct/class and create an error there,
without being rerouted through opDispatch.
Anyway...
To solve the symbol-visibility problem, I made the whole machinery a
template, which should be mixed in the main module.
For the user, it's trivial, add:
mixin Extensible;
in your main module (or in any module you'll use free functions, but symbol
visibility will be affected ). You can then use extend(value) to get an
extensible version of a class or struct.
I have to complete to code to forward all operator calls to the wrapped
value, since I cannot use alias this. In the end, I project to extract this
part to make a generic ParallelType!Type wrapper that is not a subtype of
Type (as alias this would). Indeed ExtendType is just a parallel type wich
forward unknown methods to free functions.
Another proposal I have is a mixin that creates a string enum, Names,
containing the local scope qualified name.
module pack.mod;
mixin(ScopeName); // Names is "pack.mod"
int foo(int j)
{
mixin(ScopeName); // Names is "pack.mod.foo"
}
class C(A,B)
{
struct S
{
void method()
{
mixin(ScopeName); // Once C is instantiated Names is
"pack.mod.C!(type1, type2).S.method"
}
}
}
And so on... The code is _heavily_ based on std.demangle.demangle, with some
subtle differences to make it work at compile-time. I'm not sure that would
be good practice to duplicate such a function in Phobos...
Use case : as an helper for other mixins, giving them access to the local
scope name. For example the local function name/class name for logging, or
the current module name to test the existence of a type, etc.
>
> > The dranges project at dsource is awesome, it wouldn't hurt to put
> > some of that good stuff in phobos.
>
> Agreed. It's Philippe Sigaud's project and he's been recently added to the
> roster
> of Phobos devs. I assume he intends to integrate at least the more
> generally
> useful parts of dranges eventually.
>
Thanks for the kind words, both of you. It's on my todo list on the short
term (~ 1 week). I'll extract some code and propose if for review. David
just has to stop launching interesting threads or asking for review of his
own code :)
Philippe
