[squeak-dev] Can't browse Traits [was Ancient Mantis Report 1554, compiler and global vs class variables]

Frank Shearar frank.shearar at gmail.com
Tue Jul 23 09:24:53 UTC 2013


On 23 July 2013 09:38, Casey Ransberger <casey.obrien.r at gmail.com> wrote:
> Andreas said his implementation actually could support stateful traits
> trivially, though it wasn't exposed anywhere, and remarked that this would
> basically amount to mixin inheritance.

"Yes" in the short answer form, but "no" in the longer form. Stateful
traits are a lot like mixins except you still have the
user-resolves-conflict thing, where mixin inheritance has the order
problem ( (A mixin: B) mixin: C is not (A mixin: C) mixin: B ).

> IIRC the limitation around traits being stateless was borne of somewhat
> academic motivation and a self-imposed constraint on the part of the people
> who did the original implementation at SCG. The version in Squeak currently
> doesn't have this limitation (it doesn't try to prevent you from putting
> state on a trait, but it doesn't give you a way to do it either.)
>
> If you want stateful traits / mixins in Squeak, a good, long look at the
> traits implementation in Squeak may reveal how to do it.

Or be lazy and ask folk like Stephane Ducasse, Camillo Bruni and some
other folks whose names have, regretfully, slipped my mind. See the
Pharo-dev mailing list over the past few months, including pointers to
the literature.

frank

> On Mon, Jul 22, 2013 at 1:13 PM, Chris Cunningham <cunningham.cb at gmail.com>
> wrote:
>>
>> You can browse the traits - just not by "traitName" browse.
>>
>> The other thing not nicely supported by the tools is to remove a trait
>> from a class (or better yet, all traits from a class).  This is supported,
>> but oddly - pass in an empty array into the uses: clause of the class
>> creation method.  Which this re-formats the class creation method in the
>> browser to not include the class creation method that uses #uses: as part of
>> it.  Not pretty, but works.
>>
>> And, yes, I've used Traits happily in building AST models from parsers -
>> where I don't have the full parser or model yet, and want to keep state
>> around for the unfinished parts.  It's worked nicely, but Stateful Traits
>> would have been nicer for my purpose (which is NOT included in the
>> simplified traits in Squeak).
>>
>> -Chris
>>
>>
>> On Mon, Jul 22, 2013 at 12:31 PM, Casey Ransberger
>> <casey.obrien.r at gmail.com> wrote:
>>>
>>> I just had a thought: maybe you need OmniBrowser to view them? I think
>>> the Traits people at SCG were probably using it. I could swear I've browsed
>>> traits before, but I may have had OmniBrowser or maybe I'm remember an early
>>> Pharo experience.
>>>
>>>
>>> On Jul 21, 2013, at 3:12 PM, Nicolas Cellier
>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>
>>> So, it appears that all these are Traits, and that we currently can't
>>> browse Traits.
>>> See Trait someInstance browse...
>>> (In my image I have a few obsolete Traits by the way)
>>>
>>> 2013/7/21 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
>>>>
>>>> Note that bindingOf: contents moved to bindingOf:environment: since
>>>> Environment, so the fix might have to be updated.
>>>> BTW when I browse implementors of bindingOf: I see many
>>>> Trait>>bindingOf: Is it just me?
>>>>
>>>>
>>>> 2013/7/21 Frank Shearar <frank.shearar at gmail.com>
>>>>>
>>>>> On 21 July 2013 00:41, tim Rowledge <tim at rowledge.org> wrote:
>>>>> > Whilst trawling through ancient dusty mantis reports I found this
>>>>> > little fella' - http://bugs.squeak.org/view.php?id=1554 and thought to
>>>>> > myself, "well now, this one will be closable because someone will surely
>>>>> > have modified the compiler a fair bit by now and solved this". Wrong.
>>>>> > Despite the fairly amazing amount of heat that the discussion released back
>>>>> > in 2003 (ten years ago! eeek!) it appears nothing was done at the time
>>>>> > beyond a proposed fix that only got into Mantis-land two years late through
>>>>> > Ken Causey's good offices.
>>>>> >
>>>>> > I tried out the suggested test code in a very recent (#12641) image
>>>>> > and 8 out of 10 test passed. Now I'm no compiler guru and don't claim to
>>>>> > have any special opinion on this except that it looked pretty serious back
>>>>> > then and probably ought to be fixed if at all possible. Unless someone has
>>>>> > good reasons for those two 'failing' tests to be considered unimportant, of
>>>>> > course.
>>>>>
>>>>> Those two tests - are they the tests that Ken says failed before
>>>>> loading the changeset, and work afterwards?
>>>>>
>>>>> frank
>>>>>
>>>>> > tim
>>>>> > --
>>>>> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>>> > There are two ways to write error-free programs; only the third one
>>>>> > works.
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
> --
> Casey Ransberger
>
>
>


More information about the Squeak-dev mailing list