On Wed, 05 Sep 2012 08:34:34 +0200
Jacob Carlborg <doob@me.com> wrote:
> 
> When I said "dynamic typing" that was a bit misleading. It's more the dynamic nature of Ruby I like. For example:
> 
> * Open classes
> * Reflection - adding methods, calling a method via a string,
> introspection

As far as monkey patching, I find *not* having that to be a major feature. :)

While a lot of runtime reflection *can* be built in D (even if it isn't all there right now), I am kind of annoyed at some of the limitations. Like how it's impossible (at either compile-time or runtime) to find the subclasses of a class. Uhh, actually that's the only limitation I know of. There might be more though.

> * Have executing code in all level of scopes

Not sure what sure mean by this?

> * Eval
> 

Needs polish, but:

https://bitbucket.org/Abscissa/semitwistdtools/src/977820d5dcb0/src/semitwist/util/process.d#cl-49

Usage:

string str;

str = q{ return 42; };
assert( eval!int(str) == 42 );

str = q{ return "Test string".dup; };
assert( eval!(char[])(str) == "Test string" );

:)

Granted, there'd probably be a lot less overhead doing that in Ruby or JS. But it works, more or less.

On Wednesday, 5 September 2012 at 18:22:16 UTC, Nick Sabalausky wrote:
>> * Have executing code in all level of scopes
> Not sure what sure mean by this?

In Javascript for instance, you don't need to use functions at all and can just write code that will run at the very top of the file.


Sometimes with D, I use a little helper program that adds some phobos imports and a void main(){} wrapper to the input, thus getting this same effect.


I don't like it in anything but short programs though... main() rox.

On Wednesday, 5 September 2012 at 06:34:01 UTC, Jacob Carlborg wrote:
> When I said "dynamic typing" that was a bit misleading. It's more the dynamic nature of Ruby I like. For example:

Yeah, that stuff can be good. Something I've been playing with in D is a prototype inheritance class, that you can add methods to dynamically. 9/10 times, I don't want this, but sometimes it is just nice to have.

But, right now, the horribly broken @property is really ruining it (and opCall being strangely designed in structs takes some fun out, but it works pretty well with classes... which means you have to use new at declaration, but meh, not a big deal). Everything else is pretty doable though.

Granted you couldn't use it to extend regular D stuff, but UFCS lets us sorta cheat on those anyway.

> The comparable features in a static language would probably AST-macros, annotations and similar features. If D had those features then I probably wouldn't want dynamic typing that much.

Annotations are my last dream for D, just bog simple attach metadata. My other wishes are pretty much little bug fixes.

On 2012-09-05 20:22, Nick Sabalausky wrote:

> As far as monkey patching, I find *not* having that to be a major
> feature. :)

It has saved my ass several times. Especially recently when we started to update Ruby 1.8 to 1.9.

> While a lot of runtime reflection *can* be built in D (even if it
> isn't all there right now), I am kind of annoyed at some of the
> limitations. Like how it's impossible (at either compile-time or
> runtime) to find the subclasses of a class. Uhh, actually that's the
> only limitation I know of. There might be more though.

Hmm, I actually haven't needed that in D yet. But it's so cool in Ruby, you can sort of hook up an event and be notified when a subclass inherits from its base class. The subclass then gets passed to the event handler and you can add new methods on the subclass.

>> * Have executing code in all level of scopes
>
> Not sure what sure mean by this?

The obvious one is you can have executable code at the global level. The less obvious one is you can have executable code when declaring a class:

def bar
end

class Foo
  bar() # call bar
end

This is heavily used in Ruby on Rails' ActiveRecord implementation:

class Post
  has_many :comments
end

class Comment
  belongs_to :post
end

The cool thing is that these are just plain method class (class methods). They will add some methods to context where they are called. Any other language would probably need annotations or some other kind of extra language feature to get this nice looking syntax.

Currently in D you would probably use template mixins:

