[Mono-docs-list] feature suggestion
Thu, 26 Feb 2004 03:05:23 -0500
I think I see how I've confused the matter a little for myself. My
initial interest in Mono and related technologies started with trying to
develop asp.net type applications using mono + postgres. I've read/ing
many books on c#, ado.net, components etc... just about anything I can
get my hands on really. One of my complaints is that I can't find a
book now that has real and good examples. I want to build custom asp
components but just reading the api is kinda dry (I find). It is
helpful and necessary of course but it's even more interesting reading
the source code of how mono does it. In this/my example, everything in
asp.net is a component. Component writing it's not a trivial task but
it's not like writing a new language from scratch. I wasn't suggesting
to actually "write" anything or at least not too much. Ideally there
would be a way to marry the current docs and the current source code.
Perhaps as an option of the MonoDoc to specify where you have the source
code installed and dynamically point to it from each class, delegate
etc... api spec. If you don't specify it you don't get the link to the
source kind of thing. Maybe I'm being naive - but in my (narrow?) view
isn't the hard work being done already? Talented people are writing the
source and docs - the api specifies the name of all the constructs - the
class library is named sweetly with the name of the class, struct etc as
the name of the file. There is not a perfect match with namespaces to
classes but I'm sure with a little thought even that could be overcome.
Perhaps using a new custom attribute(s). I would definitely volunteer
some time to do grunt work. Some areas of the source code may be a
little scary [to some] but I'm sure if you are studying how to write an
ado.net provider or even how to use one better you wouldn't find it so
awful. And you wouldn't have to read a book to gain that immediate
Short example: recently I wanted to use a datagrid with one column being
a checkbox and I wanted it to be as nice and easy as a command button
(events and all). Of course there are ways to do this but none that
easy. I wanted to see what others had done - surely others have wanted
to do this too. I went to the Code Project website
(http://www.codeproject.com/) and sure enough found a couple of
examples. I'm sure all worked just fine but none of them were well
integrated and each had their own setbacks. I went to the mono code and
saw exactly how this mechanism works and within an hour I had an awesome
answer that was perfectly integrated (well I thought so :) anyhow). But
this would only have happened because I knew about the mono doc.
Selfishly I don't want to tell anyone that the absolute best kept secret
on the internet is Mono. But it's definitely more fun to show people
and see their reaction.
I imagine as I move on to other pure mono.net technologies there will be
plenty more rewards to come and I'll keep using the sources where I
can/should. I would love to see how people so used to the way that
Microsoft presents their Help docs and then have something of equal
quality with the code behind it - unheard of!! Ok, back to work for me...
Cheers and thanks for listening
Gustavo Ramos wrote:
>>I can imagine a world of difficulties in getting this to actually work
>>(the biggest of which being flux in the codebase) but this would be
>>phenomenal if it could actually be pulled off. Really, any major open
>>source project that could pull something like this off would see a
>>huge swell in developer contribution. Getting over the critical
>>knowledge hump that would make me useful to the project is the main
>>bit holding me back.
> Right! In the long term, it would bring back a lot of contributions to mono.
> However this could be a huge task, comparable to the work needed for a
> book. It could be a great candidate project for novell investments.
> Personally would prefer a straight reading book format, instead of
> cross-linked sources documents. They would be valuable as a reference for
> the mono hacker, who knows --at least-- how the beast work. A book format
> should do for those interested in learning the mono internals from
> scratch. If that results in a huge project, the book could skip the basics
> of compilers design.
> I'm reading the book "Compilers. Principles, technics and tools.", it's
> great, but a rather hard reading style. Apart from that, it's a lot of
> theory, and don't dive into real implementations. Another book, which
> title "Inside C#" suggests the internal side of C# doesn't go far, it's
> rather a book for C# language learning, with just a few comments about
> IL and other internals. However, Tom Archer (the Author of the latter)
> wrote his book while he was learning C#, because at the time of the
> writing .net was at beta stage. Well, mixing said things, it would be
> not so hard to write a Mono book about internals while learning it.
> Compilers design theory however couldn't be avoided at all, as it is
> intimately linked to the implementation. I'd love to see someone taking
> such an item :-)
> I'd be happy to write it, but unfortunately don't have the time. Food
> and survival is first :-( Please, if someone would like to swap writing
> subjects (e.g. blog <=> book), there would be a lot of interest out
> there for it. Maybe someone about to write a thesis?
> Mono-docs-list maillist - Monofirstname.lastname@example.org