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);
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);
ConvertToString is much more readable.
The JITter could theoretically eliminate one or more method calls
anyway
(though I can’t say that I know for sure that it does).
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. <
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs