(no subject)

It would be useful to have a helper function to clean up this kind of
code.
Or is there one and I can’t find it?

RubyUtils.GetConstant(context, rubyClass,
SymbolTable.StringToId(mutableString.ConvertToString()), true);

MutableString.ToSymbol()?

On Sun, May 11, 2008 at 5:34 AM, Peter Bacon D. <

Magic!

Now the next question is should I be using:

mutableString.ConvertToString() or mutableString.GetStringSlice(0)

to get hold of a CLR string for passing to a .NET method.

Both end up calling Content.GetStringSlice(…) anyway but the second
one
seems to go through slightly fewer method calls. My feeling is the
former
is more intuitive.

Pete

From: [email protected]
[mailto:[email protected]] On Behalf Of Curt
Hagenlocher
Sent: Sunday,11 May 11, 2008 13:38
To: [email protected]
Subject: Re: [Ironruby-core] (no subject)

MutableString.ToSymbol()?

On Sun, May 11, 2008 at 5:34 AM, Peter Bacon D.
[email protected] wrote:

It would be useful to have a helper function to clean up this kind of
code.
Or is there one and I can’t find it?

RubyUtils.GetConstant(context, rubyClass,
SymbolTable.StringToId(mutableString.ConvertToString()), true);

  1. ConvertToString is much more readable.

  2. The JITter could theoretically eliminate one or more method calls
    anyway
    (though I can’t say that I know for sure that it does).

  3. We haven’t done anything to optimize this new version of
    MutableString
    yet. In particular, we might find that getting a string from the
    same MutableString multiple times is a frequent enough operation that
    we’ll
    cache the results after the first call. It’s much less likely that such
    an
    optimization would be made for the output of Slice.

My personal rule-of-thumb is that the code you write should clearly
express
your intent as cleanly as possible. We write code not just for the
computer
but also for other humans. Performance issues should be considered up
front
only when considering higher-level design, and for lower-level code are
best
identified later on through profiling.

On Sun, May 11, 2008 at 5:52 AM, Peter Bacon D. <