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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080710/3a93d719/attachment.html>
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>(XAML Pad with DLR scripting). Regards, Stefan 2008/7/10 Ivan Porto Carrero <ivan at flanders.co.nz>:> 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 > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080710/f3e75c27/attachment.html>
Robert Brotherus
2008-Jul-10 09:19 UTC
[Ironruby-core] Accessing CLR-class methods/properties/fields
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<object>>("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 Brotherus
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: Robert.Brotherus at napa.fi
www.napa.fi