[Better Comment Initiative]: MooseEntity

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[Better Comment Initiative]: MooseEntity

Stéphane Ducasse
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 way to add state for model extensions as well as meta information (property and navigation).
For example a package can extend an entity to add more state and such extension should be only visible when the package is loaded.

Any MooseEntiy 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:>

        FAMIXAttribute>>hierarchyNestingLevel
                <property: #AHNL longName: 'Attribute hierarchy nesting level'
                        description: 'The hierarchy nesting level of an attribute.'>
               
                ^self
                        lookUpPropertyNamed: #AHNL
                        computedAs: [self belongsTo hierarchyNestingLevel]

In addition, any MooseEntity can also be annotated with navigation declarations (which are used by the environment 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.


Finally, MooseEntity provides the possibility to add simple annotations (we call properties to avoid clash name with Java annotations),
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.

        allDeclaredProperties
                return the properties (FAME instances) that describe the receiver. The properties are defined using <property:longName:description:>.

        navigationSelectors
                Return the list of methods that support the receiver navigation.

                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.

The state instance variable provides a mechanism for extending the state of entities.
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Better Comment Initiative]: MooseEntity

Tudor Girba-2
Hi,

Cool that you started this because a part of it is slightly wrong :). This means that this effort is highly needed. Of course, we knew that beforehand, but it is great to have it clear.


On 18 Sep 2011, at 19:02, Stéphane Ducasse wrote:

> 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.

> 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.

Cheers,
Doru


> The state instance variable provides a mechanism for extending the state of entities.
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"There are no old things, there are only old ways of looking at them."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Better Comment Initiative]: MooseEntity

Stéphane Ducasse

On Sep 18, 2011, at 9:49 PM, Tudor Girba wrote:

> Hi,
>
> Cool that you started this because a part of it is slightly wrong :).

I was reading code and trying to remember :)


> This means that this effort is highly needed. Of course, we knew that beforehand, but it is great to have it clear.
>
>
> On 18 Sep 2011, at 19:02, Stéphane Ducasse wrote:
>
>> 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.
>
>> 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.
>
> Cheers,
> Doru
>
>
>> The state instance variable provides a mechanism for extending the state of entities.
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "There are no old things, there are only old ways of looking at them."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Better Comment Initiative]: MooseEntity

Stéphane Ducasse
In reply to this post by Tudor Girba-2
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?


>> 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

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.

>> 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


ok but put also a lookup one


> ---
>
> 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.

I would because else nobody knows it.

>
>> 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.


so why it is not tagged as such.

How can I guess that?

>
>> 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.

Ok

>
>> 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.

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



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Better Comment Initiative]: MooseEntity

Tudor Girba-2
Hi,

On 18 Sep 2011, at 22:23, Stéphane Ducasse wrote:

> doru can you generate a new comment in addition to the inplace remarks

Yes. I will try.

> 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?

I am still waiting for someone to invest in this :). Andre started to work on the pragma issue, but he only got half way.


>
>>> 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
>
> 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.

I did not say you should do it. I pointed it out for spreading the knowledge. Who knows, maybe someone jumps right at it :)



>>> 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
>
>
> ok but put also a lookup one

No. The lookup thing is just a helper. It delegates to the privateState and we only used it as a transition from a historical usage.

>> ---
>>
>> 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.

Of course. I was just saying we should somehow distinguish the two. Most likely, we should add a meta comment in Fame and that should be about the usage of the meta-model. And then we keep the Smalltalk class comment for the implementation.

I created a new issue:
http://code.google.com/p/moose-technology/issues/detail?id=708


>>> 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.
>
> I would because else nobody knows it.



>>
>>> 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.
>
>
> so why it is not tagged as such.
>
> How can I guess that?

They should be, but since a long time I am pretty much the only one working on Core. And things move slowly.


>>> 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.
>
> Ok
>>
>>> 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.
>
> so why is it there?

Because of the same reason StringHolder is still in Pharo :). Legacy. But, as I pointed out we have an issue for this and Andre did a good job of porting the critical ones. We should continue.

> So now I'm totally confused.
>
> Guys we are not good at making sure that people can understand Moose.

When you say guys, who are you referring to? I would like to know too if there are more people interested in maintaining these parts :)

> 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.

Sure. This happens :). But, it is good that you do it. Now we know that even you do not know it anymore. So, we have to do something about it.

