<MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> vs <MSEClass: #Association super: #FAMIXSourcedEntity>

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

<MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> vs <MSEClass: #Association super: #FAMIXSourcedEntity>

Stéphane Ducasse
Hi guys

Is there a reason why we get
                #Attribute and not FAMIXAttribute

and/or
                super: #FAMIXStructuredEntity
        instead of

                super: 'FAMIX.StructuredEntity'

So I would prefer to have something regular
either

        #'FAMIX.Attribute' super: #'FAMIX.StructuredEntity'
        or
        #Attribute super: #StructuredEntity
       
In fact I would prefer
       
        #'FAMIXAttribute' super: #'FAMIXStructuredEntity'

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: <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> vs <MSEClass: #Association super: #FAMIXSourcedEntity>

Tudor Girba-2
Hi,

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

> Hi guys
>
> Is there a reason why we get
> #Attribute and not FAMIXAttribute

I do not understand. Do you refer to the name of the MetaDescription? If yes, that is because the qualified name is 'FAMIX.Attribute', given that it belongs to the FAMIX package. So, there is no need to prefix the class name.

> and/or
> super: #FAMIXStructuredEntity
> instead of
>
> super: 'FAMIX.StructuredEntity'


Ok, this is pretty much crappy :). #FAMIXStructuredEntity will perform a lookup of the class in the Smalltalk image. 'FAMIX.StructuredEntity' will perform it in the Fame meta repository. We should only use symbols because they are also affected by refactorings. I will create a rule :).

> So I would prefer to have something regular
> either
>
> #'FAMIX.Attribute' super: #'FAMIX.StructuredEntity'
> or
> #Attribute super: #StructuredEntity
>
> In fact I would prefer
>
> #'FAMIXAttribute' super: #'FAMIXStructuredEntity

No. It should be:
MSEClass: 'Attribute' super: #FAMIXStructuralEntity

Cheers,
Doru


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

--
www.tudorgirba.com

"What is more important: To be happy, or to make happy?"


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

Re: <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> vs <MSEClass: #Association super: #FAMIXSourcedEntity>

Stéphane Ducasse

On Sep 24, 2011, at 10:00 AM, Tudor Girba wrote:

> Hi,
>
> On 23 Sep 2011, at 22:15, Stéphane Ducasse wrote:
>
>> Hi guys
>>
>> Is there a reason why we get
>> #Attribute and not FAMIXAttribute
>
> I do not understand. Do you refer to the name of the MetaDescription? If yes, that is because the qualified name is 'FAMIX.Attribute', given that it belongs to the FAMIX package. So, there is no need to prefix the class name.
>
>> and/or
>> super: #FAMIXStructuredEntity
>> instead of
>>
>> super: 'FAMIX.StructuredEntity'
>
>
> Ok, this is pretty much crappy :). #FAMIXStructuredEntity will perform a lookup of the class in the Smalltalk image. 'FAMIX.StructuredEntity' will perform it in the Fame meta repository. We should only use symbols because they are also affected by refactorings. I will create a rule :).

I do not get it.
Why two different lookup for a single position argument because
we jhave in the image

        <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> and
        <MSEClass: #Association super: #FAMIXSourcedEntity>

And to me super: is the same kind of lookup not two.

>
>> So I would prefer to have something regular
>> either
>>
>> #'FAMIX.Attribute' super: #'FAMIX.StructuredEntity'
>> or
>> #Attribute super: #StructuredEntity
>>
>> In fact I would prefer
>>
>> #'FAMIXAttribute' super: #'FAMIXStructuredEntity
>
> No. It should be:
> MSEClass: 'Attribute' super: #FAMIXStructuralEntity

I try to understand what you meant

If
        FAMIXStructuralEntity is to look up the FMClass in the metatower and look for the
                        MSEClass: 'StructuralEntity' super: #Whatwever

Then I do not get why it should be #FAMIXStructuralEntity
        MSEClass: 'Attribute' super: #FAMIXStructuralEntity

and not
        MSEClass: 'Attribute' super: #StructuralEntity


Finally I do not get the need to have FAMIX in front of the second one
because it looks like you hardocde in the anme the package and this is not nice and looks bad

MSEClass: #Attribute# super: #StructuralEntity package: #FAMIX

would be better to me.

Then I do not see why you have a string and a symbol this makes everything more complex

> MSEClass: 'Attribute' super: #FAMIXStructuralEntity

So MSEClass: 'Attribute' super: #FAMIXStructuralEntity does not satisfy me
So tell me and we fix it but once for all.



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: <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> vs <MSEClass: #Association super: #FAMIXSourcedEntity>

Tudor Girba-2
Hi,

On 24 Sep 2011, at 10:21, Stéphane Ducasse wrote:

>
> On Sep 24, 2011, at 10:00 AM, Tudor Girba wrote:
>
>> Hi,
>>
>> On 23 Sep 2011, at 22:15, Stéphane Ducasse wrote:
>>
>>> Hi guys
>>>
>>> Is there a reason why we get
>>> #Attribute and not FAMIXAttribute
>>
>> I do not understand. Do you refer to the name of the MetaDescription? If yes, that is because the qualified name is 'FAMIX.Attribute', given that it belongs to the FAMIX package. So, there is no need to prefix the class name.
>>
>>> and/or
>>> super: #FAMIXStructuredEntity
>>> instead of
>>>
>>> super: 'FAMIX.StructuredEntity'
>>
>>
>> Ok, this is pretty much crappy :). #FAMIXStructuredEntity will perform a lookup of the class in the Smalltalk image. 'FAMIX.StructuredEntity' will perform it in the Fame meta repository. We should only use symbols because they are also affected by refactorings. I will create a rule :).
>
> I do not get it.
> Why two different lookup for a single position argument because
> we jhave in the image
>
> <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> and
> <MSEClass: #Association super: #FAMIXSourcedEntity>
>
> And to me super: is the same kind of lookup not two.

I know. That is why I said I did not like it (=crappy). We had this argument before, but Adrian wanted it this way, and it remained like this. The reason is that sometimes (in 0.001% of cases) you might have an entity that is only defined in Fame but not directly in Smalltalk. In that case, you want to look it up in Fame, not in Smalltalk.

Now we can change it and only provide the Smalltalk based lookup.

>>
>>> So I would prefer to have something regular
>>> either
>>>
>>> #'FAMIX.Attribute' super: #'FAMIX.StructuredEntity'
>>> or
>>> #Attribute super: #StructuredEntity
>>>
>>> In fact I would prefer
>>>
>>> #'FAMIXAttribute' super: #'FAMIXStructuredEntity
>>
>> No. It should be:
>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>
> I try to understand what you meant
>
> If
> FAMIXStructuralEntity is to look up the FMClass in the metatower and look for the
> MSEClass: 'StructuralEntity' super: #Whatwever
>
> Then I do not get why it should be #FAMIXStructuralEntity
> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>
> and not
> MSEClass: 'Attribute' super: #StructuralEntity

You have the have the fully qualified name, not just the name of the meta description (you might have two in two distinct packages).

> Finally I do not get the need to have FAMIX in front of the second one
> because it looks like you hardocde in the anme the package and this is not nice and looks bad
>
> MSEClass: #Attribute# super: #StructuralEntity package: #FAMIX

Fame already provides a lookup based on the fully qualified name, so we can safely use that.

> would be better to me.
>
> Then I do not see why you have a string and a symbol this makes everything more complex

See the above explanation.

>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>
> So MSEClass: 'Attribute' super: #FAMIXStructuralEntity does not satisfy me

It should :).

> So tell me and we fix it but once for all.

#FAMIXStructuralEntity points to the name of the Smalltalk class. There is no other way around it. This is the most robust way of referring to the superclass because if we rename the Smalltalk class, the pragma will be updated as well (it's a symbol).

So, everywhere we have superclass: we should have the name of the Smalltalk class.

Now, that we are at it, we should introduce also only FM3Class: pragma and rely on the default Smalltalk superclass information. Like this we do not have to maintain it at all. Again, this is something I argued a while ago, but did not get introduced.

