I would not put superOb in scriptloader like that you can do what you want and we too :)
Stef On May 6, 2009, at 4:18 PM, Cédrick Béler wrote: > Hi guys, (cc'ed to pharo list - we're talking about the UML diagram > used in OBEnhancement) > > 2009/5/6 David Röthlisberger <[email protected]>: >> Hi Cédric, >> >> I also like what you did for the UML diagram. > > I didn't push it to the repository because they were some personal > choices and you underlined some of them. > >> >> Some issues I encountered: >> >> - class-side methods should not be at the bottom, but at the top, and >> displayed with underlined font to be more UML-compliant. > > Oh I forgot about that. Looks ok to me though I don't know yet how to > underline text in Mondrian (the text is a single stream with cr's) > >> - not sure about adding the method protocol. If included, I'd >> rather go for >> ordering the method alphabetically and then show the protocol in >> parentheses > > yes there is an ordering problem. The alphabetical order is ok, but > printing the protocol beside could lead to long lines and then wide > rectangles in the diagrams. > > Even if not standard, I actually prefer the ordering by protocol > mainly because it shows the method intention and it forces to use > them. > Nevertheless, to be consistent, I'd like to have a list of predefined > protocols that can be ordered (initialize, accessing, ...) but this is > outside the scope of the UML diagram. > > Could we agree on that in Pharo (standard list of method protocols) ? > Can someone propose a starting point... > > What do you think ? (we could also provide an alternative ordering > trough a popumenu "alphabetical/protocol") > >> - accessors should be present, IMO. > > I agree for the general case but decided to not show them in my > diagrams. > > This is part of a wider strategy. I explore using ivar as slots and > hence not consider accessors as methods. Each ivar has automatic > accessors that I try to complete with pragma's for further processing. > Something like <type: min: max: visibility: >... > Just experiencing... but anyways, I find accessing methods adding too > much extra noise in the diagrams. I'd prefer completing ivars with > their visibility characteristic. Maybe another candidate for the > popumenu (hide accessors). > > >> - empty areas at the end should not be shown at all, eg. if there >> are no >> class methods, class vars. I'd instead suggest to show class vars >> underlined >> in the variable area at the top, class methods underlined at the >> top of the >> method area, which means that there are only two areas. If there >> are no vars >> or methods defined, keep the empty area, but having two or three >> empty areas >> is very confusing (and non-standard). > > ok, you're right. Still, I need to know how to underline text... Do I > need to use TextAttribute ? Any pointers ? > >> For classes without methods and vars (there are some of those...) >> we should >> only show the rectangle with the class name. > > ok. > > >> >> I'd very much appreciate if you could extend your implementation to >> address >> these issues. > > I'll try to do so ;) > > I've also planned to fill menus (browse, implement, senders, > variables, etc... + export as PNG + ...) and hoverText (class comment, > method definitions ...). > > Such a diagram could be an alternative/complementary way of browsing > code... > >> Note that OB uses your implementation, as we rely on the class >> UMLEnhClassDiagram from Alex' Mondrian version containing your >> extensions. > > Yep, I saw that ;) > > Cheers, > > Cédrick > >> >> Thanks a lot, >> David >> >>> >>> I like your extension. Adding edges will not be a problem. You're >>> the >>> second one to ask for it. >>> I will do some coding tonight or tomorrow, will come back to you >>> soon. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 30 Apr 2009, at 16:59, Cédrick Béler wrote: >>> >>>> Hi Alexandre and David, >>>> >>>> I just saw that you merged the development of Mondrian with >>>> OBDiagram. >>>> Sounds good to me. Though, I missed some information in the UML >>>> class >>>> diagram, so I did my own. I joined it in cas you'd like it (plus a >>>> diagram example). One remark though, I simply remove accessing >>>> methods >>>> as I find they "pollute" my diagrams. It's ok for me but I guess >>>> not >>>> for general diagrams. >>>> >>>> I actually play more with accessing method so that I can have their >>>> status and type (declaration in pragmas). Do you think it will be >>>> doable to draw associations between classes (if declared in >>>> pragmas) ? >>>> >>>> Cheers, >>>> >>>> -- >>>> Cédrick >>>> <UMLFullClassDiagram.st><xorp.png> >>> >> >> > > _______________________________________________ > 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
