About SourcedMethodReference
Locked
 
|
Hi all, The tests are currently expecting a MethodReference. If I modify the tests to exepect a SourcedMethodReference, the problem is now on:
SourcedMethodReference>>= ^self == aMethodReference. Why this has been redefined in SourcedMethodReference? I think that the super class (MethodReference) implementation is semantically better. No?
MethodReference>>= anotherMethodReference "Answer whether the receiver and the argument represent the same object."
^ self species == anotherMethodReference species and: [(self classSymbol = anotherMethodReference classSymbol)
and: [(self classIsMeta = anotherMethodReference classIsMeta) and: [self methodSymbol = anotherMethodReference methodSymbol]]]
#Luc |
Re: About SourcedMethodReference
|
|
I think identity is better. It forcing more strict rules: no more than
one method reference in system necessary for representing same method. On 9 November 2010 23:48, Luc Fabresse <[hidden email]> wrote: > Hi all, > When SourcedMethodReference have been introduced, some tests in > SystemNavigationTest turned yellow. > The tests are currently expecting a MethodReference. > If I modify the tests to exepect a SourcedMethodReference, the problem is > now on: > SourcedMethodReference>>= > ^self == aMethodReference. > Why this has been redefined in SourcedMethodReference? > I think that the super class (MethodReference) implementation is > semantically better. No? > > MethodReference>>= anotherMethodReference > "Answer whether the receiver and the argument represent the > same object." > ^ self species == anotherMethodReference species > and: [(self classSymbol = anotherMethodReference classSymbol) > and: [(self classIsMeta = anotherMethodReference classIsMeta) > and: [self methodSymbol = anotherMethodReference methodSymbol]]] > #Luc > -- Best regards, Igor Stasenko AKA sig. |
Re: About SourcedMethodReference
|
|
In reply to this post by Luc Fabresse
On Nov 9, 2010, at 10:48 PM, Luc Fabresse wrote: > Hi all, > > When SourcedMethodReference have been introduced, some tests in > SystemNavigationTest turned yellow. > The tests are currently expecting a MethodReference. > If I modify the tests to exepect a SourcedMethodReference, the > problem is now on: > > SourcedMethodReference>>= > ^self == aMethodReference. > > Why this has been redefined in SourcedMethodReference? It has been redefined becausea the end, we want to remove MethodReference, and this is the default behavior for the method = > I think that the super class (MethodReference) implementation is > semantically better. No? > > MethodReference>>= anotherMethodReference > "Answer whether the receiver and the argument represent the > same object." > ^ self species == anotherMethodReference species > and: [(self classSymbol = anotherMethodReference classSymbol) > and: [(self classIsMeta = anotherMethodReference classIsMeta) > and: [self methodSymbol = anotherMethodReference methodSymbol]]] > #Luc This method doesn't answer what we expect anymore, because here, two references (with different source) pointing on two versions of the same method are evaluate as equal, and we do not want that. About tests, JB and I had wrote a fix, but we have lost it ... But I will take a look at that asap Thank you for your feedback Ben |
Re: About SourcedMethodReference
|
|
There is still a lot to be done, so I did not know the changes were already integrated ;-)
But the subclassing construction is temporary to allow code to migrate to the new sourcereference framework. Benjamin: is the latest version in 1.2 or on pharotaskforce or ... ? On 10 Nov 2010, at 04:22, Benjamin wrote: > > On Nov 9, 2010, at 10:48 PM, Luc Fabresse wrote: > >> Hi all, >> >> When SourcedMethodReference have been introduced, some tests in SystemNavigationTest turned yellow. >> The tests are currently expecting a MethodReference. >> If I modify the tests to exepect a SourcedMethodReference, the problem is now on: >> >> SourcedMethodReference>>= >> ^self == aMethodReference. >> >> Why this has been redefined in SourcedMethodReference? > > It has been redefined becausea the end, we want to remove MethodReference, and this is the default behavior for the method = > >> I think that the super class (MethodReference) implementation is semantically better. No? >> >> MethodReference>>= anotherMethodReference >> "Answer whether the receiver and the argument represent the >> same object." >> ^ self species == anotherMethodReference species >> and: [(self classSymbol = anotherMethodReference classSymbol) >> and: [(self classIsMeta = anotherMethodReference classIsMeta) >> and: [self methodSymbol = anotherMethodReference methodSymbol]]] >> #Luc > > This method doesn't answer what we expect anymore, because here, two references (with different source) pointing on two versions of the same method are evaluate as equal, and we do not want that. > > About tests, JB and I had wrote a fix, but we have lost it ... > But I will take a look at that asap > > > Thank you for your feedback > > > Ben > > |
Re: About SourcedMethodReference
|
|
On Nov 10, 2010, at 8:43 AM, Johan Brichau wrote: > There is still a lot to be done, so I did not know the changes were > already integrated ;-) > But the subclassing construction is temporary to allow code to > migrate to the new sourcereference framework. > > Benjamin: is the latest version in 1.2 or on pharotaskforce or ... ? > The last version is in !.2, and I'm still working on killing MethodReference references (I've done a ChangeSorter, I'm still playing with it, expecting for explosions ^^ If you want to play with it too, just say it to me) Ben > > On 10 Nov 2010, at 04:22, Benjamin wrote: > >> >> On Nov 9, 2010, at 10:48 PM, Luc Fabresse wrote: >> >>> Hi all, >>> >>> When SourcedMethodReference have been introduced, some tests in >>> SystemNavigationTest turned yellow. >>> The tests are currently expecting a MethodReference. >>> If I modify the tests to exepect a SourcedMethodReference, the >>> problem is now on: >>> >>> SourcedMethodReference>>= >>> ^self == aMethodReference. >>> >>> Why this has been redefined in SourcedMethodReference? >> >> It has been redefined becausea the end, we want to remove >> MethodReference, and this is the default behavior for the method = >> >>> I think that the super class (MethodReference) implementation is >>> semantically better. No? >>> >>> MethodReference>>= anotherMethodReference >>> "Answer whether the receiver and the argument represent the >>> same object." >>> ^ self species == anotherMethodReference species >>> and: [(self classSymbol = anotherMethodReference classSymbol) >>> and: [(self classIsMeta = anotherMethodReference classIsMeta) >>> and: [self methodSymbol = anotherMethodReference >>> methodSymbol]]] >>> #Luc >> >> This method doesn't answer what we expect anymore, because here, >> two references (with different source) pointing on two versions of >> the same method are evaluate as equal, and we do not want that. >> >> About tests, JB and I had wrote a fix, but we have lost it ... >> But I will take a look at that asap >> >> >> Thank you for your feedback >> >> >> Ben >> >> > > |
Re: About SourcedMethodReference
|
|
In reply to this post by Luc Fabresse
On Nov 9, 2010, at 10:57 PM, Igor Stasenko wrote: > I think identity is better. It forcing more strict rules: no more than > one method reference > in system necessary for representing same method. I'm not sure I understand exactly what you mean. In the recent message or in the versions, you get mulitple version of the "same" methods but different methodreference. > > On 9 November 2010 23:48, Luc Fabresse <[hidden email]> wrote: >> Hi all, >> When SourcedMethodReference have been introduced, some tests in >> SystemNavigationTest turned yellow. >> The tests are currently expecting a MethodReference. >> If I modify the tests to exepect a SourcedMethodReference, the problem is >> now on: >> SourcedMethodReference>>= >> ^self == aMethodReference. >> Why this has been redefined in SourcedMethodReference? >> I think that the super class (MethodReference) implementation is >> semantically better. No? >> >> MethodReference>>= anotherMethodReference >> "Answer whether the receiver and the argument represent the >> same object." >> ^ self species == anotherMethodReference species >> and: [(self classSymbol = anotherMethodReference classSymbol) >> and: [(self classIsMeta = anotherMethodReference classIsMeta) >> and: [self methodSymbol = anotherMethodReference methodSymbol]]] >> #Luc >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
Re: About SourcedMethodReference
|
|
In reply to this post by Benjamin Van Ryseghem (Pharo)
On Tue, Nov 9, 2010 at 7:22 PM, Benjamin <[hidden email]> wrote:
Why do you want to remove MethodReference?
|
Re: About SourcedMethodReference
|
|
In reply to this post by Benjamin Van Ryseghem (Pharo)
> Why do you want to remove MethodReference?
To be able to have MethodReferenceWithSource which will be renamed MethodReference and in the same time not put the system on its knees. ;) Right now MethodReference and friend sucks even if I already fixed a lot of Feature Envy. I do not like the logic to read change files with case statement #Comment .... all the bad logic it implies. There is a lack of real objects there. When you read the code of RecentMessages or recovery you can faint and re fixed a lot of Feature Envy, Duplicated code in 1.2. A lot is happening in 1.2 under the surface and a lot more will happen in 1.3. We want a real declarative model of source code. Veronica will start to work on that. We want to store also **all** the code of all the version in a database so that we can do real versions queries. Now the changes made on MethodReference are to make sure that we can have two methodReference with the same selector, class, but a different timestamp and source code. Like what we see in versions and recent changes, but done in a much better way. Benjaman rewrote completely recentMessages and this is great we can filter recentMessages based on time, class, packages..... and without the changes in MethodReference we had to put isKindOf and other nasty checks all over the place. So in summary, we want to put in place an infrastructure for building next generation tools. Ideally we will have ClassDefinition MethodDefinition InstanceVariableDefinition and migrate all the tools to them. We will experiment with that and certainly build a robust infrastructure for that. I hope it explains. We wrote a document explaining that. But now we should build it. Stef |
Re: About SourcedMethodReference
|
|
In reply to this post by Eliot Miranda-2
On 10 Nov 2010, at 12:14, Eliot Miranda wrote: > Why do you want to remove MethodReference? The work was initiated from Benjamin's work on a new browser for 'recent changes', which basically needs to manipulate source references. MethodReference is being used to this end in various parts of the system but it represents various different things: class comment reference, method source reference, class definition reference, etc.. In addition, it always represents a reference to the current source. To retrieve older versions of the source, you need to walk the changes stream yourself. Last but not least, various different tools are walking the changes file with different implementations. From that experience, the idea arose to create a sourcereference model that explicitly models the different source elements (methods, class comments, definitions, etc) and that has explicit timestamping. At the same time, we don't want to break existing tools and have embedded the exisiting MethodReference in that model. Johan |
Re: About SourcedMethodReference
|
|
On 10 November 2010 15:04, Johan Brichau <[hidden email]> wrote:
> > On 10 Nov 2010, at 12:14, Eliot Miranda wrote: > >> Why do you want to remove MethodReference? > > The work was initiated from Benjamin's work on a new browser for 'recent changes', which basically needs to manipulate source references. > > MethodReference is being used to this end in various parts of the system but it represents various different things: class comment reference, method source reference, class definition reference, etc.. In addition, it always represents a reference to the current source. To retrieve older versions of the source, you need to walk the changes stream yourself. Last but not least, various different tools are walking the changes file with different implementations. > > From that experience, the idea arose to create a sourcereference model that explicitly models the different source elements (methods, class comments, definitions, etc) and that has explicit timestamping. At the same time, we don't want to break existing tools and have embedded the exisiting MethodReference in that model. > +1 and please, keep in mind to delegate retrieving an actual source code to some abstract layer. So, then we can bind any remote storage to it, like database or file system whatever. > Johan > -- Best regards, Igor Stasenko AKA sig. |
Re: About SourcedMethodReference
|
|
In reply to this post by Johan Brichau-2
>>
>> >>> Why do you want to remove MethodReference? >> >> The work was initiated from Benjamin's work on a new browser for 'recent changes', which basically needs to manipulate source references. >> >> MethodReference is being used to this end in various parts of the system but it represents various different things: class comment reference, method source reference, class definition reference, etc.. In addition, it always represents a reference to the current source. To retrieve older versions of the source, you need to walk the changes stream yourself. Last but not least, various different tools are walking the changes file with different implementations. >> >> From that experience, the idea arose to create a sourcereference model that explicitly models the different source elements (methods, class comments, definitions, etc) and that has explicit timestamping. At the same time, we don't want to break existing tools and have embedded the exisiting MethodReference in that model. >> > > +1 > > and please, keep in mind to delegate retrieving an actual source code > to some abstract layer. > So, then we can bind any remote storage to it, like database or file > system whatever. Yes we should probably have a look at method trailer with you but first we should build the infrastructure and test it. Stef |
Re: About SourcedMethodReference
|
|
In reply to this post by Stéphane Ducasse
2010/11/10 Stéphane Ducasse <[hidden email]>
That was my point. And I think that equality of SourcedMethodReference should not be based on identity but a modified version of the MethodReference implementation integrating the version.
#Luc
|
Re: About SourcedMethodReference
|
|
In reply to this post by Benjamin Van Ryseghem (Pharo)
On 10 Nov 2010, at 10:14, Benjamin wrote: > The last version is in !.2, and I'm still working on killing MethodReference references (I've done a ChangeSorter, I'm still playing with it, expecting for explosions ^^ If you want to play with it too, just say it to me) Ok Ben, consider this a yell ;-) I can spend some time on this over the long weekend in Belgium. I'll just work myself back in from the code I can find online Johan |
Re: About SourcedMethodReference
|
|
In reply to this post by Benjamin Van Ryseghem (Pharo)
On Nov 11, 2010, at 7:55 AM, Johan Brichau wrote: > > On 10 Nov 2010, at 10:14, Benjamin wrote: > >> The last version is in !.2, and I'm still working on killing MethodReference references (I've done a ChangeSorter, I'm still playing with it, expecting for explosions ^^ If you want to play with it too, just say it to me) > > Ok Ben, consider this a yell ;-) > I can spend some time on this over the long weekend in Belgium. Excellent. Ben sent me this code to try to fix all the reference to MethodSource but it should be tested because it can toast you :) http://code.google.com/p/pharo/issues/detail?id=3224 > I'll just work myself back in from the code I can find online > > Johan |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |