Re: [closure-compiler-discuss] JSC_INEXISTENT_PROPERTY error using this.property?

514 views
Skip to first unread message

Ilia Mirkin

unread,
Jul 8, 2012, 6:07:08 PM7/8/12
to closure-comp...@googlegroups.com
I think you want

otosug.Suggestion.prototype.html

Also, no need to use things like @this on .prototype functions. That's
more for when you're declaring an anonymous function that references a
non-obvious "this".

Lastly, you shouldn't return stuff from constructors... they should be
invoked via "new" (and thus not have a @return). Take a look at some
files in closure library for more examples of how to declare
classes/etc... e.g. goog.date.Date in
http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/date/date.js
(and lots and lots of other examples throughout).

On Sun, Jul 8, 2012 at 5:54 PM, <fja...@gmail.com> wrote:
> How can I get the properties recognized to use them with "this"?
>
> Here is my code and I get the error: when I compile it with advanced
> optimizations
>
> JSC_INEXISTENT_PROPERTY: Property html never defined on otosug.Suggestion at
> line 60 character 7
> return this.html || this.text;
> ^
> JSC_INEXISTENT_PROPERTY: Property text never defined on otosug.Suggestion at
> line 60 character 20
> return this.html || this.text;
>
> // Suggestion structure
> /**
> * @constructor
> * @return {otosug.Suggestion}
> */
> otosug.Suggestion = function () {}
>
> // Properties.
> /**
> * @type {string|null}
> * @expose
> */
> otosug.Suggestion.id = null;
>
> /**
> * @type {string|null}
> * @expose
> */
> otosug.Suggestion.text = null;
>
> /**
> * @type {string|null}
> * @expose
> */
> otosug.Suggestion.html = null;
>
> /**
> * Returns a string representing the Suggestion.
> * @this {otosug.Suggestion}
> * @return {string}
> * @override
> */
> otosug.Suggestion.prototype.toString = function() {
> return this.html || this.text; // <<<<<<<<<<<<<<< ERROR:
> JSC_INEXISTENT_PROPERTY
> };
>
> Thanks
>
> Fred
>

Ross Dakin

unread,
Jul 9, 2012, 2:23:08 AM7/9/12
to closure-comp...@googlegroups.com
As Ilia points out, this is a JavaScript problem, not a compiler problem.


Ross

Chad Killingsworth

unread,
Jul 10, 2012, 1:18:37 PM7/10/12
to closure-comp...@googlegroups.com
Please be careful with @expose. It invalidates almost all optimizations on that property. It's really only designed when you need to preserve a reference (not a copy) to a static property on a constructor.

Chad Killingsworth

Ilia Mirkin

unread,
Jan 18, 2013, 2:36:01 PM1/18/13
to closure-comp...@googlegroups.com
Could you just unconditionally add

/** @type {number} */
MyType.prototype.thing;

below your conditional constructor definition?

On Fri, Jan 18, 2013 at 2:15 PM, <brook....@gmail.com> wrote:
> I'm not convinced this question was answered. The question is how to get
> the Closure compiler to stop flagging properties as not existing, when they
> do, in fact, exist.
>
> Here's a situation:
>
> var MyType;
>
> if(definePropertyWorksRight()) {
> /**
> * @constructor
> */
> MyType = function () {
> this.init();
> Object.defineProperty(this,"thing",...);
> return this;
> };
> } else {
> /**
> * @constructor
> */
> MyType = function () {
> this.init();
> this.thing = 42;
> // setThing() and getThing() written later in the file.
> return this;
> };
> }
>
> I might choose to do this if I'd like to define object properties in IE9+,
> Chrome, etc., but I can't use them in IE8 and FF3.5 because
> Object.defineProperty isn't implemented correctly. Since I'm going to make
> many of the MyType objects, I don't want to do the feature test repeatedly
> during construction for performance reasons. Variant function definition is
> the way to go with this, but the Closure compiler gets fussy. It seems like
> I ought to be able to annotate my way around this situation.
>
> MyType.prototype.init is defined later in the file (and if you try to do it
> before defining the constructor, the Closure compiler complains). I still
> see JSC_INEXISTENT_PROPERTY showing up. That means there should be an @
> syntax for indicating that this.init() is legitimate--but what is that
> syntax? (I infer this is a single-pass compiler because a double-pass
> compiler wouldn't have this issue--it would see init declared later on.)
> There's no Javascript issue here--it's purely an annotation issue with the
> Closure compiler.
Reply all
Reply to author
Forward
0 new messages