What's a sensible definition of FAMIXMethod>>incomingAccesses?
Locked
What's a sensible definition of FAMIXMethod>>incomingAccesses?
 
|
Take a look at the following definitions:
FAMIXClass>>qIncomingAccesses ^ self attributes flatCollect: [ :each | each incomingAccesses ] FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" ^ self classes flatCollect: [ :c | c qIncomingAccesses ] Now does it make sense to have a similar definition for FAMIXMethod? FAMIXMethod>>qIncomingAccesses ^ (self parameters collect: #incomingAccesses) addAll: (self localVariables collect: #incomingAccesses); yourself We can't really say there are 'incoming accesses' on attributes in a method. On the contrary, methods are the ones which make (outgoing) accesses to attributes. On the other hand, incoming accesses on parameters and local variables are necessarily from the lexical scope, the method itself: so not a very interesting information. And it's not consistent with the FamixClass and FamixScopingEntity, which collect all access to attributes within their scope. In other words, we can say: aClass qIncomingInvocaions = aClass methods flatCollect: #qIncomingInvocations but: aClass qIncomingAccesses ~= aClass methods flatCollect: #qIncomingAccesses I am wondering if it would not be better to just say: FAMIXMethod>>qIncomingAccesses ^ Array new Or maybe I'm just trying to split hairs -- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: What's a sensible definition of FAMIXMethod>>incomingAccesses?
|
|
Hi!
I do not understand. qIncomingAccesses is not defined in my image. But what does it mean? What "q" is for? "incomingAccesses" is an explicit name. I am lost Alexandre On 12 Jan 2011, at 14:51, Simon Denier wrote: > Take a look at the following definitions: > > > FAMIXClass>>qIncomingAccesses > ^ self attributes flatCollect: [ :each | each incomingAccesses ] > > > FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" > ^ self classes flatCollect: [ :c | c qIncomingAccesses ] > > > Now does it make sense to have a similar definition for FAMIXMethod? > > > FAMIXMethod>>qIncomingAccesses > ^ (self parameters collect: #incomingAccesses) > addAll: (self localVariables collect: #incomingAccesses); > yourself > > > We can't really say there are 'incoming accesses' on attributes in a method. On the contrary, methods are the ones which make (outgoing) accesses to attributes. On the other hand, incoming accesses on parameters and local variables are necessarily from the lexical scope, the method itself: so not a very interesting information. And it's not consistent with the FamixClass and FamixScopingEntity, which collect all access to attributes within their scope. > > In other words, we can say: > aClass qIncomingInvocaions = aClass methods flatCollect: #qIncomingInvocations > > but: > aClass qIncomingAccesses ~= aClass methods flatCollect: #qIncomingAccesses > > > I am wondering if it would not be better to just say: > > FAMIXMethod>>qIncomingAccesses > > ^ Array new > > > Or maybe I'm just trying to split hairs > > -- > Simon > > > > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: What's a sensible definition of FAMIXMethod>>incomingAccesses?
|
|
In reply to this post by Simon Denier-4
Alex, I understood that q in qIncomigAccesses was some kind of typo.
I ignored it and it made some sense. ----- Mail original ----- > De: "Simon Denier" <[hidden email]> > À: "Moose-related development" <[hidden email]> > Cc: "Simon Denier" <[hidden email]> > Envoyé: Mercredi 12 Janvier 2011 18:51:27 > Objet: [Moose-dev] What's a sensible definition of FAMIXMethod>>incomingAccesses? > Take a look at the following definitions: > > > FAMIXClass>>qIncomingAccesses > ^ self attributes flatCollect: [ :each | each incomingAccesses ] > > > FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" > ^ self classes flatCollect: [ :c | c qIncomingAccesses ] > > > Now does it make sense to have a similar definition for FAMIXMethod? I think you demonstrated that it does not make sense. Method are closed box that don't have persistent state. You cannot access anything inside them except from within themselves. Why would you want to have FAMIXmethod>>incomigAccesses ? > FAMIXMethod>>qIncomingAccesses > ^ (self parameters collect: #incomingAccesses) > addAll: (self localVariables collect: #incomingAccesses); > yourself > > > We can't really say there are 'incoming accesses' on attributes in a > method. On the contrary, methods are the ones which make (outgoing) > accesses to attributes. On the other hand, incoming accesses on > parameters and local variables are necessarily from the lexical scope, > the method itself: so not a very interesting information. And it's not > consistent with the FamixClass and FamixScopingEntity, which collect > all access to attributes within their scope. > > In other words, we can say: > aClass qIncomingInvocaions = aClass methods flatCollect: > #qIncomingInvocations > > but: > aClass qIncomingAccesses ~= aClass methods flatCollect: > #qIncomingAccesses > > > I am wondering if it would not be better to just say: > > FAMIXMethod>>qIncomingAccesses > > ^ Array new > > > Or maybe I'm just trying to split hairs > > -- > Simon > > > > > > > > > _______________________________________________ > 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 |
Re: What's a sensible definition of FAMIXMethod>>incomingAccesses?
|
|
Yeah, don't worry about the q for now, it's just some namespace to avoid potential conflicts with regular Famix extensions. On 12 janv. 2011, at 21:24, Nicolas Anquetil wrote: > Alex, I understood that q in qIncomigAccesses was some kind of typo. > I ignored it and it made some sense. > > ----- Mail original ----- >> De: "Simon Denier" <[hidden email]> >> À: "Moose-related development" <[hidden email]> >> Cc: "Simon Denier" <[hidden email]> >> Envoyé: Mercredi 12 Janvier 2011 18:51:27 >> Objet: [Moose-dev] What's a sensible definition of FAMIXMethod>>incomingAccesses? >> Take a look at the following definitions: >> >> >> FAMIXClass>>qIncomingAccesses >> ^ self attributes flatCollect: [ :each | each incomingAccesses ] >> >> >> FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" >> ^ self classes flatCollect: [ :c | c qIncomingAccesses ] >> >> >> Now does it make sense to have a similar definition for FAMIXMethod? > > I think you demonstrated that it does not make sense. > Method are closed box that don't have persistent state. > You cannot access anything inside them except from within themselves. > > Why would you want to have FAMIXmethod>>incomigAccesses ? > >> FAMIXMethod>>qIncomingAccesses >> ^ (self parameters collect: #incomingAccesses) >> addAll: (self localVariables collect: #incomingAccesses); >> yourself >> >> >> We can't really say there are 'incoming accesses' on attributes in a >> method. On the contrary, methods are the ones which make (outgoing) >> accesses to attributes. On the other hand, incoming accesses on >> parameters and local variables are necessarily from the lexical scope, >> the method itself: so not a very interesting information. And it's not >> consistent with the FamixClass and FamixScopingEntity, which collect >> all access to attributes within their scope. >> >> In other words, we can say: >> aClass qIncomingInvocaions = aClass methods flatCollect: >> #qIncomingInvocations >> >> but: >> aClass qIncomingAccesses ~= aClass methods flatCollect: >> #qIncomingAccesses >> >> >> I am wondering if it would not be better to just say: >> >> FAMIXMethod>>qIncomingAccesses >> >> ^ Array new >> >> >> Or maybe I'm just trying to split hairs >> >> -- >> Simon >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 -- Simon Denier _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: What's a sensible definition of FAMIXMethod>>incomingAccesses?
|
|
Incoming and outgoing is only for specifying the relation direction on the (contained) element, not for specifying the outer or inner scope of the relation origin.
So, FAMIXMethod>>qIncomingAccesses should definitely not be "Array new". It should be like you said first: FAMIXMethod>>qIncomingAccesses ^ (self parameters collect: #incomingAccesses) addAll: (self localVariables collect: #incomingAccesses); yourself Cheers, Doru On 12 Jan 2011, at 22:15, Simon Denier wrote: > > Yeah, don't worry about the q for now, it's just some namespace to avoid potential conflicts with regular Famix extensions. > > > On 12 janv. 2011, at 21:24, Nicolas Anquetil wrote: > >> Alex, I understood that q in qIncomigAccesses was some kind of typo. >> I ignored it and it made some sense. >> >> ----- Mail original ----- >>> De: "Simon Denier" <[hidden email]> >>> À: "Moose-related development" <[hidden email]> >>> Cc: "Simon Denier" <[hidden email]> >>> Envoyé: Mercredi 12 Janvier 2011 18:51:27 >>> Objet: [Moose-dev] What's a sensible definition of FAMIXMethod>>incomingAccesses? >>> Take a look at the following definitions: >>> >>> >>> FAMIXClass>>qIncomingAccesses >>> ^ self attributes flatCollect: [ :each | each incomingAccesses ] >>> >>> >>> FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" >>> ^ self classes flatCollect: [ :c | c qIncomingAccesses ] >>> >>> >>> Now does it make sense to have a similar definition for FAMIXMethod? >> >> I think you demonstrated that it does not make sense. >> Method are closed box that don't have persistent state. >> You cannot access anything inside them except from within themselves. >> >> Why would you want to have FAMIXmethod>>incomigAccesses ? >> >>> FAMIXMethod>>qIncomingAccesses >>> ^ (self parameters collect: #incomingAccesses) >>> addAll: (self localVariables collect: #incomingAccesses); >>> yourself >>> >>> >>> We can't really say there are 'incoming accesses' on attributes in a >>> method. On the contrary, methods are the ones which make (outgoing) >>> accesses to attributes. On the other hand, incoming accesses on >>> parameters and local variables are necessarily from the lexical scope, >>> the method itself: so not a very interesting information. And it's not >>> consistent with the FamixClass and FamixScopingEntity, which collect >>> all access to attributes within their scope. >>> >>> In other words, we can say: >>> aClass qIncomingInvocaions = aClass methods flatCollect: >>> #qIncomingInvocations >>> >>> but: >>> aClass qIncomingAccesses ~= aClass methods flatCollect: >>> #qIncomingAccesses >>> >>> >>> I am wondering if it would not be better to just say: >>> >>> FAMIXMethod>>qIncomingAccesses >>> >>> ^ Array new >>> >>> >>> Or maybe I'm just trying to split hairs >>> >>> -- >>> Simon >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |