Hi Dave,
in your eaxmple "foo" is a class variable. Technically everything you
add to the members section will be in the prototype of the class. That's
why obj.hasOwnProperty('foo') returns false whereas it returns true if
you set this in the constructor directly on "this".
As you have noted i
There are sometimes thought that this could be an advatange. The proper
way to address to statics is via the full namespace (I think you can do
something thike this.self(arguments) for short), while "member
instances" are access via this.
I agree though that this is a real bad practice but I do
Hi.
I had the same issue about a week ago, and I this is documented here on
the wiki: http://qooxdoo.org/documentation/0.8/classes#instance_members
Cheers.
dmbaggett wrote:
> What exactly does code like this mean:
>
> qx.Class.define("my.class", {
> ...
> members: {
> foo: 1
> }
> ...
On Tue, Oct 6, 2009 at 17:40, dmbaggett wrote:
> While this is working as advertised, it seems very counter-intuitive. It
> seems
> to me that the "features for object orientation" doc ought to include a
> warning
> about this. (Even better would be to have QooxDoo recognize this situation
> and
Thanks, Derrell,
What you describe below perfectly explains my problem. In my real code,
I have something like
foo: { bar: 1 }
and this is causing all copies of foo to get initialized to the same
reference;
hence the object is shared across all instances.
While this is working as advertised,
On Tue, Oct 6, 2009 at 16:55, dmbaggett wrote:
>
> What exactly does code like this mean:
>
> qx.Class.define("my.class", {
> ...
> members: {
>foo: 1
> }
> ...
> });
>
> In particular, when will foo be initialized? Is foo now an instance
> variable
> or a class variable?
>
> foo is an inst
What exactly does code like this mean:
qx.Class.define("my.class", {
...
members: {
foo: 1
}
...
});
In particular, when will foo be initialized? Is foo now an instance variable
or a class variable?
The reason I ask is that in some very complicated code I am seeing behavior
that suggest
