Traits with pool vars?
trygver at ifi.uio.no
Thu Apr 7 12:35:26 UTC 2005
The usage I have in mind is to use a pool var to define the context for a
set of traits, so it should be safe. A BabyUML component is an encapsulated
set of objects known by its provided and required interfaces (UML). I have
a need for component members to share named objects so that a trait can say
'foo something' and hit the right object. Pools will do as long as I stick
to sequential programming, otherwise I might need two-lever indirection.
Pool vars are tricky beasts at the best of times... I'll probably do the
experiment to see how it works out.
At 13:59 07.04.2005, you wrote:
>>I love the way traits separate method from class.
>:) me too
>>Traits do not know the ultimate class, so they cannot reference instvars.
>>Traits do know Smalltalk, so they can reference global variables and are
>>not quite stateless.
>>I have occasion to experiment with "regional variables" and want to use
>>pool vars for this.
>>Ar a first glance, it seems simple to let traits access pool vars.
>>Does this violently violate the ideas behind traits?
>I will have to digest it.
>But without too much thinking I would say that as soon as you only have
>global space this should not be a problem. However now this could mean that
>you would need a kind of requirement for dependency with the pool.
>Because you could load a PoolReferingTrait into a system not having this pool
>and then yoru code would not be working.
>So my solution would be to:
> do not access pool in traits
> use a required methods instead
> and in the class provide a method to access to the pool
>this way the class has the responsibility to access/provide state and
>traits just use
>or express requirement and are not polluted with state.
Trygve Reenskaug mailto: trygver at ifi.uio.no
Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver
N-0378 Oslo Tel: (+47) 22 49 57 27
More information about the Squeak-dev