8 Dec
2008
8 Dec
'08
12:16 p.m.
Hi
I was wondering how some pragmas should be handled in Moose?
Apparently there is currently two "kind" of pragmas in use: the ones
which begin with MSESomething are used to describe the model in Fame.
But there is also a range of "property:longName:description:" pragmas
which are used to describe entity properties like "numberOfMethods",
"numberOfAccesses"...
Such pragmas allow a generic mean to access some metrics, using
MooseEntity#propertyNamed:
But the implementation of #propertyNamed: relies on attributes which
should be described in the metamodel.
Now it seems that the responsibility to parse and interpret those
pragmas belongs to Fame. Currently they are not handled, and I just
found a TODO note in FM3MetaDescription#attributeNamed:ifAbsent:
--
Simon
9 Dec
9 Dec
11:45 a.m.
Hi Simon,
You will find property:longName:description: only in the FAMIX 2
classes, because this pragma is used in the Meta version of Moose in
VW. So, these pragmas should be migrated to Fame MSE*. The other
solution is to subclass the Fame PragmaProcessor and modify it to
understand the old pragmas.
Cheers,
Doru
On Dec 8, 2008, at 12:16 PM, Simon Denier wrote:
Hi
I was wondering how some pragmas should be handled in Moose?
Apparently there is currently two "kind" of pragmas in use: the ones
which begin with MSESomething are used to describe the model in
Fame. But there is also a range of "property:longName:description:"
pragmas which are used to describe entity properties like
"numberOfMethods", "numberOfAccesses"...
Such pragmas allow a generic mean to access some metrics, using
MooseEntity#propertyNamed:
But the implementation of #propertyNamed: relies on attributes which
should be described in the metamodel.
Now it seems that the responsibility to parse and interpret those
pragmas belongs to Fame. Currently they are not handled, and I just
found a TODO note in FM3MetaDescription#attributeNamed:ifAbsent:
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Sometimes the best solution is not the best solution."
10 Dec
10 Dec
midnight
New subject: [Fame-dev] Property pragmas handling
Hi Simon,
As I understand you have "custom attributes" in your metamodel and
want to specify them using pragmas. Further you would like Fame to
parse and handle these pragmas.
I dont have a solution ready for this. Which is not a surprise, Fame
grows only when need arises. Do you have suggestions how to solve it?
What would be best for your need?
Would something alonge these lines help you:
<MSEAnnotation: #longName value: 'pimp my meta-model'>
<MSEAnnotation: #description value: 'Yo dawg, I herd you like
models so we put ...'>
cheers,
AA
--
Follow me http://twitter.com/akuhn
On 08.12.2008, at 12:16, Simon Denier wrote:
Hi
I was wondering how some pragmas should be handled in Moose?
Apparently there is currently two "kind" of pragmas in use: the ones
which begin with MSESomething are used to describe the model in
Fame. But there is also a range of "property:longName:description:"
pragmas which are used to describe entity properties like
"numberOfMethods", "numberOfAccesses"...
Such pragmas allow a generic mean to access some metrics, using
MooseEntity#propertyNamed:
But the implementation of #propertyNamed: relies on attributes which
should be described in the metamodel.
Now it seems that the responsibility to parse and interpret those
pragmas belongs to Fame. Currently they are not handled, and I just
found a TODO note in FM3MetaDescription#attributeNamed:ifAbsent:
--
Simon
2:57 a.m.
New subject: [Fame-dev] Re: Property pragmas handling
From: "Adrian Kuhn" <akuhn(a)gmx.ch>
Would something alonge these lines help you:
<MSEAnnotation: #longName value: 'pimp my meta-model'>
<MSEAnnotation: #description value: 'Yo dawg, I herd you like models
so we put ...'>
I am also quite interested in custom pragmas being captured in a general
way, and then available for query as well as emmitted back into any
generated code.
Why not just do the shorter:
<longName: 'foo'>
<description: 'bar'>
<other: #baz on: 'bar'>
(I'm sure there is a good reason :-)
11 Dec
11 Dec
1:01 a.m.
New subject: [Fame-dev] Property pragmas handling
I'm slowly making my mind around such issues.
First, let me sum up what I understood from the past/current state in
Meta and Moose.
In Meta there was some kind of support for generic access (by symbol)
to property described by pragmas. This support went as far as
providing different SelectorStrategy to compute getter/setter for a
property.
Now in Moose, there is a cache system on top of that. In particular
since properties are read only, there are computed once and stored.
The cache seems to work in two ways:
- when you make a direct call to a method computing a property, good
behaviour for the method is to ask the cache and provides a block to
initialize the value in case it is missing
- when you access the property through its symbolic name, it will look
for it in the cache and in case it is not there, request it using a
SelectorStrategy, which will in the end call the above method (repeat
process above)
Note that the second case can result in two cache miss, but this is
just a minor remark.
The fact is, the cache is built on top of the metamodel, but it should
not be a concern of the metamodel.
OK, enough rambling, back to the topic of pragmas. The attributes
declared by those pragmas should be described with FM3Property, right?
It makes good sense to me, in particular since we could then request
the attributes for their value using #getFrom:
So we could declare such an attribute using <MSEProperty: #NOM
type: ....>.
Then there is custom annotations to such attributes using specific
pragmas, like you propose:
<MSEAnnotation: #longName value: 'pimp my meta-model'>
<MSEAnnotation: #description value: 'Yo dawg, I herd you like models
so we put ...'>
I think such specific annotations should be stored in FM3Element, with
accessors.
Also there should be a mean to query enclosed elements based on such
annotations, like: I should be able to ask a FM3MetaDescription for
all its attributes which declare a 'description' annotation.
On 10 déc. 08, at 00:00, Adrian Kuhn wrote:
Hi Simon,
As I understand you have "custom attributes" in your metamodel and
want to specify them using pragmas. Further you would like Fame to
parse and handle these pragmas.
I dont have a solution ready for this. Which is not a surprise, Fame
grows only when need arises. Do you have suggestions how to solve
it? What would be best for your need?
Would something alonge these lines help you:
<MSEAnnotation: #longName value: 'pimp my meta-model'>
<MSEAnnotation: #description value: 'Yo dawg, I herd you like
models so we put ...'>
cheers,
AA
--
Follow me http://twitter.com/akuhn
On 08.12.2008, at 12:16, Simon Denier wrote:
--
Simon
Hi
I was wondering how some pragmas should be handled in Moose?
Apparently there is currently two "kind" of pragmas in use: the
ones which begin with MSESomething are used to describe the model
in Fame. But there is also a range of
"property:longName:description:" pragmas which are used to describe
entity properties like "numberOfMethods", "numberOfAccesses"...
Such pragmas allow a generic mean to access some metrics, using
MooseEntity#propertyNamed:
But the implementation of #propertyNamed: relies on attributes
which should be described in the metamodel.
Now it seems that the responsibility to parse and interpret those
pragmas belongs to Fame. Currently they are not handled, and I just
found a TODO note in FM3MetaDescription#attributeNamed:ifAbsent:
--
Simon
7:52 a.m.
New subject: [Fame-dev] Property pragmas handling
Hi Simon,
First, let me sum up what I understood from the
past/current state
in Meta and Moose.
In Meta there was some kind of support for generic access (by
symbol) to property described by pragmas. This support went as far
as providing different SelectorStrategy to compute getter/setter for
a property.
Now in Moose, there is a cache system on top of that. In particular
since properties are read only, there are computed once and stored.
The cache seems to work in two ways:
- when you make a direct call to a method computing a property, good
behaviour for the method is to ask the cache and provides a block to
initialize the value in case it is missing
- when you access the property through its symbolic name, it will
look for it in the cache and in case it is not there, request it
using a SelectorStrategy, which will in the end call the above
method (repeat process above)
Note that the second case can result in two cache miss, but this is
just a minor remark.
The fact is, the cache is built on top of the metamodel, but it
should not be a concern of the metamodel.
The propertyNamed: cache mechanism is not the concern of the meta-
model. It is the concern of each object, and it is the object that
decide to compute something based on the information from the meta-
description. The meta-model does not know anything about such a
mechanism.
I do not see why this would be wrong.
In any case, propertyNamed: was a method used heavily long time ago,
when we did not have methods for each property. So, most of the code
in Moose does not depend on it anymore. However, it is still
convenient to call it from the conformity strategies.
OK, enough rambling, back to the topic of pragmas. The
attributes
declared by those pragmas should be described with FM3Property,
right? It makes good sense to me, in particular since we could then
request the attributes for their value using #getFrom:
So we could declare such an attribute using <MSEProperty: #NOM
type: ....>.
Then there is custom annotations to such attributes using specific
pragmas, like you propose:
<MSEAnnotation: #longName value: 'pimp my meta-model'>
<MSEAnnotation: #description value: 'Yo dawg, I herd you like models
so we put ...'>
I think such specific annotations should be stored in FM3Element,
with accessors.
Also there should be a mean to query enclosed elements based on such
annotations, like: I should be able to ask a FM3MetaDescription for
all its attributes which declare a 'description' annotation.
In Moose/Meta we subclassed Property with a class that has longName
and description fields, and we had a specialized PragmaProcessor that
knew how to read those annotations. I agree that there these classes
did not have much behavior, but it was easier to grasp. Annotations
linked to meta Properties can be an overkill for the matter at hand.
On the other hand, if Annotations could be attached to any Element,
this could be a nice way to comment the meta-model.
Cheers,
Doru
On 10 déc. 08, at 00:00, Adrian Kuhn wrote:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"To lead is not to demand things, it is to make them happen."
Hi Simon,
As I understand you have "custom attributes" in your metamodel and
want to specify them using pragmas. Further you would like Fame to
parse and handle these pragmas.
I dont have a solution ready for this. Which is not a surprise,
Fame grows only when need arises. Do you have suggestions how to
solve it? What would be best for your need?
Would something alonge these lines help you:
<MSEAnnotation: #longName value: 'pimp my meta-model'>
<MSEAnnotation: #description value: 'Yo dawg, I herd you like
models so we put ...'>
cheers,
AA
--
Follow me http://twitter.com/akuhn
On 08.12.2008, at 12:16, Simon Denier wrote:
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi
I was wondering how some pragmas should be handled in Moose?
Apparently there is currently two "kind" of pragmas in use: the
ones which begin with MSESomething are used to describe the model
in Fame. But there is also a range of
"property:longName:description:" pragmas which are used to
describe entity properties like "numberOfMethods",
"numberOfAccesses"...
Such pragmas allow a generic mean to access some metrics, using
MooseEntity#propertyNamed:
But the implementation of #propertyNamed: relies on attributes
which should be described in the metamodel.
Now it seems that the responsibility to parse and interpret those
pragmas belongs to Fame. Currently they are not handled, and I
just found a TODO note in
FM3MetaDescription#attributeNamed:ifAbsent:
--
Simon
10:27 a.m.
New subject: [Fame-dev] Property pragmas handling
On 11 déc. 08, at 07:52, Tudor Girba wrote:
How easy could this be in Fame?
Hi Simon,
Oups sorry Doru, I did not say it was wrong, it was just a plain old
summary statement of the current state as I was clarifying my
understanding of the code.
Actually, I was thinking yesterday if pushing the cache as a generic
mechanism into the metamodel would make sense but, too much hurdles
for no improvment. So I almost wrote this for myself :)
First, let me sum up what I understood from the
past/current state
in Meta and Moose.
In Meta there was some kind of support for generic access (by
symbol) to property described by pragmas. This support went as far
as providing different SelectorStrategy to compute getter/setter
for a property.
Now in Moose, there is a cache system on top of that. In particular
since properties are read only, there are computed once and stored.
The cache seems to work in two ways:
- when you make a direct call to a method computing a property,
good behaviour for the method is to ask the cache and provides a
block to initialize the value in case it is missing
- when you access the property through its symbolic name, it will
look for it in the cache and in case it is not there, request it
using a SelectorStrategy, which will in the end call the above
method (repeat process above)
Note that the second case can result in two cache miss, but this is
just a minor remark.
The fact is, the cache is built on top of the metamodel, but it
should not be a concern of the metamodel.
The propertyNamed: cache mechanism is not the concern of the meta-
model. It is the concern of each object, and it is the object that
decide to compute something based on the information from the meta-
description. The meta-model does not know anything about such a
mechanism.
I do not see why this would be wrong.
In any case, propertyNamed: was a method used heavily long time ago,
when we did not have methods for each property. So, most of the code
in Moose does not depend on it anymore. However, it is still
convenient to call it from the conformity strategies.
Nice to know that. But what do you call a conformity strategy?
Still, #propertyNamed: seems a good way to access properties when
displaying them in the UI for an entity, right? Or is there something
I missed?
OK, enough rambling, back to the topic of
pragmas. The attributes
declared by those pragmas should be described with FM3Property,
right? It makes good sense to me, in particular since we could then
request the attributes for their value using #getFrom:
So we could declare such an attribute using <MSEProperty: #NOM
type: ....>.
Then there is custom annotations to such attributes using specific
pragmas, like you propose:
<MSEAnnotation: #longName value: 'pimp my meta-model'>
<MSEAnnotation: #description value: 'Yo dawg, I herd you like
models so we put ...'>
I think such specific annotations should be stored in FM3Element,
with accessors.
Also there should be a mean to query enclosed elements based on
such annotations, like: I should be able to ask a
FM3MetaDescription for all its attributes which declare a
'description' annotation.
In Moose/Meta we subclassed Property with a class that has longName
and description fields, and we had a specialized PragmaProcessor
that knew how to read those annotations. I agree that there these
classes did not have much behavior, but it was easier to grasp. Annotations linked to meta
Properties
can be an overkill for the matter at hand. On the other hand, if
Annotations could be attached to any Element, this could be a nice
way to comment the meta-model.
I think so.
Now there are other annotations use elsewhere in Moose, like the
<navigation> ones. Currently, I dont know how they are dealt with.
Cheers,
Doru
--
Simon
On 10 déc. 08, at 00:00, Adrian Kuhn wrote:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"To lead is not to demand things, it is to make them happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Simon,
As I understand you have "custom attributes" in your metamodel and
want to specify them using pragmas. Further you would like Fame to
parse and handle these pragmas.
I dont have a solution ready for this. Which is not a surprise,
Fame grows only when need arises. Do you have suggestions how to
solve it? What would be best for your need?
Would something alonge these lines help you:
<MSEAnnotation: #longName value: 'pimp my meta-model'>
<MSEAnnotation: #description value: 'Yo dawg, I herd you like
models so we put ...'>
cheers,
AA
--
Follow me http://twitter.com/akuhn
On 08.12.2008, at 12:16, Simon Denier wrote:
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi
I was wondering how some pragmas should be handled in Moose?
Apparently there is currently two "kind" of pragmas in use: the
ones which begin with MSESomething are used to describe the model
in Fame. But there is also a range of
"property:longName:description:" pragmas which are used to
describe entity properties like "numberOfMethods",
"numberOfAccesses"...
Such pragmas allow a generic mean to access some metrics, using
MooseEntity#propertyNamed:
But the implementation of #propertyNamed: relies on attributes
which should be described in the metamodel.
Now it seems that the responsibility to parse and interpret those
pragmas belongs to Fame. Currently they are not handled, and I
just found a TODO note in
FM3MetaDescription#attributeNamed:ifAbsent:
--
Simon
11:36 p.m.
New subject: [Fame-dev] Property pragmas handling
Hi Simon,
Oups sorry Doru, I did not say it was wrong, it was just a plain old
summary statement of the current state as I was clarifying my
understanding of the code.
Oh, do not apologize for things like this. I do not get upset that
easily :)
All the classes that start with CF (in the Moose-ConformityStrategies
package). In the VW browser, you get an input box to query a group.
Behind that there is a ConformityStrategy which is nothing but a
simple AST for a simple boolean language. It's called Conformity
because for a query of NOM > 10 it can say either true/false, or a
percentage of conformity. For example, if NOM = 20 then, the result
would be 200%.
Just subclass Property and that is it.
In VW we have a MetaNavigation class.
Cheers,
Doru
--
www.tudorgirba.com
www.tudorgirba.com/blog
"To lead is not to demand things, it is to make them happen."
The fact is, the cache is built on top of the
metamodel, but it
should not be a concern of the metamodel.
The propertyNamed: cache mechanism is not the concern of the meta-
model. It is the concern of each object, and it is the object that
decide to compute something based on the information from the meta-
description. The meta-model does not know anything about such a
mechanism.
I do not see why this would be wrong. Actually, I was thinking yesterday if pushing the
cache as a generic
mechanism into the metamodel would make sense but, too much hurdles
for no improvment. So I almost wrote this for myself :)
Ok, I misunderstood that you were criticizing my beautiful design that
evolved from one thing and ended up being something else that is not
really useful anymore :).
In any case,
propertyNamed: was a method used heavily long time
ago, when we did not have methods for each property. So, most of
the code in Moose does not depend on it anymore. However, it is
still convenient to call it from the conformity strategies.
Nice to know that. But what do you call a conformity strategy? Still, #propertyNamed: seems a good way to access
properties when
displaying them in the UI for an entity, right? Or is there
something I missed?
Not really. You should be able to get a similar result by directly
getting it from the object via mmGet: (in Meta).
In Moose/Meta
we subclassed Property with a class that has longName
and description fields, and we had a specialized PragmaProcessor
that knew how to read those annotations. I agree that there these
classes did not have much behavior,
How easy could this be in Fame? but it was
easier to grasp. Annotations linked to meta Properties
can be an overkill for the matter at hand. On the other hand, if
Annotations could be attached to any Element, this could be a nice
way to comment the meta-model.
I think so.
Now there are other annotations use elsewhere in Moose, like the
<navigation> ones. Currently, I dont know how they are dealt with.
Cheers,
Doru
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 10 déc. 08, at 00:00, Adrian Kuhn wrote:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"To lead is not to demand things, it is to make them happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Simon,
As I understand you have "custom attributes" in your metamodel
and want to specify them using pragmas. Further you would like
Fame to parse and handle these pragmas.
I dont have a solution ready for this. Which is not a surprise,
Fame grows only when need arises. Do you have suggestions how to
solve it? What would be best for your need?
Would something alonge these lines help you:
<MSEAnnotation: #longName value: 'pimp my meta-model'>
<MSEAnnotation: #description value: 'Yo dawg, I herd you like
models so we put ...'>
cheers,
AA
--
Follow me http://twitter.com/akuhn
On 08.12.2008, at 12:16, Simon Denier wrote:
> Hi
>
> I was wondering how some pragmas should be handled in Moose?
> Apparently there is currently two "kind" of pragmas in use: the
> ones which begin with MSESomething are used to describe the
> model in Fame. But there is also a range of
> "property:longName:description:" pragmas which are used to
> describe entity properties like "numberOfMethods",
> "numberOfAccesses"...
>
> Such pragmas allow a generic mean to access some metrics, using
> MooseEntity#propertyNamed:
> But the implementation of #propertyNamed: relies on attributes
> which should be described in the metamodel.
>
> Now it seems that the responsibility to parse and interpret
> those pragmas belongs to Fame. Currently they are not handled,
> and I just found a TODO note in
> FM3MetaDescription#attributeNamed:ifAbsent:
>
>
>
> --
> Simon
>
>
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5863
days inactive
5866
days old
7 comments
4 participants
participants (4)
-
Adrian Kuhn -
Itsme (Sophie) -
Simon Denier -
Tudor Girba