documentation effort of Mondrian
by Alexandre Bergel
Hi!
I recently documented the source code of Mondrian. This means adding class comments and methods comments.
Before the effort, only 14% of the methods were commented. Below a screenshot of the DocumentationBlueprint, a visualization intended to help me document. The MOShape class hierarchy is here presented.
After the effort, 24% of the methods are commented. Here is another screen, after 3 days of work.
Here is the legend:
'big box = class' .
'edge = inheritance link' .
'small box = method' .
'small box height = number of lines of code' .
'small box width = number of collaborating classes' .
'red border = non commented' .
Comments are welcome
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
12 years, 4 months
Issue 595 in moose-technology: [Glamour] Transmission>>from: is said to take a port
by moose-technology@googlecode.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 595 by damien.c...(a)gmail.com: [Glamour] Transmission>>from: is
said to take a port
http://code.google.com/p/moose-technology/issues/detail?id=595
The method GLMTransmission>>from: takes a parameter 'aPort'. However, this
method is most of the time used with a pane symbol instead of a port. This
is confusing as the Moose book says
"
For specifying a transmission origin that points to a #selection port
of a pane, you simply use from:.
"
In this case it is clear that the port is #selection and it is the default.
The reader is then waiting for an implementation similar to:
GLMTransmission>>from: aPaneSymbol
^ self from: aPaneSymbol port: #selection
12 years, 4 months
FAMIXPackage>>methods and MooseChef
by Tudor Girba
Hi,
I am continuing to review MooseChef and I stumbled across the definition of query**Invocations defined in TScopingEntityQueries:
TScopingEntityQueries>>queryAllOutgoingInvocations
^ self createOutgoingInvocationQueryResultWith: (self methods flatCollect: [ :m | m outgoingInvocations ])
This depends on #methods. However, in FAMIXPackage, methods only returns the extended methods defined in the package:
FAMIXPackage>>methods
^ self privateState
cacheAt: #methods
ifAbsentPut: [
childNamedEntities select: [ :child | child isKindOf: FAMIXBehaviouralEntity ]]
This has a different semantics from the one defined in Namespace:
FAMIXNamespace>>methods
^ self privateState
cacheAt: #methods
ifAbsentPut: [
self classes flatCollect: #methods ]
So. I propose that FAMIXPackage>>methods is changed to classExtensionMethods and methods is computed like in Namespace + classExtensionMethods.
Anyone else depending on methods with the semantics of classExtensionMethods?
Cheers,
Doru
--
www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
12 years, 4 months
Limitation of Mondrian?
by Alexandre Bergel
Hi!
I often bump into a problem having the following gist:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
view nodes: #( $a $b $a).
view edgesFromAssociations: { $a -> $b . $b -> $a}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
How can I express the the second $a and not the first when defining edges? I have the impression this limitation comes from the fact that two different nodes have the same model behind ($a), and there is no way to distinguish between them.
An easy and backward compatible solution would be to permit to provide nodes:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
nodes := view nodes: #( $a $b $a).
view edgesFromAssociations: { nodes first -> nodes second . nodes second -> nodes third }
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Opinion?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
12 years, 4 months