The DeRailed Challenge

Brad Anderson brad at dsource.org
Sat Feb 10 07:36:52 PST 2007


Robby wrote:
> comments inline
> kris wrote:
>> 'DeRailed' is a project intended to compete in the space where RoR has
>> been successful. We believe an RoR "killer" will do wonders for D as a
>> language, in terms of publicity and potential widespread adoption.
>>
> How about before it starts we leave the term killer out of it and come
> back to alternative. Not that I don't think D can supply a better
> toolkit, but when I read killer I think of 'ipod killer (zune), windows
> killer (some linux distro)' etc. There isn't any reasons to encourage
> defensiveness from the start. :)

I agree, and don't like the DeRailed name.  It would serve no purpose any
longer, if the project were to far surpass RoR in feature/function/acceptance.

>> To get there we need to surmount some hurdles. This is simply an
>> overview, not a detailed analysis:
>>
>> 1) D is a statically compiled language; it doesn't have the
>> late-binding support of a language like Ruby or Python. We need to
>> find a way of enabling late-binding of code & symbols, in a manner
>> that is seamless to a user/developer. DDL is a project targeted at
>> exactly this issue, but it's a thorny problem to address. Some help
>> from the compiler itself would go a long way to making this a reality
>> (on linux, this currently appears to be resolvable).
>>
>> 2) Full reflection at run time is something D lacks. We need this to
>> properly enable late-binding to the extent we feel is needed. There's
>> a side-project under way right now to address this particular issue.
>>
> This would be nice, one problem domain I seem to run into is getting
> all of the fields + their types of a struct. Something like
> for(field in struct)
>     field.'get type'
> would help my cause a lot.

http://www.dsource.org/forums/viewtopic.php?t=2283

Specifically, what you're searching for is tupleof:

# class Model(T) : IModel {
#     IField[] fields;
#     this() {
#         T self = cast(T)this;
#         foreach (i, f; self.tupleof) {
#             static if (is(typeof(f) : IField)) {
#                 self.tupleof[i] = new typeof(f);
#                 this.fields ~= self.tupleof[i];
#             }
#         }
#     }
}

>> 3) a GUI front end, capable of being generated on the fly, yet
>> sufficiently powerful and extensible. We've been investigating various
>> existing technologies and approaches.
>>
> Like others I'm really not sure where this is going. If it's about html
> generation I have a few ideas on it.
>> 4) A back-end interface, to the DB. DDBI currently looks like a
>> reasonable solution, and there's  work currently under way to make it
>> much more useful.
>>
> I fully understand DDBI's intent (to bring a common database idiom over
> to D (I couldn't count the languages that have a similar syntax), but it
> does tend to be cumbersome when looking at derailed. The binding
> experience they've already plowed through will be invaluable though ;)
>> 5) A runtime platform, with clustering support. We can leverage
>> various tools from the Mango project.
>>
> may google zed shaw and mongrel to get some information on some ideas
> pertaining to this?
>> The big question for us right now is this: in what manner might a
>> compile-time DSL (or set thereof) make life significantly easier for
>> either a user/developer, or for us whilst constructing this tool?
>>
>> The DSL(s) in question should adhere to all the usual stipulations
>> about being transparent, working cleanly with a debugger etc. They
>> would also have to provide value above and beyond what might be
>> enabled by a separate (non compile-time) domain-specific tool. To
>> illustrate, one DSL suggestion might be some limited form of GUI?
>> However, there are better tools available for exactly that domain,
>> which expose a richer environment than we could hope to achieve via a
>> compile-time implementation. Please keep this particular aspect in mind.
>>
> I'm coming from an activerecord point of view, (I'm trying to look into
> that aspect first), and personally I don't think there needs to be a dsl
>  for it. Well, maybe a little:), but I'll come to that in a second.
> 
> 
> Actually, mid draft I threw something together
> http://www.dsource.org/projects/tango/wiki/DeActive
> Give it a looksee.
> 
> 
>> What do you think? Can you come up with something?
> 
> 
> 



More information about the Digitalmars-d mailing list