class Post
{
    mixin hasMany!("comments);
}

class Comment
{
    mixin belongsTo!("post");
}

But I think this use case would be perfect for AST-macros or user defined attributes/annotations:

class Post
{
    @hasMany("comments");
}

class Comment
{
    @belongsTo!("post");
}


> Needs polish, but:
>
> https://bitbucket.org/Abscissa/semitwistdtools/src/977820d5dcb0/src/semitwist/util/process.d#cl-49
>
> Usage:
>
> string str;
>
> str = q{ return 42; };
> assert( eval!int(str) == 42 );
>
> str = q{ return "Test string".dup; };
> assert( eval!(char[])(str) == "Test string" );
>
> :)
>
> Granted, there'd probably be a lot less overhead doing that in Ruby or
> JS. But it works, more or less.

I'll have to take a look at that sometime. Is it that code that calls RDMD to compile and run it?

-- 
/Jacob Carlborg

On 2012-09-05 20:43, Adam D. Ruppe wrote:

> In Javascript for instance, you don't need to use functions at all and
> can just write code that will run at the very top of the file.
>
>
> Sometimes with D, I use a little helper program that adds some phobos
> imports and a void main(){} wrapper to the input, thus getting this same
> effect.
>
>
> I don't like it in anything but short programs though... main() rox.

In Ruby you can also but executable code in class declarations. It's heavily used in Ruby on Rails' ActiveRecord implementation:

class Post
  has_many :comments
end

class Comment
  belongs_to :post
end

"belongs_to" and "has_many" are plain class methods. When this is possible you rarely need user defined attributes/annotations and similar features.

-- 
/Jacob Carlborg

On Thu, 06 Sep 2012 08:44:20 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2012-09-05 20:22, Nick Sabalausky wrote:
> > Needs polish, but:
> >
> > https://bitbucket.org/Abscissa/semitwistdtools/src/977820d5dcb0/src/semitwist/util/process.d#cl-49
> >
> > Usage:
> >
> > string str;
> >
> > str = q{ return 42; };
> > assert( eval!int(str) == 42 );
> >
> > str = q{ return "Test string".dup; };
> > assert( eval!(char[])(str) == "Test string" );
> 
> I'll have to take a look at that sometime. Is it that code that calls RDMD to compile and run it?
> 

Yes.

On Thu, 6 Sep 2012 04:38:24 -0400
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Thu, 06 Sep 2012 08:44:20 +0200
> Jacob Carlborg <doob@me.com> wrote:
> 
> > 
> > I'll have to take a look at that sometime. Is it that code that calls RDMD to compile and run it?
> > 
> 
> Yes.
> 

The only other trick is (de)serializing the eval's return value to send
it back through stdout. It'd probably be a good job for Orange ;)

On 2012-09-06 10:41, Nick Sabalausky wrote:

> The only other trick is (de)serializing the eval's return value to send
> it back through stdout. It'd probably be a good job for Orange ;)

Hehe :)

-- 
/Jacob Carlborg

On Wed, 05 Sep 2012 14:22:43 -0400, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:


> While a lot of runtime reflection *can* be built in D (even if it
> isn't all there right now), I am kind of annoyed at some of the
> limitations. Like how it's impossible (at either compile-time or
> runtime) to find the subclasses of a class. Uhh, actually that's the
> only limitation I know of. There might be more though.
>

I think this actually is one of the few reflection things possible :)

If you look in druntime, there is a way to iterate over all class TypeInfo objects, and you can simply see if the class type inherits from your target.

It may be inefficient, but possible (and you can build a tree based on this so further lookups are not slow).

-Steve

> 2. The C preprocessor is no excuse to why we shouldn't have good refactoring tools for D.

I think the author of the original message including many who agree with him forget a simple fact - coding an IDE that can handle D's generative abilities is not a trivial thing to do.

I can whine about many things that I miss, but I can't expect from an open-source community to spend thousands of working hours coding extra-dificult features...