> 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.

That is not the right state of mind :).

Doru


> Stef
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"What we can governs what we wish."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Better Comment Initiative]: MooseEntity

Stéphane Ducasse
Doru the key difference with stringHolder is that in StringHolder nobody understand how it works.
Because it I would know I would go way faster. So I suggest that we spend next two weeks not typing code on moose but only fixing comments
and we will get a real impact.
For pharo I have always to reverse engineer (network, filesystem...) because people forget that a soft is finihsed with it is really documented.


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.

Property Extension
----------------
Any MooseEntity can extended with property that is described using the FAME meta model as follow:

YourEntity>>yourExtendingAttribute
        <MSEProperty: #yourExtendingAttribute type: #YourType>
        ^ self privateState attributeAt: #yourExtendingAttribute

YourEntity>>yourExtendingAttribute: aValue
        <MSEProperty: #yourExtendingAttribute type: #YourType>
        ^ self privateState attributeAt: #yourExtendingAttribute put: aValue

Note that a nice helper, lookUpPropertyNamed: omputedAs: is provided to hide the use of privateState to subclasses.


Old versions used <property:longName:description:> as in the following example.

        FAMIXAttribute>>hierarchyNestingLevel
                <property: #AHNL longName: 'Attribute hierarchy nesting level'
                        description: 'The hierarchy nesting level of an attribute.'>
               
                ^self
                        lookUpPropertyNamed: #AHNL
                        computedAs: [self belongsTo hierarchyNestingLevel]


Entity Navigation
--------------

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.


Property
-------
Finally, MooseEntity provides the possibility to add other free style properties (we call properties to avoid clash name with Java annotations),
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:
        mooseDescription
                returns the description (FAME instance) described the receiver.

        mooseDisplayString
                returns a name for UI use.
       
        allDeclaredProperties
                returns the properties (FAME instances) that describe the receiver. This method seems to be obsolete.
                But its subtitute is unclear.

        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 method seems to be obsolete, but its replacement is unclear.


The previous comment is now published.









Open Questions.
-----------


1  lookUpPropertyNamed: #yourExtendingAttribute computedAs:



        I started to deprecate  lookUpPropertyNamed: #yourExtendingAttribute computedAs:  but I do not think that we want all the FAMIXsubclasses to know that there is a private state

        I prefer
                self lookUpPropertyNamed: #yourExtendingAttribute computedAs:
                self privateState attributeAt: #yourExtendingAttribute put: aValue


        So can we agree on this before I rewrite everything?


2 allDeclaredProperties
                return the properties (FAME instances) that describe the receiver. The properties are defined using <property:longName:description:>.
                This is an obsolete method.

But it is used by the system
and even is part of the public interface of hismo.
How do we know the declaredProperties then?


3 about description?
Is it obsolete? because it is used what is the relationship with mooseDescription?

MooseEntity>>description
         
        ^self privateState description


4 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.




> When you say guys, who are you referring to? I would like to know too if there are more people interested in maintaining these parts :)

so basically you and me (but I do not have the knowledge and the time) and we should not think that new engineers can do anything at
this level because there is no magic, no doc generate less knowledge and less knowledge less doc.

so what do we do:
        Plan A- build a roadmap and do it (I can probably work every two evenings on it for a month).
                Right now (this evening we log on chat and we fix) these two

                        allPropertySelectors
                                is used
                        allDeclaredProperties
                                is used
               
        Plan B - I focus only on pharo (because I cannot do both especially right now).

so if somebody with knowledge wants to join I will give a try.





Stef






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Better Comment Initiative]: MooseEntity

Tudor Girba-2
Hi,

I changed the MooseEntity comment (the API should still be extended a bit):


MooseEntity is an abstract entity. Entities should subclass this class.

!!Extension mechanism

The state instance variable provides a mechanism for extending the state of entities. This is achieved through 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. This is an important mechanism to enable extensibility and modularity.

For example, if you have YourEntity that subclasses MooseEntity, you can extend it with:

YourEntity>>yourExtendingAttribute
        ^ self privateState attributeAt: #yourExtendingAttribute
YourEntity>>yourExtendingAttribute: aValue
        ^ self privateState attributeAt: #yourExtendingAttribute put: aValue

(see MooseEntityState for more information)


!!Meta descriptions

Entities should also be meta-described in terms of Fame. This is achieved by means of pragmas:

