I’ve been playing with IronRuby a bit today, and I notice that the
reflection methods are not yet implemented (e.g. running “”.methods in
the interpreter does not produce the expected result). This is not
surprising, given the early stages of development.
Is there a plan in place as to which features currently have the highest
priority for implementation, and if so what is the priority of
reflection? IMO, reflection methods should probably be a moderately
high priority, as this would help with implementing most other features.
For example, I was trying to see what string functions were missing from
the implementation from within the IronRuby interpreter, but got an
error when trying to get the methods for strings… Of course I can
pull up the source (and did), but I think implementing some of these
things would be easier with reflection in place. Just a suggestion…
My second question is related to strings… You are currently
StringBuilder to implement your MutableString class, though there is a
comment about eventually replacing this with byte[]. Is there any ETA
on when that might happen? I had wanted to work on implementing some of
the string functions to get myself acquainted with the codebase, but I
see that the string class is in a state where it might not be the best
of ideas to try to add new functionality… Or, if you are willing to
accept a patch for it, I may try the StringBuilder -> byte[] conversion
myself.
Lastly, I see the following in the code base: /!/. For example:
public MutableString/!/ Append(string/!/ str, int
startIndex, int charCount) {
What does this mean? Is there a coding standards document which
describes this? I don’t see any documentation in the codebase about it,
but I assume that it means roughly the same as it does in ruby (that the
method is destructive or somehow changing the object), but I can’t
reconcile that with some things I see in the code base…(for example,
why the ! on the str parameter?).
Lastly, I see the following in the code base: /!/. For example:
public MutableString/!/ Append(string/!/ str, int
startIndex, int charCount) {
What does this mean? Is there a coding standards document which
describes this? I don’t see any documentation in the codebase about it,
but I assume that it means roughly the same as it does in ruby (that the
method is destructive or somehow changing the object), but I can’t
reconcile that with some things I see in the code base…(for example,
why the ! on the str parameter?).
This is only a guess, but one thing I’ve noticed that was missing in C#
is the ability to specify that a nullable type (like string) should
never be null.
So:
string! foo = null;
would result in a compiler error, and you would be required to cast a
nullable string explicitly to a non-nullable string like:
string bar;
string! foo = (string!)bar;
One gotcha with my guess is that “as” semantics wouldn’t work well with
this:
string bar = null;
string! foo = bar as string!;
would fail unless the “as” operator is able to set foo to
default(string!), which might be String.Empty.
And, in particular, the /!/ means “should never be null”. Common
things that can’t be null are CodeContext arguments, and the “self”
argument in most library methods (however if you’re implementing a
Module, self can be null, e.g. class NilClass; include MyModule; end;
nil.my_module_method)
The /!/ is only processed by Spec#, and should not be confused with
the [NotNull] attribute that you can use to tell the DLR MethodBinder
that null isn’t allowed for that argument.
Is there a plan in place as to which features currently have the
highest priority for implementation, and if so what is the priority of
reflection? IMO, reflection methods should probably be a moderately
high priority, as this would help with implementing most other
features.
For example, I was trying to see what string functions were missing
from the implementation from within the IronRuby interpreter, but got
an error when trying to get the methods for strings… Of course I can
pull up the source (and did), but I think implementing some of these
things would be easier with reflection in place. Just a suggestion…
As we refactor stuff after our RubyConf hacks, we’re adding the method
reflection methods. This should show up either early next week when we
resync our tree with SVN.
My second question is related to strings… You are currently
StringBuilder to implement your MutableString class, though there is a
comment about eventually replacing this with byte[]. Is there any ETA
on when that might happen? I had wanted to work on implementing some
of the string functions to get myself acquainted with the codebase,
but I see that the string class is in a state where it might not be
the best of ideas to try to add new functionality… Or, if you are
willing to accept a patch for it, I may try the StringBuilder →
byte[] conversion myself.
If you want to try the byte[] conversion, please go for it. You could
also take the approach of implementing additional instance methods on
String since the interface to StringBuilder should be mostly compatible.
Lastly, I see the following in the code base: /!/. For example:
public MutableString/*!*/ Append(string/*!*/ str, int
startIndex, int charCount) {
These are the Spec# annotations. There is a wiki with some info on
Spec#: