18 Sep
2011
18 Sep
'11
10:23 p.m.
doru can you generate a new comment in addition to the inplace remarks
because else this is quite boring for me since I have to understand what is wrong and what
is not.
Then how do we address all the wrong and obsolete methods?
yes so we should fix the code.
Now I do not have time for that in addition to the rest :(
tomorrow I get just 6 hours meetings: company and project writing.
ok but put also a lookup one
I would because else nobody knows it.
so why it is not tagged as such.
How can I guess that?
Ok
so why is it there?
So now I'm totally confused.
Guys we are not good at making sure that people can understand Moose. I'm sorry to say
that but class comments are important and one line is not good.
It took more than 30 min for a totally wrong one.
Can we do a really effort because how can I explain moose to new people in such a case?
May be I should just stop to think about it in fact and focus on Pharo.
Stef
We have:
-------
MooseEntity is an abstract entity. Entities should subclass this class.
The state instance variable provides a mechanism for extending the state of entities.
Proposition:
----------
MooseEntity is an abstract class that refines MooseElement. Model entities should be
instances of subclasses this class.
MooseEntity provides means to add state for model extensions as well as meta information.
The state extension is provided through MooseEntityState (see MooseEntityState). Using
this mechanism, a package can extend an entity to add more state. This extension will only
be visible when the package is loaded.
Any MooseEntity can extended with property that
is described using the FAME meta model.
Here is an example: FAMIXAttribute defined the property AHNL as follow using the pragma
<property:longName:description:>
This is wrong now. See:
http://code.google.com/p/moose-technology/issues/detail?id=706
FAMIXAttribute>>hierarchyNestingLevel
<property: #AHNL longName: 'Attribute hierarchy nesting level'
description: 'The hierarchy nesting level of an attribute.'>
^self
lookUpPropertyNamed: #AHNL
computedAs: [self belongsTo hierarchyNestingLevel]
I would prefer to have less hardcoded examples. So, maybe like this:
---
YourEntity>>yourExtendingAttribute
<MSEProperty: #yourExtendingAttribute type: #YourType>
^ self privateState attributeAt: #yourExtendingAttribute
YourEntity>>yourExtendingAttribute: aValue
<MSEProperty: #yourExtendingAttribute type: #YourType>
^ self privateState attributeAt: #yourExtendingAttribute put: aValue ---
Furthermore, I think we should split the comment into conceptual and implementation part
because when looking at the entity from the MetaBrowser point of view, you want to know
how to use it, not how to implement it.
Yes but we should keep in the implementation one because they are important for users.
In addition, any MooseEntity can also be
annotated with navigation declarations (which are used by the user interface to propose
navigation options to the user).
For example, the class FAMIXClass can define the navigation 'Accessor Methods' as
follows
FAMIXClass>>accessorMethodsGroup
<navigation: 'Accessor methods'>
^ FAMIXMethodGroup withAll: (self accessorMethods) withDescription: 'Pure accessors
in ', self name
The pragma <navigation:> declares that the method accessorMethodsGroup is the
method to invoke to get the associated navigation.
The method navigationSelectors (see below) returns the list of methods declaring
navigation of a given MooseEntity.
This <navigation:> is more of a secondary point and I would not put it in here.
Finally, MooseEntity provides the possibility to
add simple annotations (we call properties to avoid clash name with Java annotations),
No. These are really properties.
to any moose model element. For example, a new
information can be added to any model entity and it should be accessible. Like for example
a comment. Note that such a solution does not use FAME based description and as such will
not appear when we will query the declared properties.
propertyNamed: name
propertyNamed: name put: value
Have a look at the test testProperty for an example of property use.
Some API:
description
returns the description (FAME instance) described the receiver.
This is mooseDescription. This is indeed important.
allDeclaredProperties
return the properties (FAME instances) that describe the receiver. The properties are
defined using <property:longName:description:>.
This is an obsolete method. navigationSelectors
Return the list of methods that support the receiver navigation.
This is more of a helper method. I would rather keep it internally and not advertise it
much. For example FAMIXClass instance can be
navigated via #(#outgoingInvocationsGroup #allExternalMultiplications #invokedClasses
#allExternalDuplications #clientClasses #invokingClasses #allMultiplications
#allInternalDuplications #abstractMethodsGroup #providerClasses
#allInternalMultiplications #accessorMethodsGroup #allDuplicatingClasses
#incomingAccessesGroup #subclassHierarchyGroup #superclassHierarchyGroup #methodsGroup
#withSuperclassHierarchyGroup #withSubclassHierarchyGroup #classes)
Try: FAMIXClass allInstances first navigationSelectors.
allPropertySelectors
Return a dictionary with all properties of the entity, including metamodel properties,
metrics, and navigation groups.
Keys are abstract names of properties, values are implementing selectors.
for example: #ATFD -> #numberOfAccessesToForeignData means that ATDF is computed by
invoking the method #numberOfAccessesToForeignData.
This is an obsolete method.