Ayende @ Rahien

Stefan Wenig commented on Challenge: C# Rewriting

Wed, 18 Mar 2009 09:31:49 GMT

I read that wrong, I thought you were talking about extending C# with _additional_ tooling, but this is about compiling code snippets from text fields, right? Now everything makes sense, sorry for being so balky. I still have reservations about not having a schema for the actual data though. The view makes up the schema, alright. But the view is created upon existing data, which _should_ comply to one or more schemas (whether explicit or implicit), unless the view code is completely heuristic. That's a general problem that I have with schema-less data though. You avoid n schema migrations, but you have to deal with n versions of your data in the latest version of your code. But maybe that's just me being too enterprisey ;-)

Ayende Rahien commented on Challenge: C# Rewriting

Sun, 15 Mar 2009 19:47:07 GMT

Yes, I do want to compile this

Andrey Shchekin commented on Challenge: C# Rewriting

Sun, 15 Mar 2009 19:01:26 GMT

Ok, I read the CouchDB docs and it seems I understand the situation now. Another question -- so you need a preprocessor since you do not only need to infer a schema, you also actually want to compile this (optionally using PLINQ or whatever)? Otherwise you could just go with NRefactory without a compile step at all?

Ayende Rahien commented on Challenge: C# Rewriting

Sun, 15 Mar 2009 09:00:35 GMT

Andrey, there _is_ no schema. It is the view that defines the schema, and trying to define it twice is a waste of time.

Andrey Shchekin commented on Challenge: C# Rewriting

Sun, 15 Mar 2009 08:55:26 GMT

I would never want to do this. Did you like object-typed parameter in ASP.NET MVC? Dynamics (compile-time or runtime) are are problem waiting to happen. Just use a generator to get a typed interface from the existing schema (you can easily do it through the pre-compile step), then compile this code referencing the generated interface. If the DB has to be completely separated from this code, just extract some kind of schema from the DB (automatically), then generate an interface based on this schema.

Stefan Wenig commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 14:11:52 GMT

Of course it is, that's just how they are wired. "Hey, this looks useful - can we make it internal?" But making a framework's guts internal is one thing. While I don't agree with this default, at least they have given some good reasons. But binding a language's data access syntax to a non-virtual method of a concrete class is just ... unbelievable. I can't even access XML data without loading it into an XElement first. There goes the idea of VB being my favorite DSL for XML ... at least the more interesting part of it.

Ayende Rahien commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 12:55:41 GMT

Stefan, I actually got to talk with the guy who implemented that feature not long ago. That was an intentional decision on Microsoft part. They did not want to deal with supporting this extensibility story.

Stefan Wenig commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 12:49:23 GMT

BTW, I just checked whether VB's XML support could help out here. The syntax doc.Type == page would become doc.@Type = page in VB. That looks good enough (although only for string values, I didn't look any further). However, VB's XML literals are unneccesarily bound to the XElement type (and some related types). The resolution of .@Type is done via an extension method (AttributeValue) that VB will define for any assembly that uses those XML literals, but it will not use a user-provided method for other types. Also, the relevant methods in XElement are not virtual. (There might be a hack when you reach really deep into the data structures of XElement, but that's a place where I don't want to be.) Unbelievable.

Stefan Wenig commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 09:15:10 GMT

I guess I'll have to wait for the answer to that challenge before I have a chance to understand your answers to my comments. I was not trying to answer your question. Although it sounds interesting, I don't know the first thing about NRefactory and I'm lazy, so I'll just wait for the answer and _then_ go look into NRefactory. Neither was I changing the parameters of the question. I got off on a tangent about an alternative solution using interfaces with some other readers. And I made a general comment about whether the solution, as you defined it, would be worth a modification to the tool chain. I have thought about transformations in some cases where C# is unneccessarily limited (attribute argument types, for instance), and a simple precompiler step could bring huge benefits. Still, modifying the tool chain is a problem itself, and I finally decided not to do it. But that''s not a relevant discussion if this is considered a challenge just for fun, so feel free to ignore my comments ;-)

Ayende Rahien commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 07:21:45 GMT

configurator, You are confusing the db side code and the client side code. They are not in sync, not kept together and in general should be separated. As such, when defining a view, having to define an interface for the view is redundant and violate DRY. And yes, I am doing things that the language was never meant to do. That is part of the fun, because the _end result_ is going to be worth it.

Ayende Rahien commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 07:13:00 GMT