- First, on the class side, you should have a method . For example, YourEntity could have
YourEntity class>>annotation
        <MSEClass: #YourEntity super: #MooseEntity>
        <package: 'YourPackage'>
        <MSEComment: 'The YourEntity Smalltalk class has a correspondent YourEntity meta entity in the Fame world'>

- The pragma <MSEProperty:type:> must be placed in the getter method to denote a Fame property. For example:
YourEntity>>yourExtendingAttribute
        <MSEProperty: #yourExtendingAttribute type: #YourType>
        <MSEComment: 'This is an attribute extended in a different package'>
        ^ self privateState attributeAt: #yourExtendingAttribute
       
       
!!Important API

mooseDescription - returns the corresponding FM3MetaDescription instance
mooseName - returns a symbol that should qualify the current entity. It does not have to be unique




On 19 Sep 2011, at 09:42, Stéphane Ducasse wrote:

> Doru the key difference with stringHolder is that in StringHolder nobody understand how it works.
> Because it I would know I would go way faster. So I suggest that we spend next two weeks not typing code on moose but only fixing comments
> and we will get a real impact.
> For pharo I have always to reverse engineer (network, filesystem...) because people forget that a soft is finihsed with it is really documented.
>
>
> 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.
>
> Property Extension
> ----------------
> Any MooseEntity can extended with property that is described using the FAME meta model as follow:
>
> YourEntity>>yourExtendingAttribute
> <MSEProperty: #yourExtendingAttribute type: #YourType>
> ^ self privateState attributeAt: #yourExtendingAttribute
>
> YourEntity>>yourExtendingAttribute: aValue
> <MSEProperty: #yourExtendingAttribute type: #YourType>
> ^ self privateState attributeAt: #yourExtendingAttribute put: aValue
>
> Note that a nice helper, lookUpPropertyNamed: omputedAs: is provided to hide the use of privateState to subclasses.
>
>
> Old versions used <property:longName:description:> as in the following example.
>
> FAMIXAttribute>>hierarchyNestingLevel
> <property: #AHNL longName: 'Attribute hierarchy nesting level'
> description: 'The hierarchy nesting level of an attribute.'>
>
> ^self
> lookUpPropertyNamed: #AHNL
> computedAs: [self belongsTo hierarchyNestingLevel]
>
>
> Entity Navigation
> --------------
>
> 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.
>
>
> Property
> -------
> Finally, MooseEntity provides the possibility to add other free style properties (we call properties to avoid clash name with Java annotations),
> 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:
> mooseDescription
> returns the description (FAME instance) described the receiver.
>
> mooseDisplayString
> returns a name for UI use.
>
> allDeclaredProperties
> returns the properties (FAME instances) that describe the receiver. This method seems to be obsolete.
> But its subtitute is unclear.
>
> 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 method seems to be obsolete, but its replacement is unclear.
>
>
> The previous comment is now published.
>
>
>
>
>
>
>
>
>
> Open Questions.
> -----------
>
>
> 1  lookUpPropertyNamed: #yourExtendingAttribute computedAs:
>
>
>
> I started to deprecate  lookUpPropertyNamed: #yourExtendingAttribute computedAs:  but I do not think that we want all the FAMIXsubclasses to know that there is a private state
>
> I prefer
> self lookUpPropertyNamed: #yourExtendingAttribute computedAs:
> self privateState attributeAt: #yourExtendingAttribute put: aValue
>
>
> So can we agree on this before I rewrite everything?
>
>
> 2 allDeclaredProperties
> return the properties (FAME instances) that describe the receiver. The properties are defined using <property:longName:description:>.
> This is an obsolete method.
>
> But it is used by the system
> and even is part of the public interface of hismo.
> How do we know the declaredProperties then?
>
>
> 3 about description?
> Is it obsolete? because it is used what is the relationship with mooseDescription?
>
> MooseEntity>>description
>
> ^self privateState description
>
>
> 4 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.
>
>
>
>
>> When you say guys, who are you referring to? I would like to know too if there are more people interested in maintaining these parts :)
>
> so basically you and me (but I do not have the knowledge and the time) and we should not think that new engineers can do anything at
> this level because there is no magic, no doc generate less knowledge and less knowledge less doc.
>
> so what do we do:
> Plan A- build a roadmap and do it (I can probably work every two evenings on it for a month).
> Right now (this evening we log on chat and we fix) these two
>
> allPropertySelectors
> is used
> allDeclaredProperties
> is used
>
> Plan B - I focus only on pharo (because I cannot do both especially right now).
>
> so if somebody with knowledge wants to join I will give a try.
>
>
>
>
>
> Stef
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"From an abstract enough point of view, any two things are similar."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Better Comment Initiative]: MooseEntity

