[Seaside] 2.1 preview

Avi Bryant seaside@lists.squeakfoundation.org
Tue, 17 Dec 2002 00:40:59 -0800 (PST)


Hi all,

I've put an early release of Seaside 2.1 up at
http://beta4.com/seaside2/Seaside2.10.st.gz .

The main change in this release is that the old ManagedObject/IVAP method
of instrumenting instance variable reads and writes is no longer used.
Instead, it introduces an explicit stateTree instance variable which is
used by components to read and write state that needs to rewind and
fork for the back button.

Although you could directly use stateTree #at: and #at:put:, subclasses of
WAComponent now also have an extra line in their class definition which
allows you to declare stateVariableNames.  Accessors which go through the
stateTree will be generated for each of these names.  For example,

  WAComponent subclass: #WACounter
	instanceVariableNames: ''
	stateVariableNames: 'count '
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Seaside/Examples-Basic'

generates

  count
	^stateTree at: #count

  count: anObject
	stateTree at: #count put: anObject


This change does raise the question of when it's appropiate to use
stateVars instead of instVars.  When in doubt, it never hurts to make
something a state variable (except for increased memory usage...).  As a
rule of thumb, however, if you ever change the value of an instance
variable *after* the component is first created and initialized, then it
should probably be a stateVar.  Going through my own code, I found it
interesting how few instance variables this applied to... I'm hopeful that
making this distinction more explicit will lead to a better understanding
of mutation patterns in general.

I'd appreciate it if people tried this out and let me know how they found
the new approach.

Cheers,
Avi