[Mono-docs-list] feature suggestion

[Chris Vickerson]

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  -  Mono-docs-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-docs-list