View mode: basic / threaded / horizontal-split · Log in · Help
September 05, 2012
Re: D-etractions A real world programmers view on D
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.
September 05, 2012
Re: D-etractions A real world programmers view on D
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.
September 05, 2012
Re: D-etractions A real world programmers view on D
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.
September 06, 2012
Re: D-etractions A real world programmers view on D
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
September 06, 2012
Re: D-etractions A real world programmers view on D
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
September 06, 2012
Re: D-etractions A real world programmers view on D
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.
September 06, 2012
Re: D-etractions A real world programmers view on D
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 ;)
September 06, 2012
Re: D-etractions A real world programmers view on D
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
September 06, 2012
Re: D-etractions A real world programmers view on D
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
September 06, 2012
Re: D-etractions A real world programmers view on D
> 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...
5 6 7 8 9 10
Top | Discussion index | About this forum | D home