Cheers,
Doru

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

--
www.tudorgirba.com

"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."




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

Re: <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> vs <MSEClass: #Association super: #FAMIXSourcedEntity>

Stéphane Ducasse
>>>
>>>
>>>> Hi guys
>>>>
>>>> Is there a reason why we get
>>>> #Attribute and not FAMIXAttribute
>>>
>>> I do not understand. Do you refer to the name of the MetaDescription? If yes, that is because the qualified name is 'FAMIX.Attribute', given that it belongs to the FAMIX package. So, there is no need to prefix the class name.
>>>
>>>> and/or
>>>> super: #FAMIXStructuredEntity
>>>> instead of
>>>>
>>>> super: 'FAMIX.StructuredEntity'
>>>
>>>
>>> Ok, this is pretty much crappy :). #FAMIXStructuredEntity will perform a lookup of the class in the Smalltalk image. 'FAMIX.StructuredEntity' will perform it in the Fame meta repository. We should only use symbols because they are also affected by refactorings. I will create a rule :).
>>
>> I do not get it.
>> Why two different lookup for a single position argument because
>> we jhave in the image
>>
>> <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> and
>> <MSEClass: #Association super: #FAMIXSourcedEntity>
>>
>> And to me super: is the same kind of lookup not two.
>
> I know. That is why I said I did not like it (=crappy). We had this argument before, but Adrian wanted it this way, and it remained like this. The reason is that sometimes (in 0.001% of cases) you might have an entity that is only defined in Fame but not directly in Smalltalk. In that case, you want to look it up in Fame, not in Smalltalk.
>
> Now we can change it and only provide the Smalltalk based lookup.

Ok I was not aware of the difference.
Now do you have a good scenario where we would like to have a class only in fame. I do not see one.


>>>> So I would prefer to have something regular
>>>> either
>>>>
>>>> #'FAMIX.Attribute' super: #'FAMIX.StructuredEntity'
>>>> or
>>>> #Attribute super: #StructuredEntity
>>>>
>>>> In fact I would prefer
>>>>
>>>> #'FAMIXAttribute' super: #'FAMIXStructuredEntity
>>>
>>> No. It should be:
>>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>>
>> I try to understand what you meant
>>
>> If
>> FAMIXStructuralEntity is to look up the FMClass in the metatower and look for the
>> MSEClass: 'StructuralEntity' super: #Whatwever
>>
>> Then I do not get why it should be #FAMIXStructuralEntity
>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>>
>> and not
>> MSEClass: 'Attribute' super: #StructuralEntity
>
> You have the have the fully qualified name, not just the name of the meta description (you might have two in two distinct packages).

OK then why not doing it for the name too?


>
>> Finally I do not get the need to have FAMIX in front of the second one
>> because it looks like you hardocde in the anme the package and this is not nice and looks bad
>>
>> MSEClass: #Attribute# super: #StructuralEntity package: #FAMIX
>
> Fame already provides a lookup based on the fully qualified name, so we can safely use that.

So do you mean that we should apply
>> MSEClass: #Attribute# super: #StructuralEntity package: #FAMIX

?

>
>> would be better to me.
>>
>> Then I do not see why you have a string and a symbol this makes everything more complex
>
> See the above explanation.
>
>>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>>
>> So MSEClass: 'Attribute' super: #FAMIXStructuralEntity does not satisfy me
>
> It should :).

I do not understand

If MSEClass: define a fame class named Attribute why its superclass would be reference to a smalltalk class?
Why not to a fame class and that a fame class knows its implementing class.
I do not like that we are not at the same level.


>> So tell me and we fix it but once for all.
>
> #FAMIXStructuralEntity points to the name of the Smalltalk class. There is no other way around it.

Why?
Because
we could say the please create the fame class attribute that inherits from the fame class structural entity.
And the property would be annotated with the fact that
        Attribute is linked to the class that defines the pragma and structural entity is linked to the class that defined it.


I do not see why we need crossing level and mess at the declaration level.

