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

Reply via email to