Open GoogleCodeExporter opened 8 years ago
Original comment by StefanSi...@gmail.com
on 16 Oct 2009 at 8:05
The most important thing is the comments on the classes, interfaces and member
variables (as opposed to the methods). We can look at a method and see what it
does easily enough, but in any given project I find it's hard to tell what any
given class or field is for. UML/class diagrams are also helpful! Luckily, in
the case of RunSharp, I can tell a lot of how it works by stepping through a
debugger.
I see calls like g.Arg(0, "args"); are gone from this build, in favor of
Parameter(). I guess the CodeProject article will need revising too.
Original comment by qwertie...@gmail.com
on 13 Aug 2010 at 10:37
Hi qwertie256,
I'm really sorry that these things are not done yet, but it unfortunately all
comes down to how much spare time I can find for this project, which is zero
for now and the foreseeable future.
Regarding the g.Arg(...) thing - that was something I really disliked in the
first release, because it was conceptually completely wrong (although it looks
convenient at the first glance) to define formal parameter names via a code
generator class. It also introduces 'magic constants' (the parameter indices)
to the code, something I'm trying to avoid at all costs.
Best Regards,
Stefan
Original comment by StefanSi...@gmail.com
on 17 Aug 2010 at 6:32
Well, if you find time to do one thing, let it be an updated CodeProject
article. I imagine that's what everybody reads before they try to use RunSharp.
And how about that g.Do() method I suggested?
Original comment by qwertie...@gmail.com
on 2 Nov 2010 at 6:19
By the way, I finished the library I was writing based on RunSharp (a thing for
automatically reading and writing structures in files, sort of like C's fread()
and fwrite() except that it supports big-endian or little-endian,
variable-length arrays, etc.)
Original comment by qwertie...@gmail.com
on 2 Nov 2010 at 6:23
Original issue reported on code.google.com by
StefanSi...@gmail.com
on 16 Oct 2009 at 7:58