Jacob Carlborg wrote: > But that way you would need to declare different types of Options > structs all over the place?
Sometimes, but most functions are fine with regular argument lists, to me, using enums for options where appropriate. > I think there are other languages available that is far better than > PHP that you could compare with instead. Ruby on Rails: Come to think to fit, PHP's $_REQUEST() would have worked here too and shaved off a couple lines. Anyway, I've used Ruby before, but never Rails. The to_i and to_s things are familiar.. me forgetting to write them caused many problems in that project. I hate dynamic languages so much. That Ruby project is what put the nail in the coffin. I want to get an idea of how Rails works though, so see how well my approaches stack up. But, aside from discussions like this one, I haven't had a chance to get into it. > This will try to find a Post with the given id and automatically > converted the given value to an integer. This is similar to how my database libs work. It actually lets the database do the conversion though. > I've been thinking for a while to try and create something > similar as Rails' ActiveRecrod for D but every time I tried to do > it turns out to work quite badly with a static type system. Have you seen Piotr Szturmaj's Postgres code? http://www.digitalmars.com/d/archives/digitalmars/D/learn/D2_postgresql_interface_-_Phobos2_23693.html#N23695 (there's more posts than that on it too if you search) It might give you some ideas. I went the other way; I don't mind writing SQL. (I always find automatic mappings the other way to be inefficient and lacking anyway.) > As I said above, I don't see the big advantage if I have to use > Variants all over the place . The thing is it's not *all* over the place. There's a small area where you use them, and you get the static type benefits everywhere else. Even with the variant areas, the static type system helps a little bit. At least misspelled variable names are caught ahead of time by the compiler. > HAML, generates HTML - http://haml-lang.com/ Syntax and indenting aside, concepturally, that's similar to how my DOM based code works. auto profile = holder.addChild("div").className("profile"); auto left = profile.addChild("div").className("left column"); left.addChild("div", print_date).id("date"); left.addChild("div", current_user.address).id("address"); One big difference, semantically, is my code always escapes HTML by default. Looks like haml uses &= for escaping, while = does not.... so their homepage example is both incorrect and open to XSS attacks! (I offer two ways to write HTML: some functions take arguments of type Html, like Table.appendRow: table.appendRow(" ", Html(" ")); First column appears as literally . Second column shows up as a non breaking space. But, mostly, if you want to mess with html, you use the innerHTML property. It's a pain to use because outputting HTML is, 9 times out of 10, wrong. Any template system that doesn't do this gets a big point against it in my book, similarly to any database library that makes mixing unescaped text in the easiest way...) Anyway, their syntax is certainly brief. I can see the appeal in that. Curious though, how does haml handle forms? Looking through the documentation, it doesn't seem to at all. This is one of the nicest things about my DOM approach. You can write the form in standard HTML, with default values written there if you want, and the code will fill it in later. > * SASS, generates CSS - http://sass-lang.com/ (I'm using the sass > syntax and not the scss syntax) Heh, I looked at that not long ago. I'm annoyed by CSS's lack of nesting. Not annoyed enough to introduce Ruby to the project, although I rather like what they did here. I'll probably spin my own version eventually. > * CoffeeScript, generates JavaScript - Eh, I thought about something along these lines, write some of it, but I decided against going far with it. There's two reasons: a) If you're writing enough Javascript to make using a replacement worth it, you're writing too much Javascript. b) Javascript's biggest problem is that it's loosely and dynamically typed, not that it's whitespace is ignored. The auto-generated javascript to access my D code make using it almost easy anyway http://arsdnet.net/cgi-bin/apidemo/javascript <button onclick=" CoolApi.getABox('green').appendTo('playground'); " type="button">Get a green box</button> Those are all basic examples. The idea is the server does most the work, and Javascript simply plugs it in somewhere in the document - the same way the page is built on the server side. appendTo's argument can be a string for a trivial ID or an element as returned by any of the built in browser functions (such as querySelector - no need to load up a big piece of shit like jQuery to have that.) The generic get() function does partial application so it's reusable with other functions: function fadeIn(parent, speed, html) { ... } CoolApi.getABox('green').get(fadeIn, this.parentNode, 10); Since the server might return data, such might not always work. That's where the format modifier comes in: CoolApi.getPeople(0).format('table').get(fadeIn, this.parentNode, 10); Thus, javascript functions become fairly trivial and/or reusable, so you don't have to deal with the language very much at all. I also toyed with generating Javascript from D: auto js = new ClientSideScript(); js.alert("Hello, world!"); js.var("wat") = 10; js.alert(js.wat); That kind of thing. Each method call to the js object builds a code string inside it. D variables passed as arguments are converted to Javascript literals and added to the code. It actually kinda works, and I use it from time to time, but only for little things. For the big, I don't think it's worth it.
