Hi Greg,
also for me your choice #2 seems the best, having simpler code (and
without distinction on trusted and untrusted execution ) is more
useful ...

In my experiments, i tried something with annotations, and in some
cases they are very useful, but instead of implementing them in one of
pivot subprojects, what do you think on moving them (if existing here,
after cleanup) in a dedicated subproject (like the tools subproject),
but only for development environment (for compile-time utilities, from
IDE, or Ant) ?


> Resources resources = new Resources(this);
>
> If your class is named com.foo.MyClass, it will automatically load
> com.foo.MyClass.json.
>
> I also added a readObject() overload to WTKXSerializer that takes an object
> and a resource name. Now, instead of this:
>
> wtkxSerializer.readObject(getClass().getResource("foo.wtkx"));
>
> you can write this:
>
> wtkxSerializer.readObject(this, "foo.wtkx");
>
> Again, minor changes, but they make the code that much more readable.
>

This is great, so a question:
if all these are little modifications to the current (post 1.2 trunk),
what do you think on release these (including others, if needed)
before the 1.3 ?
Could we think on a maintenance 1.2.x in the short term ?
In this way we and our users could try this before the full cleanup
(Bindable, the package refactoring, etc), and see if it's not too much
complex.

In next months I'd like to start new applications, finally based on
Pivot, and starting with a post 1.2 release (or with a 1.3 trunk, but
i don't like too much this idea) would be great.
In any case, I'll tell of news on this ...


Ah, in the Web Site, if we could have also a "Real Use Cases" section,
could be useful ...


Thanks and good work,
Sandro

Reply via email to