Hello,

You might like to take a look at David Simmons' declarative approach to
state. I see there some interesting things.

I copy here below a part one of his emails describing it:

----------------------------------------

OTOH: In SmallScript I'm interested in a declarative initialization
declaration in the class that will handle the other related initialize
issues a bit more transparently. I.e., field initializers are gathered
and
the class can automatically generate a default #initialize unless it is
explicitly provided. This aids with inheritance and re-factoring.

I.e.,

Class name: Foo
    fields: varA := 0; varB := (Time.now); varC := 'Foobar'; varD;
    class-fields: classVarA;
    shared-fields: pool_global_var := anInitializerExpr; "etc"
{
    Function ["same as Class-method"
    new: anObject
        ^self new
            ...
    ]

    Method [
    blah
    ]
}

The field declaration forms provide other extensions such as:

    thread (thread-local-storage)
    readonly
    auto - generates getter/setter
    property - causes all variable references to route to getter/setter
    virtual - declares a variable which is lazily added via properties
              and is most typically used with "property" and/or "auto"
              in interfaces or base classes.
    struct - declares value-type fields (stored in the byte-storage
portion
             of an object.
    [...] - array declarations.
    <type> - types a variable (noting that types are classes so the type
             system is fully user/developer extensible).
    bool[...] - declares a boolean field that is maintained as a bit in
some
                other field. The compiler/metadata manages the bit
allocation.
    alias[...] - used for shared-fields to declare
imports/renames/aliases
to
                 other shared-variables.
    bitfield[...] - same as boolean but its type is unsigned integer and
you
                can specify the bit-width.

Examples:

 Class name: DOSTime extends: DecodedTimeValue
     fields: auto struct uint16           wFatDate,
                                          wFatTime,
                         uint32           wFatDateTime[@0];
      auto property bitfield[wFatDate:5]  wDay,
                    bitfield[wFatDate:4]  wMonth,
                    bitfield[wFatDate:7]  wYear,
                    bitfield[wFatTime:5]  wSecond,
                    bitfield[wFatTime:6]  wMinute,
                    bitfield[wFatTime:5]  wHour;
 {
 }

 Class name: ImageBase extends: COFFToolsStruct
     fields: auto                         flags, entryPointChunk,
sectionsByName,
                                          collatedSections,
currentImageSize,
                                          currentFileSize,
sectionHeadersRVA;
             auto property bool[flags]    isConsoleModule;
             auto property bool[flags]    isDebugBuild;
             auto property                out;
 {
     enum {
         /* Machine Types */
         IMAGE_FILE_MACHINE_UNKNOWN      := 0,
         ... more here, etc ...
     }
 }

 Class name: WIN32_FIND_DATA
     fields: auto struct uint32           dwFileAttributes,
                         FileTime         ftCreationTime,
                                          ftLastAccessTime,
                                          ftLastWriteTime,
                         uint32           nFileSizeHigh,
                                          nFileSizeLow,
                                          dwReserved[2],
                         char             cFilename[260 "MAX_PATH"],
                                          cAlternateFileName[14];
             auto virtual property        fileSize;
     imports: FDSpecifier
 {
 }
-------------------- End of paste --------------------------

Notice that when using "auto" the accessors will be generated if there
are none defined yet. Otherwise, the one written will be respected (not
the ones inherited though). When using "property" all accesses made to
the instance variables will be routed through accessor methods. But
notice that it will not generate them, either use it with "auto" or make
sure you have the needed accessors. Also notice that the property
semantics applies everywhere except_ in the accessors, in these methods
iv accesses are just plain iv reads/writes.
"virtual" has semantics in essence much like those of the extended
properties in Morph, but at Object level and much better integration
(only this kind of state can be declared in mixins).
As one of the goals in Smallscript is to close as much as possible the
traditionally wide gap between smalltalk and the OS, without sacrificing
its flexibility, part of the state declaration modifiers have to do with
declaring fields in a more OS-friendly manner to describe, access and
manipulate OS memory directly in smallscript. But they can be ignored
otherwise.
Finally, when using no modifiers, field declarations behave like plain
old smalltalk.

As with almost every part of Smallscript, there seems to be a lot of
flexibility, expressiveness and homogeneity in its features, but they
seem to come at a somewhat high price in terms of added complexity. I
think it is impossible to decide just yet whether this complexity is
part of the solution or it is essential and implicit in smalltalk, and
David is trying to make it more explicitly managed.

Juan

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of
Stephane Ducasse
Sent: Thursday, April 10, 2003 17:37
To: squeak dev
Subject: Need feedback on simple idea

Hi

I would like to know what you would think of the following change in 
Smalltalk.
We are really in the mood to make some change in the compiler to play 
with the idea
for our research.

remove direct access to instance variables a la self

a class still defines instance variable but we cannot access directly 
instance variables accessors are automatically optimized to use direct 
access by the compiler.

Pros:
	simplicity/uniformity no distinction between state and methods.

Cons:
	no private iv anymore anymore (except if we try to have a clever
schema
	that lets the programmer writing self x while the byte code
remove the 
send)
	with this schema we could have private instance variables but be

forced to used a 	normal method to make public an accessor.
	
	m
		self x
	<=>
	m
		x

	public accessor could be then

	getX
		self x

Applicability to Squeak:
	- would break all the accessors that do something more that
accessing
	(self changed) but we could use a dedicated parser/compiler so
that the
	changes only impact a subset.






Prof. Dr. Stéphane DUCASSE
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do 
different? ...  especially if,
  by doing something different, today might not be your last day on 
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html