Re: Overriding CLS Virtuals

Ruby IronRuby
1

We’re thinking now that we’re going to go with the mangled version of
the name instead of the originally cased-version. “Dispose” just
doesn’t look Rubyish enough. Any objections?

From: Curt H.
Sent: Monday, September 08, 2008 9:22 PM
To: ‘[email protected]’
Subject: Overriding CLS Virtuals

I’ve committed some changes to IronRuby (in SVN revision 141) that let
you implement CLS interfaces and override virtual methods on CLS base
types. Interfaces work like Ruby modules, so to make your class
implement IDisposable you could say

require ‘mscorlib’
class Disposable
include System.IDisposable
def Dispose
# Do something
end
end

You can also override virtual properties. A class or interface that has
the C# declaration “string Value { get; set; }” is overridden from
IronRuby with methods named “Value” for the getter and “Value=” for the
setter.

Note that you need to use the same casing as the CLS definition for both
methods and properties.

We’re just getting started with better .NET interop support and don’t
have very much test coverage yet - but this should let you get going on
some more sophisticated interop scenarios than were previously possible.

2

On Fri, Oct 24, 2008 at 7:54 PM, Curt H. [email protected]
wrote:

We’re thinking now that we’re going to go with the mangled version of the
name instead of the originally cased-version. “Dispose” just doesn’t look
Rubyish enough. Any objections?

My opinion does not count for much but I love Ruby openness and hate
the naming conventions. I much prefer camel case and .NET guidelines
for naming than underscore and lowercase hell. I am just getting
started with Ruby and have no intention of following the naming
conventions if I can avoid it. IronRuby and .NET are my platform of
choice for the future, even in its immature state.

3

Do it. :slight_smile:

4

On Fri, Oct 24, 2008 at 6:54 PM, Curt H.
[email protected]wrote:

We’re thinking now that we’re going to go with the mangled version of the
name instead of the originally cased-version. “Dispose” just doesn’t look
Rubyish enough. Any objections?

No objections. I’d prefer def dispose; end over def Dispose; end.

5

On Fri, Oct 24, 2008 at 7:11 PM, Ted M. [email protected] wrote:

I much prefer camel case and .NET guidelines for naming than underscore and
lowercase hell.

You’d like it better if you’d call it “snake case”. :slight_smile:

6

On Sat, Oct 25, 2008 at 6:59 PM, Orion E.
[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.

7

I used to think this kind of thing too.

Each language (or large-subset-of-language) has it’s own conventions.

Examples:

gnu/posix C: lower_underscore_case
Microsoft C (eg the win32 api): UpperCamelCase
Java: lowerCamelCase
Javascript: lowerCamelCase
.NET: UpperCamelCase (except local variables which seem to be
lowerCamelCase)
ruby/python: lower_underscore_case

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.

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.

8

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. :slight_smile:

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”.

9

On Sat, Oct 25, 2008 at 11:20 PM, Curt H.
[email protected]wrote:

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”.

Agreed. That’s what I think when I see that.

10

On Sun, Oct 26, 2008 at 12:20 AM, Curt H. [email protected]
wrote:

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?

This is a tough one, glad I do not have to make the call. Pitfalls
and trouble every way I try to think of it and type a response. :slight_smile: My
gut tells me that capitalization matters, regardless of The Ruby Way,
when it comes to .NET. If you want to write a new Dispose, def
Dispose.

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”.

But given the following:

def Foo
“Bar”
end

Foo()

what Ruby programmer would look at Foo and still think it is a
constant? Of course, if I would have made it lowercase, the
parentheses would not be necessary. My point is that the parentheses
tell the reader that it is not a constant, but a method. Is there a
situation where Foo could appear legally, as defined above, without
parentheses and be confused for a constant?

11

With respect to conventions the dynamic languages are the first
languages
that I’ve used that can actually depend on the casing (and
pluralization) to
work right (think active record models). Now it’s no longer part of the
“readability” factor of code but it can play an important part in how a
DSL
works.

Jay

On Sat, Oct 25, 2008 at 7:59 PM, Orion E.

12

The parenthesis do give an important clue, and luckily they are required
for calling a method with a constant identifier. As far as idioms and
conventions go, I don’t know how much of an official convention (as much
as a Ruby convention is official) there is, but the few cases of
capitalized methods I’ve seen do one of two things, cast to the name of
the method (Kernel.Float for example) or they return a class. An example
of the second is the R() method in _why’s Camping framework, which
returns a class for controllers. It’s used in class definitions in this
case:

class Foo < R(‘/’)
end

is a controller at the route / (root of the website). So since I’m used
to that, I prefer seeing IDisposable use def dispose in my Ruby classes.

JD

From: [email protected]
[[email protected]] On Behalf Of Ted M.
[[email protected]]
Sent: Saturday, October 25, 2008 11:12 PM
To: [email protected]
Subject: Re: [Ironruby-core] Overriding CLS Virtuals

On Sun, Oct 26, 2008 at 12:20 AM, Curt H. [email protected]
wrote:

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?

This is a tough one, glad I do not have to make the call. Pitfalls
and trouble every way I try to think of it and type a response. :slight_smile: My
gut tells me that capitalization matters, regardless of The Ruby Way,
when it comes to .NET. If you want to write a new Dispose, def
Dispose.

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”.

But given the following:

def Foo
“Bar”
end

Foo()

what Ruby programmer would look at Foo and still think it is a
constant? Of course, if I would have made it lowercase, the
parentheses would not be necessary. My point is that the parentheses
tell the reader that it is not a constant, but a method. Is there a
situation where Foo could appear legally, as defined above, without
parentheses and be confused for a constant?

Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core