Re: [Ironruby-core] Overriding CLS Virtuals
On Sun, Oct 26, 2008 at 12:20 AM, Curt Hagenlocher [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. :) 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 Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
Re: [Ironruby-core] Overriding CLS Virtuals
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 Milker [EMAIL
PROTECTED]
Sent: Saturday, October 25, 2008 11:12 PM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] Overriding CLS Virtuals
On Sun, Oct 26, 2008 at 12:20 AM, Curt Hagenlocher [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. :) 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
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
Re: [Ironruby-core] Overriding CLS Virtuals
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 Edwards [EMAIL PROTECTED]wrote: 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. On 25/10/2008, at 2:11 PM, Ted Milker wrote: On Fri, Oct 24, 2008 at 7:54 PM, Curt Hagenlocher [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. ___ 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 ___ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
Re: [Ironruby-core] Unicode Source Files
We do this for compatibility with Ruby 1.8.6, though as you can see, we don't have the error message quite right: PS F:\ C:\ruby\bin\ruby.exe x.rb x.rb:1: Invalid char `\377' in expression x.rb:1: Invalid char `\376' in expression :) I believe you'll need to save as UTF-8 and then manually strip the BOM in order to use Unicode source files -- hopefully Tomas will tell me if I'm wrong. Source encoding for Ruby is extremely tricky, and (from what I can tell) hasn't even yet been finalized for 1.9.x. We will eventually support whatever the Ruby standards are. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Milker Sent: Sunday, October 26, 2008 9:38 AM To: ironruby-core@rubyforge.org Subject: [Ironruby-core] Unicode Source Files Is the DLR going to be fixed so that it properly supports Unicode source files or is this an issue with IronRuby? If you attempt to create a new Code File with Visual Studio 2008 and call it test.rb and then execute it with: ScriptRuntime runtime = IronRuby.Ruby.CreateRuntime(); runtime.ExecuteFile( test.rb ); it blows up on the Unicode byte-order marker with: Unhandled Exception: Microsoft.Scripting.SyntaxErrorException: Invalid character 'ï' in expression at Microsoft.Scripting.ErrorSink.Add(SourceUnit source, String message, SourceSpan span, Int32 errorCode, Severity severity) in C:\Users\ted\Desktop\IronRuby\src\Microsoft.Scripting\ErrorSink.cs:line 34 at Microsoft.Scripting.ErrorCounter.Add(SourceUnit source, String message, SourceSpan span, Int32 errorCode, Severity severity) in C:\Users\ted\Desktop\IronRuby\src\Microsoft.Scripting\ErrorSink.cs:line 92 at IronRuby.Compiler.Tokenizer.Report(String message, Int32 errorCode, SourceSpan location, Severity severity) in C:\Users\ted\Desktop\IronRuby\src\ironruby\Compiler\Parser\Tokenizer.cs:line 430 at IronRuby.Compiler.Tokenizer.ReportError(ErrorInfo info, Object[] args) in C:\Users\ted\Desktop\IronRuby\src\ironruby\Compiler\Parser\Tokenizer.cs:line 442 at IronRuby.Compiler.Tokenizer.Tokenize(Boolean whitespaceSeen, Boolean cmdState) in C:\Users\ted\Desktop\IronRuby\src\ironruby\Compiler\Parser\Tokenizer.cs:line 966 at IronRuby.Compiler.Tokenizer.Tokenize() in C:\Users\ted\Desktop\IronRuby\src\ironruby\Compiler\Parser\Tokenizer.cs:line 739 at IronRuby.Compiler.Tokenizer.GetNextToken() in C:\Users\ted\Desktop\IronRuby\src\ironruby\Compiler\Parser\Tokenizer.cs:line 711 at IronRuby.Compiler.Parser.GetNextToken() in C:\Users\ted\Desktop\IronRuby\src\ironruby\Compiler\Parser\Parser.cs:line 99 at IronRuby.Compiler.ShiftReduceParser`2.Parse() in C:\Users\ted\Desktop\IronRuby\src\ironruby\Compiler\Parser\GPPG.cs:line 310 at IronRuby.Compiler.Parser.Parse(SourceUnit sourceUnit, RubyCompilerOptions options, ErrorSink errorSink) in C:\Users\ted\Desktop\IronRuby\src\ironruby\Compiler\Parser\Parser.cs:line 158 at IronRuby.Runtime.RubyContext.ParseSourceCode(SourceUnit sourceUnit, RubyCompilerOptions options, ErrorSink errorSink) in C:\Users\ted\Desktop\IronRuby\src\ironruby\Runtime\RubyContext.cs:line 203 at IronRuby.Runtime.RubyContext.CompileSourceCode(SourceUnit sourceUnit, CompilerOptions options, ErrorSink errorSink) in C:\Users\ted\Desktop\IronRuby\src\ironruby\Runtime\RubyContext.cs:line 179 at Microsoft.Scripting.SourceUnit.Compile(CompilerOptions options, ErrorSink errorSink) in C:\Users\ted\Desktop\IronRuby\src\Microsoft.Scripting\SourceUnit.cs:line 215 at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink errorSink) in C:\Users\ted\Desktop\IronRuby\src\Microsoft.Scripting\SourceUnit.cs:line 225 at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) in C:\Users\ted\Desktop\IronRuby\src\Microsoft.Scripting\Hosting\ScriptSource.cs:line 129 at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteFile(String path, ScriptScope scope) in C:\Users\ted\Desktop\IronRuby\src\Microsoft.Scripting\Hosting\ScriptEngine.cs:line 159 at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteFile(String path) in C:\Users\ted\Desktop\IronRuby\src\Microsoft.Scripting\Hosting\ScriptEngine.cs:line 148 at Microsoft.Scripting.Hosting.ScriptRuntime.ExecuteFile(String path) in C:\Users\ted\Desktop\IronRuby\src\Microsoft.Scripting\Hosting\ScriptRuntime.cs:line 257 at HostingDLRConsole.Program.Main(String[] args) in C:\Users\ted\Documents\Visual Studio 2008\Projects\Books\IronRuby in Action\HostingDLRConsole\HostingDLRConsole\Program.cs:line 14 Press any key to continue . . . I know I can fix this by using the Advanced Save Options but the DLR spec talks about Unicode support, so I assume this means that ScriptRuntime.ExecuteFile() should also support Unicode source files. ___ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core ___ Ironruby-core mailing list Ironruby-core@rubyforge.org
Re: [Ironruby-core] Unicode Source Files
Here is the extension method I am using if anyone else is interested:
public static object ExecuteUnicodeFile( this ScriptRuntime rt, string
filename )
{
string rbCode;
// OpenText will strip the BOM and keep the Unicode intact
using( var rdr = File.OpenText( filename ) )
{
rbCode = rdr.ReadToEnd();
}
return IronRuby.Ruby.GetEngine( rt ).Execute( rbCode );
}
It works great for using Japanese in strings in Ruby with IronRuby and WPF.
___
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
Re: [Ironruby-core] Unicode Source Files
If you save in Western European (Windows) - Codepage 1252 from within Visual Studio, you'll get the right result -- as long as you're not using any characters with a codepoint greater than 127. And if you are, you're probably better off anyway expressing this code point as an explicit set of UTF-8 compatible bytes because -- as you've noticed -- Ruby's currently a bit weird in its Unicode support. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Milker Sent: Sunday, October 26, 2008 11:34 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] Unicode Source Files Why so rigorous? I understand the need to maintain compatibility but this effectively eliminates Visual Studio as an editor for .rb files, without some kind of clunky build mechanism. I guess I will just use an extension method to get around the behavior for the time being. From the things I have read about Ruby and UTF-8, it seems more like it is just extremely broken, rather than extremely tricky. I still cannot even get pure Ruby stuff in Windows to work properly with UTF-8, like when using the Shoes toolkit for example. On Sun, Oct 26, 2008 at 11:52 AM, Curt Hagenlocher [EMAIL PROTECTED] wrote: We do this for compatibility with Ruby 1.8.6, though as you can see, we don't have the error message quite right: PS F:\ C:\ruby\bin\ruby.exe x.rb x.rb:1: Invalid char `\377' in expression x.rb:1: Invalid char `\376' in expression :) I believe you'll need to save as UTF-8 and then manually strip the BOM in order to use Unicode source files -- hopefully Tomas will tell me if I'm wrong. Source encoding for Ruby is extremely tricky, and (from what I can tell) hasn't even yet been finalized for 1.9.x. We will eventually support whatever the Ruby standards are. ___ 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
Re: [Ironruby-core] Unicode Source Files
You can switch to 1.9 compat mode by passing -19 argument on command line. Tomas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Milker Sent: Sunday, October 26, 2008 1:57 PM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] Unicode Source Files On Sun, Oct 26, 2008 at 3:17 PM, Jim Deville [EMAIL PROTECTED] wrote: If you are able to solve this with an extension method, then it looks likely that any VS integration work for IRb will take care of that. As it is, I use GVim for most of my Ruby coding these days. :) I use ViEmu for the best of both worlds. :) ___ 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
