Forum: IronRuby Re: Overriding CLS Virtuals

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Curt H. (Guest)
on 2008-10-25 04:54
(Received via mailing list)
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: 'removed_email_address@domain.invalid'
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.
Ted M. (Guest)
on 2008-10-25 05:12
(Received via mailing list)
On Fri, Oct 24, 2008 at 7:54 PM, Curt H. <removed_email_address@domain.invalid>
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.
Michael L. (Guest)
on 2008-10-25 05:28
(Received via mailing list)
Do it. :)
Mike M. (Guest)
on 2008-10-25 06:01
(Received via mailing list)
On Fri, Oct 24, 2008 at 6:54 PM, Curt H.
<removed_email_address@domain.invalid>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.
Mike M. (Guest)
on 2008-10-25 06:09
(Received via mailing list)
On Fri, Oct 24, 2008 at 7:11 PM, Ted M. <removed_email_address@domain.invalid> 
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". :)
Orion E. (Guest)
on 2008-10-26 06:15
(Received via mailing list)
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.
Ted M. (Guest)
on 2008-10-26 06:41
(Received via mailing list)
On Sat, Oct 25, 2008 at 6:59 PM, Orion E.
<removed_email_address@domain.invalid> 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.
Curt H. (Guest)
on 2008-10-26 07:25
(Received via mailing list)
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".
Ted M. (Guest)
on 2008-10-26 08:23
(Received via mailing list)
On Sun, Oct 26, 2008 at 12:20 AM, Curt H. <removed_email_address@domain.invalid>
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. :)  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?
Mike M. (Guest)
on 2008-10-26 09:37
(Received via mailing list)
On Sat, Oct 25, 2008 at 11:20 PM, Curt H.
<removed_email_address@domain.invalid>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.
Jim D. (Guest)
on 2008-10-26 09:43
(Received via mailing list)
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: removed_email_address@domain.invalid
[removed_email_address@domain.invalid] On Behalf Of Ted M.
[removed_email_address@domain.invalid]
Sent: Saturday, October 25, 2008 11:12 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Overriding CLS Virtuals

On Sun, Oct 26, 2008 at 12:20 AM, Curt H. <removed_email_address@domain.invalid>
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. :)  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
removed_email_address@domain.invalid
http://rubyforge.org/mailman/listinfo/ironruby-core
Jay McGaffigan (Guest)
on 2008-10-26 14:59
(Received via mailing list)
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.
This topic is locked and can not be replied to.