> This is the most robust way of referring to the superclass because if we rename the Smalltalk class, the pragma will be updated as well (it's a symbol).

if we rename the class the meta model should be rebuild

> So, everywhere we have superclass: we should have the name of the Smalltalk class.

I find that not really nice.
At least we should change the pragma to be less obscure

        FMClass: smalltalkSuperclass:

> Now, that we are at it, we should introduce also only FM3Class: pragma and rely on the default Smalltalk superclass information.


so you means removing the string and the . notation in the superclass ?

> Like this we do not have to maintain it at all. Again, this is something I argued a while ago, but did not get introduced.
>
> Cheers,
> Doru
>
>

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

Re: <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> vs <MSEClass: #Association super: #FAMIXSourcedEntity>

Tudor Girba-2
Hi Stef,

I will reply in one batch.

Having meta descriptions is nice and powerful, but at least in Moose, we want to have a 1-to-1 mapping between the meta-description and implementation. That means that we will have one Smalltalk class corresponding to one Fame class.

Also to make it simple, in most cases, we will have the superclass relationship kept in the same area. Suppose you have:

SmalltalkClassA <-> FM3MetaDescription(P.A)
SmalltalkClassB <-> FM3MetaDescription(P.B)

And now, SmalltalkClassB superclass = SmalltalkClassA.

In this case, the superclass of FM3MetaDescription(B) should be FM3MetaDescription(A). This is desirable in 99.99% of the cases. So, this is what we should optimize for.

The only case we have until now where we do not want this, is in FAMIXEntity which has as superclass Object, instead of the implementation class MooseEntity. This is because we want to be able to generate FAMIX in Java without carrying the MooseEntity class with us.

Now, let's go to our original example. Currently, you can define it in two ways:

1) SmalltalkClassB class>>annotation
        <MSEClass:'B' superclass: 'P.A'>
        <package: 'P'>

2) SmalltalkClassB class>>annotation
        <MSEClass:'B' superclass: #SmalltalkClassA>
        <package: 'P'>


In our case, we do not want 1) (even if you write it like superclass: #A package: #P), because the issue is that if I later rename 'A' to 'X', the string in class B will not get refactored. But, in 2) I refer to #SmalltalkClassA, which is more robust. Furthermore, looking for the references in of SmalltalkClassB will get me to the pragma, which is another benefit. These are especially important when you build a new meta-model.

I am not worried at all about mixing meta-levels. It is actually a way to enforce the practice of having a 1-to-1 mapping. In any case, the pragmatic solution is much more important. Btw, we currently have 108 subclasses of MooseEntity.

So, all in all, we should point to Smalltalk implementations as much as possible. I like the idea of having another pragma that will be used for pointing to Fame strings, but its use should be discouraged in most cases.

However, except when we want a different inheritance we should simply use:

3) SmalltalkClassB class>>annotation
        <FM3Class:'B'>
        <FM3Package: 'P'>


In most cases, we do not want to get rid of the name because we have packages. So, FAMIXClass will correspond to FAMIX.Class in Fame. This is why we probably still want to define explicitly both the name and the package of the Fame class. But, maybe we can find a cleverer scheme.

Does this answer your questions?

Cheers,
Doru


On 24 Sep 2011, at 22:43, Stéphane Ducasse wrote:

