[Pharo-project] About SourcedMethodReference
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
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 <luc.fabresse@gmail.com> 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.
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
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
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
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
On Tue, Nov 9, 2010 at 7:22 PM, Benjamin < benjamin.vanryseghem.pharo@gmail.com> 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 =
Why do you want to remove MethodReference?
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
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
On 10 November 2010 15:04, Johan Brichau <johan@inceptive.be> 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.
participants (5)
-
Benjamin -
Eliot Miranda -
Igor Stasenko -
Johan Brichau -
Luc Fabresse