release 3.4 (Was: [Waterken-server] org.yurl.Author schema)

[Tyler C. <ty...@wa...>]

I've just uploaded a new release of the Waterken Server to SourceForge.=20=

Once again, this release contains some major changes that break=20
backwards compatibility. I figured since I'd already done it in the=20
previous release, there was not much cost to doing it again. Needless=20
to say, I hope to stop doing this; however, I think it was definitely=20
worth it this time.

The main change is to the persistence interface. Prompted by Sandro's=20
last email, and the freedom that comes with being willing to break=20
backwards compatibility, I tried to design an interface that would make=20=

it less strange to code a mutable object.

On Feb 4, 2006, at 8:06 AM, Sandro Magi wrote:
> On 2/4/06, Tyler Close <ty...@wa...> wrote:
>> And finally, to show mutable state:
>>
>> public final class
>> Maker implements java.io.Serializable {
>>
>> =A0=A0=A0=A0 private String greeting;
>>
>> =A0=A0=A0=A0 public static Hello
>> =A0=A0=A0=A0 make() { return new Hello( Global.create(new Maker())); =
}
>>
>> =A0=A0=A0=A0 public static final class
>> =A0=A0=A0=A0 Hello implements java.io.Serializable {
>>
>> =A0=A0=A0=A0=A0=A0=A0=A0 private Key scope;
>>
>> =A0=A0=A0=A0=A0=A0=A0=A0 Hello(final Key scope) {
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 this.scope =3D scope;
>> =A0=A0=A0=A0=A0=A0=A0=A0 }
>>
>> =A0=A0=A0=A0=A0=A0=A0=A0 public String
>> =A0=A0=A0=A0=A0=A0=A0=A0 getGreeting() { return =
((Maker)scope.query()).greeting; }
>>
>> =A0=A0=A0=A0=A0=A0=A0=A0 public void
>> =A0=A0=A0=A0=A0=A0=A0=A0 setGreeting(final String greeting) {
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ((Maker)scope.update()).greeting =
=3D greeting;
>> =A0=A0=A0=A0=A0=A0=A0=A0 }
>> =A0=A0=A0=A0 }
>> }
>>
>> Thoughts?
>
> I think that's very good. I've seen the above pattern quite a bit, but=20=

> it looks a tad strange; some elaboration might help me understand why=20=

> this approach is taken. I'm specifically referring to the Maker=20
> pattern, the data used in the nested class being stored in the parent=20=

> class rather than as a private variable, etc. For instance, is there a=20=

> design that makes use of a single class instead?

When I first built the persistence interface, I was expecting that the=20=

common case would be an object containing many mutable variables. In=20
this case, a persistent data class containing these variables would=20
need to be defined, and a second class creating the public interface to=20=

that data class would also need to be defined. By making the public=20
interface class an inner class, the mutable variables in the persistent=20=

data class could be freely read and assigned, without the need to=20
create getter and setter methods. Since the public interface class is=20
an inner class, it has access to the private state of the persistent=20
data class. For the expected common case, this coding style seemed to=20
impose the least burden on the programmer.

However, looking at our Hello World example and also the other examples=20=

in the Waterken Server release, it appears that having a single mutable=20=

variable of a predefined type is a very common case. For example, the=20
Hello World code needs a single mutable string. The IOU code needs a=20
single mutable integer. The yurl.org wiki code needs a single mutable=20
object. For all these cases, the minimal implementation requires only=20
definition of a public interface class, since the persistent data is of=20=

a predefined type. In these cases, the Maker coding style is imposing=20
an unnecessary burden by requiring the coding of a persistent data=20
class that has only one variable. So to avoid wear and tear on the=20
programmer, I've created a new persistence interface.

The Hello World example with mutable state now looks like:

public final class
Hello implements java.io.Serializable {
     private Var greeting;

     public
     Hello(final String initial) {
         greeting =3D Persistent.var(initial);
     }

     public String
     getGreeting() { return (String)greeting.getValue(); }

     public void
     setGreeting(final String greeting) {
         this.greeting.assign(greeting);
     }
}

This code is now really close to what the programmer would naturally=20
write if they weren't dealing with a persistent object interface. I am=20=

hoping it will also seem less "strange", and be easier to learn. I look=20=

forward to your thoughts on this new interface.

I'll be at CodeCon this weekend if anyone wants to get together. Hope=20
to see you there.

Tyler

---
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/