#propertyAt: to the rescue?

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

#propertyAt: to the rescue?

Schwab,Wilhelm K
Hello all,

I have a design that is oscillating a little, and #propertyAt: might put
an end to it.

Consider a large network of objects that read from streams.  Actually,
there are many such networks, one of which needs access to a map that
can either be global, held in some kind of context, attached to a shared
object higher up on the food chain, or attached to the source stream as
a property.

Having gotten tired of #readFrom:for: when #readFrom: makes a lot more
sense, I am leaning toward the propery idea.  I don't like a global
because I might need to run a couple of the networks in parallel.

There could be problems with streams "producing" other streams on the
way to the consumers, but it would be fairly straigtforward to learn
(the hard way of course<g>) when to transfer a property from one stream
to another.

Comments?

Blair, given that packages use properties, would it make sense to give
the package system its own property manager?  That might speed up
properties for the more casual user.  I could provide my own manager,
but in this case, I would have to do it for base system classes (e.g.
streams), which seems inappropriate.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]