# WPF philosophy

**URL:** <https://www.ruby-forum.com/t/wpf-philosophy/142660>\
**Category:** IronRuby\
**Created:** [July 10, 2008, 4:28am UTC](https://www.ruby-forum.com/t/wpf-philosophy/142660 "2008-07-10T04:28:46Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![barby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@barby](https://www.ruby-forum.com/u/barby)\
**Post date:** [July 10, 2008, 4:28am UTC](https://www.ruby-forum.com/t/wpf-philosophy/142660/1 "2008-07-10T04:28:46Z")

</div>

Hi

I don’t really know if this is an appropriate discussion but here it  
goes.

Ruby and Xaml at first sight a DSL is very appropriate to get rid of the  
xml  
syntax. I’m all for that 🙂 However the price you pay is that at that  
moment  
only developers can change the design of the application. Blend will  
happily  
refuse to load it for example which makes it a bad idea for projects  
that  
are developed by a designer and a developer IMHO. What I do see  
happening is  
and what I’ll use in my chapter is smallish additions, control  
instantiation  
and code generation dsl’s at functional places in the application.  
With a DSL you also loose skinning support and the lot. I would be very  
happy to be proven wrong though :).  
There are a lot of other places where DSL’s really work like setting up  
timers, threads and those things.

Furthermore because xaml controls exist in the statically typed part of  
the  
.NET universe it’s pretty hard to have controls written in Dynamic  
languages. I started the Dynamic script control that allows you to  
inject a  
DLR based control in a XAML tree. I didn’t have time to fully fix it but  
it  
does work to a certain degree. One of the problems I have there is that  
I  
could not get to the controls inside the dyn script control anymore, the  
reason is unknown to me at this time. I put that on the back burner for  
now  
as I have to make more progress on my book but intend to fully finish  
that  
control when my book is finished if nobody else has done one by then or  
you  
tell me you will have something like that when IR goes 1.0. I think it  
would be great to be able to use DLR controls with similar paradigms as  
their CLR cousins.

Then another avenue I’ve been thinking about is a couple of rake tasks  
that  
will take a control tree and spit out the CLR based control with stub  
event  
handlers etc so that a designer can still change it but the real  
implementation of the event handlers occurs in a monkey patched version  
of  
that control. This should give you the best of both worlds because you  
don’t  
need to venture into C# while retaining full tooling support. A downside  
to  
this approach is that you will always have a compilation step after you  
make  
a change to the design of a control. This is the approach the guys of  
rucola (a rails like framework for rubycocoa) are taking with interface  
builder. While blend is no interface builder there are some  
similarities.

A last approach I have in mind but I tend to think that this is a bad  
one 🙂  
A XAML template engine. I think its a bad idea because you lose  
everything  
designer support, databinding and dsl niceness.

As a conclusion I think I would probably favor a mixture of approach 1-3  
with approach 3 being the predominant one and approach 1-2 when needed.  
Thougths?

Thanks  
Ivan

---

<div class="post-metadata">

**Author:** ![barby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@barby](https://www.ruby-forum.com/u/barby)\
**Post date:** [July 10, 2008, 10:25am UTC](https://www.ruby-forum.com/t/wpf-philosophy/142660/2 "2008-07-10T10:25:41Z")

</div>

I have also thought of similar ideas. However mine were more code  
centric,  
not XAML.

For example if you want to create a DependecyProperty or RoutedEvent you  
have to write a lot of code in a static language like  
DependecyProperty.Register(…) and you end up with something like 20  
lines  
of code including all the property changed, coerce, validate handlers.  
This  
can be a lot simpler in a dynamic language like ruby when you can have  
approach similar to rails’ active record: has\_many: or belongs\_to:

I think we should try to avoid going away from XAML, because this is our  
common language with designers. They live in tools like Blend and even  
Visual Studio is cumbersome for some of them. What we can have there is  
some  
kind of ruby markup extension that will allow us to do dynamic dispatch  
or  
something similar.

P.S.: You can check a simple “still buggy” tool I have developed DLR  
Pad[http://www.codeplex.com/DlrPad](http://www.codeplex.com/DlrPad)(XAML Pad with DLR scripting).

Regards,  
Stefan

2008/7/10 Ivan Porto C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![barby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@barby](https://www.ruby-forum.com/u/barby)\
**Post date:** [July 10, 2008, 11:26am UTC](https://www.ruby-forum.com/t/wpf-philosophy/142660/3 "2008-07-10T11:26:51Z")

</div>

Consider following C# program (ScriptService.SharedService provides  
access to IronRuby and is unimportant for understanding the case):

* * *

using System;  
using System.Diagnostics;  
using Fi.Napa.Gui;

public class A  
{  
public string SomeField = “field”;  
public string SomeProperty { get { return “prop”; } }  
public string SomeMethod() { return “method”; }  
}

class Program  
{  
static void Main(string[] args)  
{  
ScriptService.SharedService.ExecuteStr(@"  
def test(obj)  
Debug::print ‘In Ruby’  
Debug::print obj.some\_method  
Debug::print obj.SomeMethod  
Debug::print obj.send(:some\_method)  
Debug::print obj.send(:SomeMethod)

```
            Debug::print obj.some_property
            Debug::print obj.SomeProperty
            Debug::print obj.send(:some_property)
            Debug::print obj.send(:SomeProperty)

            Debug::print obj.SomeField
            Debug::print obj.some_field
            Debug::print obj.send(:SomeField)
            Debug::print obj.send(:some_field)
        end
    ");

    Action<object> test =

```

ScriptService.SharedService.ExecuteStr\<Action\>(“method(:test)”);

```
    try {
test(new A()); // Call the Ruby "test"-function with

```

instance of A as parameter  
}  
catch (Exception ex) { Debug.Print(ex.ToString()); }  
}  
}

* * *

Output of the program is:

In Ruby  
method  
method  
method  
method  
prop  
prop  
prop  
prop  
field  
field  
A first chance exception of type ‘System.ArgumentException’ occurred in  
Unknown Module.  
System.ArgumentException: wrong number or type of arguments for  
`SomeField' at _stub_$27##27(Closure , CallSite , CodeContext , Object , RubyArray ) at _stub_MatchCaller(Object , CallSite , Object[] ) at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[]  
args) in  
C:\programs\IronRuby\trunk\src\Microsoft.Scripting.Core\Actions\CallSite  
.cs:line 288  
…  
at System.Void(Object)(Object[] , Object )  
at Program.Main(String[] args) in  
C:\DATA\IronRubyIssueX\IronRubyIssueX\Program.cs:line 38

* * *

This indicates that CLR-class fields (unlike CLR-methods and  
CLR-properties) cannot be accessed with ruby:s send-method although they  
are directly accessible as ruby-methods:

Debug::print obj.SomeField # ok  
Debug::print obj.some\_field # ok  
Debug::print obj.send(:SomeField) # Exception: wrong number of  
arguments for method SomeField  
Debug::print obj.send(:some\_field) # Exception: wrong number of  
arguments for method some\_field

I would expect that in final IronRuby 1.0 CLR-interoperability the  
syntaxes a.x and a.send(:x) would always work the same, regardless of a  
and x. I assume this is the intention of IR team as well?

Also I am intrigued by the type of the exception: “wrong number or type  
of arguments for `SomeField’”. Does that indicate that the fields  
_could_ still be accessed with the send-method with some additional  
arguments…?

Robert B.  
Software architect  
Napa Ltd  
Tammasaarenkatu 3, Helsinki FI-00180  
P.O.Box 470, Helsinki FI-00181  
Tel. +358 9 22 813 1  
Direct. +358 9 22 813 611  
GSM +358 45 11 456 02  
Fax. +358 9 22 813 800  
Email: removed\_email\_address@domain.invalid

> **[Home – NAPA](https://www.napa.fi/)**
>
> NAPA provides intelligent solutions for maritime industry: Software, Services and Data Analysis for Ship Design and Operation. We combine naval architecture, shipping and digital expertise to help maritime business make the decisions that matter.