Let's say that w is a WPF window. That is, w = System::Windows::Window.new
Then you can currently get the actual height of the window by saying either w.ActualHeight -or- w.actual_height. This is something that we don't intend to change. The nature of a dynamic call site is such that the method lookup is deferred until the point this code is reached, and then we're free to bind the actual call target using whatever semantics we please. We don't even have to pay any real overhead for this ability, because we cache the result of the lookups after they were made the first time and don't have to perform them again. (Window *is* after all, a *static* type. :) However, virtual calls from a C# application back into IronRuby are a different matter, due Ruby's dynamic nature. Here there is both a performance cost and a semantic cost for performing multiple lookups. The performance cost results from the fact that we have to check for two different symbol names on every CLS call to this method before we can identify that we need to delegate to the base class implementation. (To be fair, this, too could be cached, albeit with slightly greater difficulty.) The semantic cost is based in the confusion resulting when methods with both names are defined on the class. Should we call method "dispose" or method "Dispose"? or both? Finally, as you're probably aware by now, capitalization in Ruby is not simply a matter of convention. In many cases, the parser actually treats identifiers which start with a capital letter differently than it does identifiers that start lower case. Now it turns out that method names are one of the places where Ruby doesn't draw this distinction, but I'd guess that many Ruby programmers look at any identifier starting with a capital letter and think "that's a constant". -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Milker Sent: Saturday, October 25, 2008 9:35 PM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] Overriding CLS Virtuals On Sat, Oct 25, 2008 at 6:59 PM, Orion Edwards <[EMAIL PROTECTED]> wrote: > While none of the languages will stop you from using any conventions you > like, it's MUCH easier to learn to put your ego aside, and go with the > conventions. I agree, however, the DLR adds a twist to the formula. > The simple fact is, you're going to be reading loads of sourcecode written > by others in the form of examples and so forth, and if you get annoyed every > time you see stuff you 'hate' - well you're going to be having a pretty > unhappy time. I do not get annoyed if I am reading or programming in a single language. I do like to keep things simple though. If I am working in .NET, I am going to keep a single, consistent style convention for my source code. I am not going to maintain two different conventions just because I am using Ruby in half of my app and C# in the other. Even if it were pure Ruby in IronRuby, I would use .NET guidelines because I am almost certain to be using the .NET libraries in IronRuby. In this case and in my opinion, the framework determines the convention, not the languages used. One of the main reasons why I am interested in IronRuby is because it will give me access to WPF. GUIs with Ruby in Windows, I have learned, is a pretty painful and overall annoying experience compared to C# and WPF. I do have a particular dislike for the underscore key because of its placement on the keyboard as well. _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
