WPF philosophy

barby · July 10, 2008, 4:28am

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

barby · July 10, 2008, 10:25am

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
Padhttp://www.codeplex.com/DlrPad(XAML Pad with DLR scripting).

Regards,
Stefan

2008/7/10 Ivan Porto C. [email protected]:

barby · July 10, 2008, 11:26am

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.CallSite1.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: [email protected]