Stefan, No, this is not a trick question. The problem is that when trying to change the parameters of the question, you are not aware of the context in which it is going to operate, so you are making the wrong assumptions. There is going to be a pre compiler step anyway, so the objection about not having to change the tool chain is not valid. At that point, you might as well squeeze the most out of this operation, because good syntax _matter_.

configurator commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 03:51:55 GMT

If I understand you correctly, what you want is for all documents to always be dynamically bound (i.e. C# 4 type dynamic), never accessing them anyway else. I can't shake the feeling that you are trying to coerce the language into something that it is not - a late-bound language. If you want a late-bound language, use VB or C# 4.

configurator commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 03:49:26 GMT

I don't see how defining a property is a violation of DRY. Is that property defined anywhere else? In the document itself, of course, but wouldn't the producer of the document (i.e. the same program) need the exact same interface anyway? What good is a document that you can't access? And you can't access the document if you don't have an interface to access it with.

Stefan Wenig commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 01:18:50 GMT

As some people already pointed out, your first example will compile if you statically define an interface for doc. The advantage would be that you don't have to modify the tool chain (i.e., precompile C#). I'm just saying that this will compile, but you still need to implement that interface (either statically or dynamically) in order for this code to work at run time. (As for the rest of our answer: is this some kind of trick question where the real challenge is figuring out what the rules of the game are? I thought you're asking for that precompiler?)

Ayende Rahien commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 01:04:53 GMT

Stefan, I think that you are missing something, because I haven't explained it. There _isn't_ anything else here. Literally. The code on this post is all the code that is required to create a view. You are not going to be able to use standard tools anyway.

Ayende Rahien commented on Challenge: C# Rewriting

Sat, 14 Mar 2009 01:00:03 GMT

configurator, I don't want to do that, I see this as a violation of DRY.

Stefan Wenig commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 23:31:49 GMT

Confusing your whole tool chain - from R# to the debugger and back - with a small precompilation trick sounds bad enough. The verbose version is not _that_ bad after all. But dismissing the whole notion of defining interfaces (or schemas for that matter, where's the difference) as a violation of DRY? Anyway, just defining the interfaces would not get you working code.. You might want to consider the XML features of VB (import

yug commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 21:07:34 GMT

I agree with configurator, wouldn't touching the LINQ expressions be easier than introduction another layer of complexity?

Tuna Toksoz commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 19:54:39 GMT

Looks similar to what we used to do with NH Linq :)

configurator commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 19:49:21 GMT

Ayende, I suggest rewriting the linq expressions, and not the C# code. The pro is that no precompilation rewriting is necessary. The con is that some interface has to be defined - but only so that the code will compile.

Ayende Rahien commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 17:31:55 GMT

Jan, The second syntax is uglier, and it exposes implementation details that I would rather not have. The idea is to get a nicer syntax for things.

Ayende Rahien commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 17:30:11 GMT

Frank, I am not sure how you would get this to compile against "any old interface", when you don't know what the interface is in the first place.

Ayende Rahien commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 17:28:50 GMT

Josh, Yes, it would. But Boo doesn't have full Linq support yet, and in this case, Linq really IS the best syntax for this.

Ayende Rahien commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 17:27:57 GMT

Justin, Yes, I know. I am not willing to be tied to C# 4.0

Ayende Rahien commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 17:27:20 GMT

Andrew, That is too much work. The data is already there, having to specify it twice is violation of DRY

Ayende Rahien commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 17:26:14 GMT

Nathaniel, Take a look at the view syntax, vs. the couch db syntax. I find that linq make this a LOT simpler. It is also resolving a lot of problems relating to how to create indexed views without schema.

Ayende Rahien commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 17:24:58 GMT

Roy, Not really. If you pound C# hard enough, you can generate dynamics.

Hüseyin Tüfekçilerli commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 17:15:32 GMT

Here: [http://snipt.org/KP](http://snipt.org/KP) Transforms the example above but there is no guarantee that it will work for anything slightly different :)

Jan Limpens commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 16:41:47 GMT

I actually prefer the second, compiling expression. It is more obvious what is happening and as doc.Title will not give me intellisense anyway, whats the motive of this syntax sugar? When I first read this in the other post, I assumed that doc.Title was a regular property every doc has.

Frank Quednau commented on Challenge: C# Rewriting

Fri, 13 Mar 2009 16:09:41 GMT

Interestingly it's an expression. You could write against any ol' interface, parse the expression and create a new one that looks like the second. Alternatively a regular expression should work well :)