[Seaside-dev] Two minor implementation questions

Lukas Renggli renggli at gmail.com
Tue Oct 16 09:13:09 UTC 2007


> WADispatcher>>beAwareOfChangeOf: anAspectSymbol with: aParameter
> from: anEntryPoint
>         (anEntryPoint == self
>                 and: [anAspectSymbol == #name]) ifTrue: [^ self].
>         "Here when anything has changed but the name in the
>         receiver"
>         version := self version + 1.
>         lastUpdate := TimeStamp now.
>         self changed
>
> At issue is the last line of code "self changed". The "changed"
> method appears to call Object>>changed, which eventually calls:
>
> Object>>changed: anAspectSymbol with: aParameter
>
>         self myDependents update: anAspectSymbol with: aParameter from: self
>
> However as far as I can see WADispacher objects return nil on "self
> myDependents". (I think it is a good idea to avoid using dependents
> on Object.) So the "self changed" appears to unneeded.

This was added because VisualWorks needed it. I don't remember exactly
why and if it is still the case? It potentially introduces portability
problems, as the change-notifications are implemented slightly
different in all Smalltalk dialects. Moreover passing symbols around
is not really the thing I enjoy ;-)

> The second place is in WASystemConfiguration. This class is a
> singleton. There is a single instance of the class stored in a class
> instance variable. This does not seem to make sense. First of all
> WASystemConfiguration and its parent class WAConfiguration have no
> state. Secondly WASystemConfiguration is an abstract class. So there
> does not seem any need for the singleton.

There are a couple of subclasses. Every subclass has its own variable
#instance to store its specific singleton instance. It is important to
always have the same instance, because #= is not overridden. We could
probably get rid of this singleton behavior by overriding #= and
checking for the same class, but I don't know if this is worth the
change?

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch


More information about the seaside-dev mailing list