<div dir="ltr"><div><div>+1 for keeping them (let's be a bit conservative).<br><br></div>What I call does not work is:<br></div>- if you have a Trait instance, say MyTrait, then (MyTrait browse) will open on Trait rather than MyTrait<br>
- a side effect, browsing implementors of a method #traitMethod implemented by Trait will answer exactly one Trait>>traitMethod per Trait instance<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/7/22 Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
By "browse" do you mean something other than using Browser? Because I<br>
unaware of any _serious_ Trait issues until now, other than #- not<br>
doing the right thing in complicated compositions.<br>
<br>
frank<br>
<br>
On 21 July 2013 23:12, Nicolas Cellier<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> So, it appears that all these are Traits, and that we currently can't browse<br>
> Traits.<br>
> See Trait someInstance browse...<br>
> (In my image I have a few obsolete Traits by the way)<br>
><br>
> 2013/7/21 Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>><br>
>><br>
>> Note that bindingOf: contents moved to bindingOf:environment: since<br>
>> Environment, so the fix might have to be updated.<br>
>> BTW when I browse implementors of bindingOf: I see many Trait>>bindingOf:<br>
>> Is it just me?<br>
>><br>
>><br>
>> 2013/7/21 Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>><br>
>>><br>
>>> On 21 July 2013 00:41, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
>>> > Whilst trawling through ancient dusty mantis reports I found this<br>
>>> > little fella' - <a href="http://bugs.squeak.org/view.php?id=1554" target="_blank">http://bugs.squeak.org/view.php?id=1554</a> and thought to<br>
>>> > myself, "well now, this one will be closable because someone will surely<br>
>>> > have modified the compiler a fair bit by now and solved this". Wrong.<br>
>>> > Despite the fairly amazing amount of heat that the discussion released back<br>
>>> > in 2003 (ten years ago! eeek!) it appears nothing was done at the time<br>
>>> > beyond a proposed fix that only got into Mantis-land two years late through<br>
>>> > Ken Causey's good offices.<br>
>>> ><br>
>>> > I tried out the suggested test code in a very recent (#12641) image and<br>
>>> > 8 out of 10 test passed. Now I'm no compiler guru and don't claim to have<br>
>>> > any special opinion on this except that it looked pretty serious back then<br>
>>> > and probably ought to be fixed if at all possible. Unless someone has good<br>
>>> > reasons for those two 'failing' tests to be considered unimportant, of<br>
>>> > course.<br>
>>><br>
>>> Those two tests - are they the tests that Ken says failed before<br>
>>> loading the changeset, and work afterwards?<br>
>>><br>
>>> frank<br>
>>><br>
>>> > tim<br>
>>> > --<br>
>>> > tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
>>> > There are two ways to write error-free programs; only the third one<br>
>>> > works.<br>
>>><br>
>><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>