Ian Eslick writes:
> You shouldn't be using any of the controllers in contrib/eslick, those
> are in-progress experiments. Which version of the source tree are you
> using? This code shouldn't be loaded unless you are doing it
> explicitly. You should just be loading elephant.asd.
As a matter
You shouldn't be using any of the controllers in contrib/eslick, those
are in-progress experiments. Which version of the source tree are you
using? This code shouldn't be loaded unless you are doing it
explicitly. You should just be loading elephant.asd.
Ian
On Mar 6, 2008, at 12:12 PM,
Alex Mizrahi writes:
> LPP> I should have added that I'm talking about a schema evolution thing
> LPP> here, i.e. the situation concerns slots *added* to a class.
>
> LPP> The slots of instances of such a class are unbound instead of being
> LPP> assigned their initform, if any.
>
> i agree with y
LPP> The slots of instances of such a class are unbound instead of
being
LPP> assigned their initform, if any.
That was a strange phenomenon that I couldn't reproduce. However,
let's keep an eye on this and revisit it (perhaps a Trac ticket
against 0.9.2). I've messed with object init
LPP> I should have added that I'm talking about a schema evolution thing
LPP> here, i.e. the situation concerns slots *added* to a class.
LPP> The slots of instances of such a class are unbound instead of being
LPP> assigned their initform, if any.
i agree with you -- this unbound thing is totall
