Exact meaning of member attributes

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Exact meaning of member attributes

dmbaggett-2

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 suggests foo is a class variable, not an instance variable. In other
words, when I call obj.hasOwnProperty('foo'), where obj is an instance of
class my.class, I get "false".

In contrast, when I put this code in the constructor:

  this.foo = 1

then each instance of my.class appears to get its own independent copy of
foo.

I'm wondering whether this is the advertised behavior, or whether something
in my complicated code is causing QooxDoo to behave this way.

Dave

--
View this message in context: http://www.nabble.com/Exact-meaning-of-member-attributes-tp25776434p25776434.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Exact meaning of member attributes

Derrell Lipman
On Tue, Oct 6, 2009 at 16:55, dmbaggett <[hidden email]> 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 instance variable. It is initialized upon instantiation of an object of the class. However you need to be a little bit careful. In your example, you gave foo a scaler value. If, OTOH, you had said
  foo: { bar : 1 }
then the object is created only once and you get a reference to it in each instance. If one instance does this.getFoo().bar = 23; then it will be 23 in all instances, because they are referencing the same object. If you need objects as member variables, the proper way to do it is to set
  foo: null
in the member section, and then initialize it to a new object in the constructor.
 
The reason I ask is that in some very complicated code I am seeing behavior
that suggests foo is a class variable, not an instance variable. In other
words, when I call obj.hasOwnProperty('foo'), where obj is an instance of
class my.class, I get "false".

That sounds like a bug, but I'm not thoroughly familiar with hasOwnProperty().

Derrell


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Exact meaning of member attributes

dmbaggett-2

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, 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 prohibit it: the proper way to share data across instances is to use
statics, no?)

Dave
--------------------------------------

On Tue, Oct 6, 2009 at 16:55, dmbaggett <[hidden email]> wrote:

However you need to be a little bit careful. In your
example, you gave foo a scaler value. If, OTOH, you had said
  foo: { bar : 1 }
then the object is created only once and you get a reference to it in each
instance. If one instance does this.getFoo().bar = 23; then it will be 23 in
all instances, because they are referencing the same object. If you need
objects as member variables, the proper way to do it is to set
  foo: null
in the member section, and then initialize it to a new object in the
constructor.

--
View this message in context: http://www.nabble.com/Exact-meaning-of-member-attributes-tp25776434p25777023.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Exact meaning of member attributes

Derrell Lipman
On Tue, Oct 6, 2009 at 17:40, dmbaggett <[hidden email]> 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 prohibit it: the proper way to share data across instances is to use
statics, no?)

Yes, that's what statics are for. This "mis-feature" is documented someplace in the wiki. I think, too, that a "generate.py lint" will tell you about it. I agree, though, that a normal run of generate.py should warn you about it.

There are technical reasons that make doing it the "intuitive" way difficult.

Derrell


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Exact meaning of member attributes

Loïc Bresson -- Novlog
In reply to this post by dmbaggett-2
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
>   }
> ...
> });
>
> 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 suggests foo is a class variable, not an instance variable. In other
> words, when I call obj.hasOwnProperty('foo'), where obj is an instance of
> class my.class, I get "false".
>
> In contrast, when I put this code in the constructor:
>
>   this.foo = 1
>
> then each instance of my.class appears to get its own independent copy of
> foo.
>
> I'm wondering whether this is the advertised behavior, or whether something
> in my complicated code is causing QooxDoo to behave this way.
>
> Dave
>


--
Loïc Bresson


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Exact meaning of member attributes

Noggin182
In reply to this post by Derrell Lipman
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 don't think we
should prevent it, I can easily imagine some people using this approach.
I would favour a warning over an error. It would be easy to produce a
warning at runtime via qx.Class.define we just need to look for members
that are either objects (not functions or null) or arrays.

Derrell Lipman wrote:

> On Tue, Oct 6, 2009 at 17:40, dmbaggett <[hidden email]
> <mailto:[hidden email]>> 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 prohibit it: the proper way to share data across instances is to use
>     statics, no?)
>
>
> Yes, that's what statics are for. This "mis-feature" is documented
> someplace in the wiki. I think, too, that a "generate.py lint" will tell
> you about it. I agree, though, that a normal run of generate.py should
> warn you about it.
>
> There are technical reasons that make doing it the "intuitive" way
> difficult.
>
> Derrell
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Exact meaning of member attributes

Fabian Jakobs
Administrator
In reply to this post by dmbaggett-2
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 in the other mail you have to take care with maps or
arrays as values in the members section. They have copy by reference
semantics so each instance of the class will have a reference to the
same array/object. This is usually not expected. Primitive data types
like numbers, strings or booleans are no problem.

Best Fabian

> 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 suggests foo is a class variable, not an instance variable. In other
> words, when I call obj.hasOwnProperty('foo'), where obj is an instance of
> class my.class, I get "false".
>
> In contrast, when I put this code in the constructor:
>
>   this.foo = 1
>
> then each instance of my.class appears to get its own independent copy of
> foo.
>
> I'm wondering whether this is the advertised behavior, or whether something
> in my complicated code is causing QooxDoo to behave this way.
>  

--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel