ClojureScript

.-default property access returns nil

Details

  • Type: Defect Defect
  • Status: Reopened Reopened
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.7.145
  • Fix Version/s: 1.9.671
  • Component/s: None
  • Labels:
    None
  • Patch:
    Code and Test

Description

Types defined with deftype/defrecord which have a default field will incorrectly return nil with property access. The following example will return nil.

(deftype Foo [default])

(let [foo (Foo. "bar")]
  (.-default foo))
  1. 871.patch
    18/Mar/15 11:43 AM
    3 kB
    Joel Holdbrooks
  2. 871.patch
    13/Oct/14 4:16 PM
    5 kB
    Joel Holdbrooks

Activity

Hide
Joel Holdbrooks added a comment -

Patch attached. I should point out that I had to borrow js-reserved from the compiler namespace and the warning message provided hard codes the munged symbol information instead of reusing the compiler's munge fn.

Show
Joel Holdbrooks added a comment - Patch attached. I should point out that I had to borrow js-reserved from the compiler namespace and the warning message provided hard codes the munged symbol information instead of reusing the compiler's munge fn.
Hide
Joel Holdbrooks added a comment -

For the sake of history, I should provide more context to this patch (I'm unable to edit the issue title for some reason). It isn't just .-default it is any field name that is also a JavaScript identifier (eg. public, private, if).

Show
Joel Holdbrooks added a comment - For the sake of history, I should provide more context to this patch (I'm unable to edit the issue title for some reason). It isn't just .-default it is any field name that is also a JavaScript identifier (eg. public, private, if).
Hide
David Nolen added a comment -

Please lift js-reserved and any helpers like munge into the shared namespace cljs.util so that logic an be shared and hard coding avoided. Thanks.

Show
David Nolen added a comment - Please lift js-reserved and any helpers like munge into the shared namespace cljs.util so that logic an be shared and hard coding avoided. Thanks.
Hide
Joel Holdbrooks added a comment -

Are you sure, David? That might make this patch a bit more noisy. If it's not a problem I'm happy to do it.

Show
Joel Holdbrooks added a comment - Are you sure, David? That might make this patch a bit more noisy. If it's not a problem I'm happy to do it.
Hide
David Nolen added a comment -

I'm sure, I'd like to avoid this kind of code duping. Cleaner in the end and better moving forward.

Show
David Nolen added a comment - I'm sure, I'd like to avoid this kind of code duping. Cleaner in the end and better moving forward.
Hide
Joel Holdbrooks added a comment -

Updated to use new refactorings

Show
Joel Holdbrooks added a comment - Updated to use new refactorings
Hide
David Nolen added a comment -

The warning is not desirable. Instead we should just munge and ensure property access always works.

Show
David Nolen added a comment - The warning is not desirable. Instead we should just munge and ensure property access always works.
Hide
David Nolen added a comment -

Now that we have CLJS-1620, a warning seems like a good answer.

Show
David Nolen added a comment - Now that we have CLJS-1620, a warning seems like a good answer.

People

Vote (3)
Watch (1)

Dates

  • Created:
    Updated: