Re: [Squeak 0005641]: Cannot override default presentation of Methods in a MethodBrowser

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

Re: [Squeak 0005641]: Cannot override default presentation of Methods in a MethodBrowser

Edgar J. De Cleene



El 10/10/07 9:40 AM, "[hidden email]"
<[hidden email]> escribió:

>
> On 10-10-07 12:40, Damien Cassou  sent you this reminder about:
>
> http://bugs.squeak.org/view.php?id=5641
>
> Don't forget this bug!

No, but seems is not ready

> The most recent "RecentChanges" seem to be in the parent report.
>
> Also as this upgrade has already caused problems once, I highly recommend
> there be tests to prove it does not still offend.
>
> I would not even recommend attempting this fix without the tests.


We have a requirement of bugs MUST have test.
Or some other Squeaker say is a good fix.
Here some say this is problematic.
Should I do the update ?
Sorry by answer in list, but this way all working on this could see we are
working.

Edgar




Reply | Threaded
Open this post in threaded view
|

Re: [Squeak 0005641]: Cannot override default presentation of Methods in a MethodBrowser

Nicolas Cellier-3
Some changes from Keith
- made stringVersion inst var lazy initialized
- provided a default value via #stringVersionDefault
- provided a #asStringOrText accessor to replace #stringVersion

The error from Keith was to let the #stringVersion accessor in place,
letting it answer nil, and letting #stringVersion senders in trouble...

Then, you have basically 2 solutions
1) revert to full initialization
2) remove the stringVersion accessor and make the ivar private

jorsaria proposed 1)
MethodReference-setStandardClassmethodSymbol.st
http://bugs.squeak.org/view.php?id=6691

I proposed 2).
StringVersion-Patch-M6691.1.cs
http://bugs.squeak.org/view.php?id=6691

----------------

If you choose 2), then some cosmetic changes might be good to do:
The #stringVersion: accessor should be rename to setStringVersion: and
classified in protocol 'setting', this would be more homogeneous with
the rest of this protocol and enforce that the ivar is kind of private.

For these reasons I would push
StringVersion-Patch-M6691.2.cs
http://bugs.squeak.org/view.php?id=6691

------------------

RecentMessageSet-updateListsAndCodeIn.st
http://bugs.squeak.org/view.php?id=5641

is a reversion to use #stringVersioninstead instead of #asStringOrText
It will not work if ivar is lazy initialized.
So it must go with 1)

------------------

RecentChanges.2.cs
http://bugs.squeak.org/view.php?id=5641

seems a duplication of

RecentChanges.2.cs
http://bugs.squeak.org/view.php?id=6402

What a mess!
Jerome said at http://bugs.squeak.org/view.php?id=6402 that this change
is not viable as refering to classes not in base image

------------------

RecentChanges.3.cs
http://bugs.squeak.org/view.php?id=6402

does use #asStringOrtext but does not rename #stringVersion: to
#setStringVersion:. It seems a good candidate too.
But it does some more work that i did not analyze.
Up to Keith to document his work.
Generally, most changes come from him, so you should ask to him.

Nicolas


Edgar J. De Cleene a écrit :

>
>
> El 10/10/07 9:40 AM, "[hidden email]"
> <[hidden email]> escribió:
>
>> On 10-10-07 12:40, Damien Cassou  sent you this reminder about:
>>
>> http://bugs.squeak.org/view.php?id=5641
>>
>> Don't forget this bug!
>
> No, but seems is not ready
>
>> The most recent "RecentChanges" seem to be in the parent report.
>>
>> Also as this upgrade has already caused problems once, I highly recommend
>> there be tests to prove it does not still offend.
>>
>> I would not even recommend attempting this fix without the tests.
>
>
> We have a requirement of bugs MUST have test.
> Or some other Squeaker say is a good fix.
> Here some say this is problematic.
> Should I do the update ?
> Sorry by answer in list, but this way all working on this could see we are
> working.
>
> Edgar
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Squeak 0005641]: Cannot override default presentation of Methods in a MethodBrowser

Edgar J. De Cleene



El 10/10/07 5:05 PM, "nicolas cellier" <[hidden email]> escribió:

> Some changes from Keith
> - made stringVersion inst var lazy initialized
> - provided a default value via #stringVersionDefault
> - provided a #asStringOrText accessor to replace #stringVersion
>
> The error from Keith was to let the #stringVersion accessor in place,
> letting it answer nil, and letting #stringVersion senders in trouble...
>
> Then, you have basically 2 solutions
> 1) revert to full initialization
> 2) remove the stringVersion accessor and make the ivar private
>
> jorsaria proposed 1)
> MethodReference-setStandardClassmethodSymbol.st
> http://bugs.squeak.org/view.php?id=6691
>
> I proposed 2).
> StringVersion-Patch-M6691.1.cs
> http://bugs.squeak.org/view.php?id=6691
>
> ----------------
>
> If you choose 2), then some cosmetic changes might be good to do:
> The #stringVersion: accessor should be rename to setStringVersion: and
> classified in protocol 'setting', this would be more homogeneous with
> the rest of this protocol and enforce that the ivar is kind of private.
>
> For these reasons I would push
> StringVersion-Patch-M6691.2.cs
> http://bugs.squeak.org/view.php?id=6691
>
> ------------------
>
> RecentMessageSet-updateListsAndCodeIn.st
> http://bugs.squeak.org/view.php?id=5641
>
> is a reversion to use #stringVersioninstead instead of #asStringOrText
> It will not work if ivar is lazy initialized.
> So it must go with 1)
>
> ------------------
>
> RecentChanges.2.cs
> http://bugs.squeak.org/view.php?id=5641
>
> seems a duplication of
>
> RecentChanges.2.cs
> http://bugs.squeak.org/view.php?id=6402
>
> What a mess!
> Jerome said at http://bugs.squeak.org/view.php?id=6402 that this change
> is not viable as refering to classes not in base image
>
> ------------------
>
> RecentChanges.3.cs
> http://bugs.squeak.org/view.php?id=6402
>
> does use #asStringOrtext but does not rename #stringVersion: to
> #setStringVersion:. It seems a good candidate too.
> But it does some more work that i did not analyze.
> Up to Keith to document his work.
> Generally, most changes come from him, so you should ask to him.
>
> Nicolas

Well, I don't wish scare all with inside release affairs :=)
Thanks to all.

Keith ?

Edgar