Stéphane Ducasse
Ok did you publish it.

Stef

On Sep 19, 2011, at 12:20 PM, Tudor Girba wrote:

> Hi,
>
> I changed the MooseEntity comment (the API should still be extended a bit):
>
>
> MooseEntity is an abstract entity. Entities should subclass this class.
>
> !!Extension mechanism
>
> The state instance variable provides a mechanism for extending the state of entities. This is achieved through 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. This is an important mechanism to enable extensibility and modularity.
>
> For example, if you have YourEntity that subclasses MooseEntity, you can extend it with:
>
> YourEntity>>yourExtendingAttribute
> ^ self privateState attributeAt: #yourExtendingAttribute
> YourEntity>>yourExtendingAttribute: aValue
> ^ self privateState attributeAt: #yourExtendingAttribute put: aValue
>
> (see MooseEntityState for more information)
>
>
> !!Meta descriptions
>
> Entities should also be meta-described in terms of Fame. This is achieved by means of pragmas:
>
> - First, on the class side, you should have a method . For example, YourEntity could have
> YourEntity class>>annotation
> <MSEClass: #YourEntity super: #MooseEntity>
> <package: 'YourPackage'>
> <MSEComment: 'The YourEntity Smalltalk class has a correspondent YourEntity meta entity in the Fame world'>
>
> - The pragma <MSEProperty:type:> must be placed in the getter method to denote a Fame property. For example:
> YourEntity>>yourExtendingAttribute
> <MSEProperty: #yourExtendingAttribute type: #YourType>
> <MSEComment: 'This is an attribute extended in a different package'>
> ^ self privateState attributeAt: #yourExtendingAttribute
>
>
> !!Important API
>
> mooseDescription - returns the corresponding FM3MetaDescription instance
> mooseName - returns a symbol that should qualify the current entity. It does not have to be unique
>
>
>
>
> On 19 Sep 2011, at 09:42, Stéphane Ducasse wrote:
>
>> Doru the key difference with stringHolder is that in StringHolder nobody understand how it works.
>> Because it I would know I would go way faster. So I suggest that we spend next two weeks not typing code on moose but only fixing comments
>> and we will get a real impact.
>> For pharo I have always to reverse engineer (network, filesystem...) because people forget that a soft is finihsed with it is really documented.
>>
>>
>> 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.
>>
>> Property Extension
>> ----------------
>> Any MooseEntity can extended with property that is described using the FAME meta model as follow:
>>
>> YourEntity>>yourExtendingAttribute
>> <MSEProperty: #yourExtendingAttribute type: #YourType>
>> ^ self privateState attributeAt: #yourExtendingAttribute
>>
>> YourEntity>>yourExtendingAttribute: aValue
>> <MSEProperty: #yourExtendingAttribute type: #YourType>
>> ^ self privateState attributeAt: #yourExtendingAttribute put: aValue
>>
>> Note that a nice helper, lookUpPropertyNamed: omputedAs: is provided to hide the use of privateState to subclasses.
>>
>>
>> Old versions used <property:longName:description:> as in the following example.
>>
>> FAMIXAttribute>>hierarchyNestingLevel
>> <property: #AHNL longName: 'Attribute hierarchy nesting level'
>> description: 'The hierarchy nesting level of an attribute.'>
>>
>> ^self
>> lookUpPropertyNamed: #AHNL
>> computedAs: [self belongsTo hierarchyNestingLevel]
>>
>>
>> Entity Navigation
>> --------------
>>
>> 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.
>>
>>
>> Property
>> -------
>> Finally, MooseEntity provides the possibility to add other free style properties (we call properties to avoid clash name with Java annotations),
>> 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:
>> mooseDescription
>> returns the description (FAME instance) described the receiver.
>>
>> mooseDisplayString
>> returns a name for UI use.
>>
>> allDeclaredProperties
>> returns the properties (FAME instances) that describe the receiver. This method seems to be obsolete.
>> But its subtitute is unclear.
>>
>> 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 method seems to be obsolete, but its replacement is unclear.
>>
>>
>> The previous comment is now published.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Open Questions.
>> -----------
>>
>>
>> 1  lookUpPropertyNamed: #yourExtendingAttribute computedAs:
>>
>>
>>
>> I started to deprecate  lookUpPropertyNamed: #yourExtendingAttribute computedAs:  but I do not think that we want all the FAMIXsubclasses to know that there is a private state
>>
>> I prefer
>> self lookUpPropertyNamed: #yourExtendingAttribute computedAs:
>> self privateState attributeAt: #yourExtendingAttribute put: aValue
>>
>>
>> So can we agree on this before I rewrite everything?
>>
>>
>> 2 allDeclaredProperties
>> return the properties (FAME instances) that describe the receiver. The properties are defined using <property:longName:description:>.
>> This is an obsolete method.
>>
>> But it is used by the system
>> and even is part of the public interface of hismo.
>> How do we know the declaredProperties then?
>>
>>
>> 3 about description?
>> Is it obsolete? because it is used what is the relationship with mooseDescription?
>>
>> MooseEntity>>description
>>
>> ^self privateState description
>>
>>
>> 4 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.
>>
>>
>>
>>
>>> When you say guys, who are you referring to? I would like to know too if there are more people interested in maintaining these parts :)
>>
>> so basically you and me (but I do not have the knowledge and the time) and we should not think that new engineers can do anything at
>> this level because there is no magic, no doc generate less knowledge and less knowledge less doc.
>>
>> so what do we do:
>> Plan A- build a roadmap and do it (I can probably work every two evenings on it for a month).
>> Right now (this evening we log on chat and we fix) these two
>>
>> allPropertySelectors
>> is used
>> allDeclaredProperties
>> is used
>>
>> Plan B - I focus only on pharo (because I cannot do both especially right now).
>>
>> so if somebody with knowledge wants to join I will give a try.
>>
>>
>>
>>
>>
>> Stef
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "From an abstract enough point of view, any two things are similar."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Better Comment Initiative]: MooseEntity