>>>>
>>>>
>>>>> Hi guys
>>>>>
>>>>> Is there a reason why we get
>>>>> #Attribute and not FAMIXAttribute
>>>>
>>>> I do not understand. Do you refer to the name of the MetaDescription? If yes, that is because the qualified name is 'FAMIX.Attribute', given that it belongs to the FAMIX package. So, there is no need to prefix the class name.
>>>>
>>>>> and/or
>>>>> super: #FAMIXStructuredEntity
>>>>> instead of
>>>>>
>>>>> super: 'FAMIX.StructuredEntity'
>>>>
>>>>
>>>> Ok, this is pretty much crappy :). #FAMIXStructuredEntity will perform a lookup of the class in the Smalltalk image. 'FAMIX.StructuredEntity' will perform it in the Fame meta repository. We should only use symbols because they are also affected by refactorings. I will create a rule :).
>>>
>>> I do not get it.
>>> Why two different lookup for a single position argument because
>>> we jhave in the image
>>>
>>> <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> and
>>> <MSEClass: #Association super: #FAMIXSourcedEntity>
>>>
>>> And to me super: is the same kind of lookup not two.
>>
>> I know. That is why I said I did not like it (=crappy). We had this argument before, but Adrian wanted it this way, and it remained like this. The reason is that sometimes (in 0.001% of cases) you might have an entity that is only defined in Fame but not directly in Smalltalk. In that case, you want to look it up in Fame, not in Smalltalk.
>>
>> Now we can change it and only provide the Smalltalk based lookup.
>
> Ok I was not aware of the difference.
> Now do you have a good scenario where we would like to have a class only in fame. I do not see one.
>
>
>>>>> So I would prefer to have something regular
>>>>> either
>>>>>
>>>>> #'FAMIX.Attribute' super: #'FAMIX.StructuredEntity'
>>>>> or
>>>>> #Attribute super: #StructuredEntity
>>>>>
>>>>> In fact I would prefer
>>>>>
>>>>> #'FAMIXAttribute' super: #'FAMIXStructuredEntity
>>>>
>>>> No. It should be:
>>>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>>>
>>> I try to understand what you meant
>>>
>>> If
>>> FAMIXStructuralEntity is to look up the FMClass in the metatower and look for the
>>> MSEClass: 'StructuralEntity' super: #Whatwever
>>>
>>> Then I do not get why it should be #FAMIXStructuralEntity
>>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>>>
>>> and not
>>> MSEClass: 'Attribute' super: #StructuralEntity
>>
>> You have the have the fully qualified name, not just the name of the meta description (you might have two in two distinct packages).
>
> OK then why not doing it for the name too?
>
>
>>
>>> Finally I do not get the need to have FAMIX in front of the second one
>>> because it looks like you hardocde in the anme the package and this is not nice and looks bad
>>>
>>> MSEClass: #Attribute# super: #StructuralEntity package: #FAMIX
>>
>> Fame already provides a lookup based on the fully qualified name, so we can safely use that.
>
> So do you mean that we should apply
>>> MSEClass: #Attribute# super: #StructuralEntity package: #FAMIX
>
> ?
>
>>
>>> would be better to me.
>>>
>>> Then I do not see why you have a string and a symbol this makes everything more complex
>>
>> See the above explanation.
>>
>>>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>>>
>>> So MSEClass: 'Attribute' super: #FAMIXStructuralEntity does not satisfy me
>>
>> It should :).
>
> I do not understand
>
> If MSEClass: define a fame class named Attribute why its superclass would be reference to a smalltalk class?
> Why not to a fame class and that a fame class knows its implementing class.
> I do not like that we are not at the same level.
>
>
>>> So tell me and we fix it but once for all.
>>
>> #FAMIXStructuralEntity points to the name of the Smalltalk class. There is no other way around it.
>
> Why?
> Because
> we could say the please create the fame class attribute that inherits from the fame class structural entity.
> And the property would be annotated with the fact that
> Attribute is linked to the class that defines the pragma and structural entity is linked to the class that defined it.
>
>
> I do not see why we need crossing level and mess at the declaration level.
>
>> This is the most robust way of referring to the superclass because if we rename the Smalltalk class, the pragma will be updated as well (it's a symbol).
>
> if we rename the class the meta model should be rebuild
>
>> So, everywhere we have superclass: we should have the name of the Smalltalk class.
>
> I find that not really nice.
> At least we should change the pragma to be less obscure
>
> FMClass: smalltalkSuperclass:
>
>> Now, that we are at it, we should introduce also only FM3Class: pragma and rely on the default Smalltalk superclass information.
>
>
> so you means removing the string and the . notation in the superclass ?
>
>> Like this we do not have to maintain it at all. Again, this is something I argued a while ago, but did not get introduced.
>>
>> Cheers,
>> Doru
>>
>>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."




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

Re: <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> vs <MSEClass: #Association super: #FAMIXSourcedEntity>

Stéphane Ducasse

On Sep 24, 2011, at 11:28 PM, Tudor Girba wrote:

> Hi Stef,
>
> I will reply in one batch.

Excellent!
I have toi run now but I will really read it carefully.

>
> Having meta descriptions is nice and powerful, but at least in Moose, we want to have a 1-to-1 mapping between the meta-description and implementation. That means that we will have one Smalltalk class corresponding to one Fame class.
>
> Also to make it simple, in most cases, we will have the superclass relationship kept in the same area. Suppose you have:
>
> SmalltalkClassA <-> FM3MetaDescription(P.A)
> SmalltalkClassB <-> FM3MetaDescription(P.B)
>
> And now, SmalltalkClassB superclass = SmalltalkClassA.
>
> In this case, the superclass of FM3MetaDescription(B) should be FM3MetaDescription(A). This is desirable in 99.99% of the cases. So, this is what we should optimize for.
>
> The only case we have until now where we do not want this, is in FAMIXEntity which has as superclass Object, instead of the implementation class MooseEntity. This is because we want to be able to generate FAMIX in Java without carrying the MooseEntity class with us.
>
> Now, let's go to our original example. Currently, you can define it in two ways:
>
> 1) SmalltalkClassB class>>annotation
> <MSEClass:'B' superclass: 'P.A'>
> <package: 'P'>
>
> 2) SmalltalkClassB class>>annotation
> <MSEClass:'B' superclass: #SmalltalkClassA>
> <package: 'P'>
>
>
> In our case, we do not want 1) (even if you write it like superclass: #A package: #P), because the issue is that if I later rename 'A' to 'X', the string in class B will not get refactored. But, in 2) I refer to #SmalltalkClassA, which is more robust. Furthermore, looking for the references in of SmalltalkClassB will get me to the pragma, which is another benefit. These are especially important when you build a new meta-model.
>
> I am not worried at all about mixing meta-levels. It is actually a way to enforce the practice of having a 1-to-1 mapping. In any case, the pragmatic solution is much more important. Btw, we currently have 108 subclasses of MooseEntity.
>
> So, all in all, we should point to Smalltalk implementations as much as possible. I like the idea of having another pragma that will be used for pointing to Fame strings, but its use should be discouraged in most cases.
>
> However, except when we want a different inheritance we should simply use:
>
> 3) SmalltalkClassB class>>annotation
> <FM3Class:'B'>
> <FM3Package: 'P'>
>
>
> In most cases, we do not want to get rid of the name because we have packages. So, FAMIXClass will correspond to FAMIX.Class in Fame. This is why we probably still want to define explicitly both the name and the package of the Fame class. But, maybe we can find a cleverer scheme.
>
> Does this answer your questions?
>
> Cheers,
> Doru
>
>
> On 24 Sep 2011, at 22:43, Stéphane Ducasse wrote:
>
>>>>>
>>>>>
>>>>>> Hi guys
>>>>>>
>>>>>> Is there a reason why we get
>>>>>> #Attribute and not FAMIXAttribute
>>>>>
>>>>> I do not understand. Do you refer to the name of the MetaDescription? If yes, that is because the qualified name is 'FAMIX.Attribute', given that it belongs to the FAMIX package. So, there is no need to prefix the class name.
>>>>>
>>>>>> and/or
>>>>>> super: #FAMIXStructuredEntity
>>>>>> instead of
>>>>>>
>>>>>> super: 'FAMIX.StructuredEntity'
>>>>>
>>>>>
>>>>> Ok, this is pretty much crappy :). #FAMIXStructuredEntity will perform a lookup of the class in the Smalltalk image. 'FAMIX.StructuredEntity' will perform it in the Fame meta repository. We should only use symbols because they are also affected by refactorings. I will create a rule :).
>>>>
>>>> I do not get it.
>>>> Why two different lookup for a single position argument because
>>>> we jhave in the image
>>>>
>>>> <MSEClass: #Attribute super: 'FAMIX.StructuralEntity'> and
>>>> <MSEClass: #Association super: #FAMIXSourcedEntity>
>>>>
>>>> And to me super: is the same kind of lookup not two.
>>>
>>> I know. That is why I said I did not like it (=crappy). We had this argument before, but Adrian wanted it this way, and it remained like this. The reason is that sometimes (in 0.001% of cases) you might have an entity that is only defined in Fame but not directly in Smalltalk. In that case, you want to look it up in Fame, not in Smalltalk.
>>>
>>> Now we can change it and only provide the Smalltalk based lookup.
>>
>> Ok I was not aware of the difference.
>> Now do you have a good scenario where we would like to have a class only in fame. I do not see one.
>>
>>
>>>>>> So I would prefer to have something regular
>>>>>> either
>>>>>>
>>>>>> #'FAMIX.Attribute' super: #'FAMIX.StructuredEntity'
>>>>>> or
>>>>>> #Attribute super: #StructuredEntity
>>>>>>
>>>>>> In fact I would prefer
>>>>>>
>>>>>> #'FAMIXAttribute' super: #'FAMIXStructuredEntity
>>>>>
>>>>> No. It should be:
>>>>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>>>>
>>>> I try to understand what you meant
>>>>
>>>> If
>>>> FAMIXStructuralEntity is to look up the FMClass in the metatower and look for the
>>>> MSEClass: 'StructuralEntity' super: #Whatwever
>>>>
>>>> Then I do not get why it should be #FAMIXStructuralEntity
>>>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>>>>
>>>> and not
>>>> MSEClass: 'Attribute' super: #StructuralEntity
>>>
>>> You have the have the fully qualified name, not just the name of the meta description (you might have two in two distinct packages).
>>
>> OK then why not doing it for the name too?
>>
>>
>>>
>>>> Finally I do not get the need to have FAMIX in front of the second one
>>>> because it looks like you hardocde in the anme the package and this is not nice and looks bad
>>>>
>>>> MSEClass: #Attribute# super: #StructuralEntity package: #FAMIX
>>>
>>> Fame already provides a lookup based on the fully qualified name, so we can safely use that.
>>
>> So do you mean that we should apply
>>>> MSEClass: #Attribute# super: #StructuralEntity package: #FAMIX
>>
>> ?
>>
>>>
>>>> would be better to me.
>>>>
>>>> Then I do not see why you have a string and a symbol this makes everything more complex
>>>
>>> See the above explanation.
>>>
>>>>> MSEClass: 'Attribute' super: #FAMIXStructuralEntity
>>>>
>>>> So MSEClass: 'Attribute' super: #FAMIXStructuralEntity does not satisfy me
>>>
>>> It should :).
>>
>> I do not understand
>>
>> If MSEClass: define a fame class named Attribute why its superclass would be reference to a smalltalk class?
>> Why not to a fame class and that a fame class knows its implementing class.
>> I do not like that we are not at the same level.
>>
>>
>>>> So tell me and we fix it but once for all.
>>>
>>> #FAMIXStructuralEntity points to the name of the Smalltalk class. There is no other way around it.
>>
>> Why?
>> Because
>> we could say the please create the fame class attribute that inherits from the fame class structural entity.
>> And the property would be annotated with the fact that
>> Attribute is linked to the class that defines the pragma and structural entity is linked to the class that defined it.
>>
>>
>> I do not see why we need crossing level and mess at the declaration level.
>>
>>> This is the most robust way of referring to the superclass because if we rename the Smalltalk class, the pragma will be updated as well (it's a symbol).
>>
>> if we rename the class the meta model should be rebuild
>>
>>> So, everywhere we have superclass: we should have the name of the Smalltalk class.
>>
>> I find that not really nice.
>> At least we should change the pragma to be less obscure
>>
>> FMClass: smalltalkSuperclass:
>>
>>> Now, that we are at it, we should introduce also only FM3Class: pragma and rely on the default Smalltalk superclass information.
>>
>>
>> so you means removing the string and the . notation in the superclass ?
>>
>>> Like this we do not have to maintain it at all. Again, this is something I argued a while ago, but did not get introduced.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."
>
>
>
>
> _______________________________________________
> 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