On Tue, 25 Oct 2011 06:00:28 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:

> I think adding more dynamic typing to D would be a splendid idea to
> further widen the variety of solutions for different problems.
> Modular app development is a very good practice and modularity means
> dynamicity, which in turn means, that one needs to give up on lots of
> sweet stuff like templates, overloading and string mixins.
> Variant is the first step towards dynamic alter-ego of D, which is
> completely undeveloped currently.
> Although my benchmarks show, that variant is quite slow and I'd really
> like a version of variant, optimized for ultimate performance.
> Also, there are lots of stuff, that i really need at run-time, which i
> only have at compile-time:
> * Interfaces. dynamic interfaces are very important to highly modular
> applications, heavily based on plugins. By dynamic interfaces i mean
> the set of attributes and methods of an object, which is only known at
> run-time.
> * Overloading. A.K.A multimethods. required by dynamic interfaces.
> * Dynamic templates. In other words, value-based overloading (since
> type is yet another attribute of dynamically typed data).
>
> Dynamic interfaces are also different from static ones because the
> interface isn't _implemented_ by a type, it's _matched_ by a type,
> which means, that if a type fits into an interface at run-time, i can
> safely cast it to that interface type and work with it.
>
> Being able to obtain the dynamic version of a delegate would be great
> to pass around generic callbacks.

Have you looked into opDispatch?

I think with opDispatch and some Variant[string] member, you should be able to implement fully dynamic types.  I think even some have done this in the past (even if only for proof of concept).

-Steve

1. opDispatch is no good for overloading when the set of methods are
defined at run-time.
2. opDIspatch doesn't cover operators (why?).

On Wed, Oct 26, 2011 at 6:09 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Tue, 25 Oct 2011 06:00:28 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>
>> I think adding more dynamic typing to D would be a splendid idea to
>> further widen the variety of solutions for different problems.
>> Modular app development is a very good practice and modularity means
>> dynamicity, which in turn means, that one needs to give up on lots of
>> sweet stuff like templates, overloading and string mixins.
>> Variant is the first step towards dynamic alter-ego of D, which is
>> completely undeveloped currently.
>> Although my benchmarks show, that variant is quite slow and I'd really
>> like a version of variant, optimized for ultimate performance.
>> Also, there are lots of stuff, that i really need at run-time, which i
>> only have at compile-time:
>> * Interfaces. dynamic interfaces are very important to highly modular
>> applications, heavily based on plugins. By dynamic interfaces i mean
>> the set of attributes and methods of an object, which is only known at
>> run-time.
>> * Overloading. A.K.A multimethods. required by dynamic interfaces.
>> * Dynamic templates. In other words, value-based overloading (since
>> type is yet another attribute of dynamically typed data).
>>
>> Dynamic interfaces are also different from static ones because the interface isn't _implemented_ by a type, it's _matched_ by a type, which means, that if a type fits into an interface at run-time, i can safely cast it to that interface type and work with it.
>>
>> Being able to obtain the dynamic version of a delegate would be great to pass around generic callbacks.
>
> Have you looked into opDispatch?
>
> I think with opDispatch and some Variant[string] member, you should be able to implement fully dynamic types.  I think even some have done this in the past (even if only for proof of concept).
>
> -Steve
>

Le 25/10/2011 17:39, Gor Gyolchanyan a écrit :
> That's the point. You don't always need to carry around your type.
> Also because you might do it in a specific and very efficient way.
> Imposing a single way of storing the type is a very inflexible decision.
> The type check may also be done at different points, after which it's
> not necessary to carry around.
> Also, as i said before, type checking WILL be done in debug mode and
> dropped in release mode.
> Variant could be built on that typeless value concept to ensure type
> safety at all times.
>

Well I don't kbnow how you can handle type safety on a non typed variable. That doesn't make sense to me.

What you want to to will end-up to be more complicated than Variant, but without the garanty that strong typing gives you. You'll losse on every facelets of the problem.

You can use opDispatch to make runtime methods and properties by having it forward to a function to do the lookup.

Something alone these lines:

DynamicObject delegate(DynamicObject[] args) dynamicFunctions;

DynamicObject opDispatch(string name, T...)(T t) {
      if(name !in dynamicFunctions) throw new MethodNotFoundException(name);
      DynamicObject[] args;
      foreach(arg; t)
           args ~= new DynamicObject(arg);

      return dynamicFunctions[name](args);
}


I've done a more complete implementation before, but don't have it on hand right now.

On Wed, 26 Oct 2011 10:15:33 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:

> 1. opDispatch is no good for overloading when the set of methods are
> defined at run-time.

For those cases, you must use the runtime interface that opDispatch will use directly.  D does not have a way to call a function by string at runtime.

call("functionName", arg1, arg2, arg3)

opDispatch simply provides a way to write cleaner code when you know the name of the function.

Even in dynamic languages, it's uncommon to call functions based on runtime strings.

> 2. opDIspatch doesn't cover operators (why?).

operators are not function symbols, and are already covered by templates.  It should be as simple as:

opBinary(string s, T...)(T args) if(isValidOperator!s)
{
   call(s, args);
}

-Steve

I know how opDispatch works. opDispatch is purely a syntax sugar (a
really neat one, IMO).
What I'm talking about is a way to choose between a set of functions,
based on the parameters.
It's basically dynamic overloading, but with additional ability to
overload, based on values (much like template constraints).
opDispatch, then could be a good way of hiding ugly code like
call("methodName", ...);

I never said, that i want this stuff to be built-in. THis is one of those cool things, that many people could use as library solutions. Such dynamic functions with powerful dynamic overloading and the help of opDispatch would be an unprecedented awesome solution to event handlers and callbacks.

On Wed, Oct 26, 2011 at 6:26 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Wed, 26 Oct 2011 10:15:33 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>
>> 1. opDispatch is no good for overloading when the set of methods are defined at run-time.
>
> For those cases, you must use the runtime interface that opDispatch will use directly.  D does not have a way to call a function by string at runtime.
>
> call("functionName", arg1, arg2, arg3)
>
> opDispatch simply provides a way to write cleaner code when you know the name of the function.
>
> Even in dynamic languages, it's uncommon to call functions based on runtime strings.
>
>> 2. opDIspatch doesn't cover operators (why?).
>
> operators are not function symbols, and are already covered by templates.  It should be as simple as:
>
> opBinary(string s, T...)(T args) if(isValidOperator!s)
> {
>   call(s, args);
> }
>
> -Steve
>