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 benefit.

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

Chris


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?

Regards,

Gustavo


_______________________________________________ Mono-docs-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-docs-list



_______________________________________________ Mono-docs-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-docs-list

Reply via email to