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

[Tyler C. <tyl...@gm...>]

On 2/12/06, Sandro Magi <naa...@gm...> wrote:
> On 2/10/06, Tyler Close <ty...@wa...> wrote:
> > I've just uploaded a new release of the Waterken Server to SourceForge.
> > Once again, this release contains some major changes that break
> > backwards compatibility. I figured since I'd already done it in the
> > previous release, there was not much cost to doing it again. Needless
> > to say, I hope to stop doing this; however, I think it was definitely
> > worth it this time.
> >
> > The main change is to the persistence interface. Prompted by Sandro's
> > last email, and the freedom that comes with being willing to break
> > backwards compatibility, I tried to design an interface that would make
> > it less strange to code a mutable object.
>
>
> Would it be possible to get a heads up on something that might change soo=
n,
> so I can avoid working on the C# version?

Modifying these base APIs is a pretty severe thing to do, so I hope I
won't need to give you a heads up because it just won't happen again.
But yes, I'll speak up as early as possible.

I spent some time this weekend working on a Hello World tutorial. I
think the new API makes the tutorial a lot easier. I've shown the new
API around a little and gotten very positive feedback, so despite the
pain, I still think making the change was the right thing to do.

For your code, hopefully applying the change will be a simple matter
of renaming some classes and functions. The underlying functionality
of the persistence engine in unchanged.

>  Indeed. The less burden to coding smaller objects, the better IMO. :-)

I think it is crucial to maximizing uptake.

> So would you recommend using Var for all a class's variables, or just for
> small objects? What are the downsides?

Any mutable state needs to be in a Var, but other than that, I don't
think there are any definitive arguments for using multiple Vars per
class, or a single Var containing a struct-style class of many mutable
properties. I think I will primarily use the latter technique, since
it will minimize casting, cause all state to be loaded from disk in a
single bundle, and perhaps clarify state transitions, as it makes it
clear that a pair of changes must be applied as a unit. For example,
see the org.waterken.heap.queue.FIFO implementation at:

http://waterken.sourceforge.net/javadoc/src-html/org/waterken/heap/queue/FI=
FO.html#line.17

Tyler

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

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/extensions/moreinfo.php?id=3D957