Tudor Girba-2
Yes.

Doru


On 19 Sep 2011, at 14:46, Stéphane Ducasse wrote:

> Ok did you publish it.
>
> Stef
>
> On Sep 19, 2011, at 12:20 PM, Tudor Girba wrote:
>
>> Hi,
>>
>> I changed the MooseEntity comment (the API should still be extended a bit):
>>
>>
>> MooseEntity is an abstract entity. Entities should subclass this class.
>>
>> !!Extension mechanism
>>
>> The state instance variable provides a mechanism for extending the state of entities. This is achieved through 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. This is an important mechanism to enable extensibility and modularity.
>>
>> For example, if you have YourEntity that subclasses MooseEntity, you can extend it with:
>>
>> YourEntity>>yourExtendingAttribute
>> ^ self privateState attributeAt: #yourExtendingAttribute
>> YourEntity>>yourExtendingAttribute: aValue
>> ^ self privateState attributeAt: #yourExtendingAttribute put: aValue
>>
>> (see MooseEntityState for more information)
>>
>>
>> !!Meta descriptions
>>
>> Entities should also be meta-described in terms of Fame. This is achieved by means of pragmas:
>>
>> - First, on the class side, you should have a method . For example, YourEntity could have
>> YourEntity class>>annotation
>> <MSEClass: #YourEntity super: #MooseEntity>
>> <package: 'YourPackage'>
>> <MSEComment: 'The YourEntity Smalltalk class has a correspondent YourEntity meta entity in the Fame world'>
>>
>> - The pragma <MSEProperty:type:> must be placed in the getter method to denote a Fame property. For example:
>> YourEntity>>yourExtendingAttribute
>> <MSEProperty: #yourExtendingAttribute type: #YourType>
>> <MSEComment: 'This is an attribute extended in a different package'>
>> ^ self privateState attributeAt: #yourExtendingAttribute
>>
>>
>> !!Important API
>>
>> mooseDescription - returns the corresponding FM3MetaDescription instance
>> mooseName - returns a symbol that should qualify the current entity. It does not have to be unique
>>
>>
>>
>>
>> On 19 Sep 2011, at 09:42, Stéphane Ducasse wrote:
>>
>>> Doru the key difference with stringHolder is that in StringHolder nobody understand how it works.
>>> Because it I would know I would go way faster. So I suggest that we spend next two weeks not typing code on moose but only fixing comments
>>> and we will get a real impact.
>>> For pharo I have always to reverse engineer (network, filesystem...) because people forget that a soft is finihsed with it is really documented.
>>>
>>>
>>> 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.
>>>
>>> Property Extension
>>> ----------------
>>> Any MooseEntity can extended with property that is described using the FAME meta model as follow:
>>>
>>> YourEntity>>yourExtendingAttribute
>>> <MSEProperty: #yourExtendingAttribute type: #YourType>
>>> ^ self privateState attributeAt: #yourExtendingAttribute
>>>
>>> YourEntity>>yourExtendingAttribute: aValue
>>> <MSEProperty: #yourExtendingAttribute type: #YourType>
>>> ^ self privateState attributeAt: #yourExtendingAttribute put: aValue
>>>
>>> Note that a nice helper, lookUpPropertyNamed: omputedAs: is provided to hide the use of privateState to subclasses.
>>>
>>>
>>> Old versions used <property:longName:description:> as in the following example.
>>>
>>> FAMIXAttribute>>hierarchyNestingLevel
>>> <property: #AHNL longName: 'Attribute hierarchy nesting level'
>>> description: 'The hierarchy nesting level of an attribute.'>
>>>
>>> ^self
>>> lookUpPropertyNamed: #AHNL
>>> computedAs: [self belongsTo hierarchyNestingLevel]
>>>
>>>
>>> Entity Navigation
>>> --------------
>>>
>>> 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.
>>>
>>>
>>> Property
>>> -------
>>> Finally, MooseEntity provides the possibility to add other free style properties (we call properties to avoid clash name with Java annotations),
>>> 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:
>>> mooseDescription
>>> returns the description (FAME instance) described the receiver.
>>>
>>> mooseDisplayString
>>> returns a name for UI use.
>>>
>>> allDeclaredProperties
>>> returns the properties (FAME instances) that describe the receiver. This method seems to be obsolete.
>>> But its subtitute is unclear.
>>>
>>> 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 method seems to be obsolete, but its replacement is unclear.
>>>
>>>
>>> The previous comment is now published.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Open Questions.
>>> -----------
>>>
>>>
>>> 1  lookUpPropertyNamed: #yourExtendingAttribute computedAs:
>>>
>>>
>>>
>>> I started to deprecate  lookUpPropertyNamed: #yourExtendingAttribute computedAs:  but I do not think that we want all the FAMIXsubclasses to know that there is a private state
>>>
>>> I prefer
>>> self lookUpPropertyNamed: #yourExtendingAttribute computedAs:
>>> self privateState attributeAt: #yourExtendingAttribute put: aValue
>>>
>>>
>>> So can we agree on this before I rewrite everything?
>>>
>>>
>>> 2 allDeclaredProperties
>>> return the properties (FAME instances) that describe the receiver. The properties are defined using <property:longName:description:>.
>>> This is an obsolete method.
>>>
>>> But it is used by the system
>>> and even is part of the public interface of hismo.
>>> How do we know the declaredProperties then?
>>>
>>>
>>> 3 about description?
>>> Is it obsolete? because it is used what is the relationship with mooseDescription?
>>>
>>> MooseEntity>>description
>>>
>>> ^self privateState description
>>>
>>>
>>> 4 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.
>>>
>>>
>>>
>>>
>>>> When you say guys, who are you referring to? I would like to know too if there are more people interested in maintaining these parts :)
>>>
>>> so basically you and me (but I do not have the knowledge and the time) and we should not think that new engineers can do anything at
>>> this level because there is no magic, no doc generate less knowledge and less knowledge less doc.
>>>
>>> so what do we do:
>>> Plan A- build a roadmap and do it (I can probably work every two evenings on it for a month).
>>> Right now (this evening we log on chat and we fix) these two
>>>
>>> allPropertySelectors
>>> is used
>>> allDeclaredProperties
>>> is used
>>>
>>> Plan B - I focus only on pharo (because I cannot do both especially right now).
>>>
>>> so if somebody with knowledge wants to join I will give a try.
>>>
>>>
>>>
>>>
>>>
>>> Stef
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "From an abstract enough point of view, any two things are similar."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Speaking louder won't make the point worthier."


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev