I agree with Lukas, although I have already expressed these sentiments in previous threads when I raised my own design concern. For me the point is that the standard old class comment / method comments is not expressive enough to be integrated into such a help system. There is a desire to annotate help above what can be done with the old method (a) via a richer API but use a system that does not depend on the subclass approach (b). Now for Pharo it does not really matter because we put the base classes in, but as Lukas says it does not load in other images that require this code. and my feeling is that the subclass approach still puts the documentation too far from the code that you are documenting. This is what I found a pain trying to integrate some help in the network package. i just ended up not doing it. I don't want to have to put it in another package. Anyway i am not going to go over old ground. i just wanted to say +1.
cheers, Mike On Wed, May 5, 2010 at 7:19 PM, Stéphane Ducasse <[email protected]> wrote: > Yes I remember it :) > Kind of pattern :) > Stef >> >>> P.S: I'm still in favour of well structured books in separate >>> packages than mixed code/docu in one package since you >>> may wish to unload docu for deployment/runtime scenarios. >>> >> Hi Torsten, all >> Yes, we had exactly the same discussion (one year ago? I can't believe it) >> about >> the settings package. An advantage of the builder approach is that >> one can simply choose: >> It is possible to let documentation methods (#helpOn: aBuilder ...) and code >> mixed in a single package without introducing any dependency >> or choose to have two packages, one for the documentation and the >> second for the code. >> Cheers >> Alain >> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
