issue-29e9f422f5e734acc86af4fe80dfd96bee007ac0.yaml

--- !ditz.rubyforge.org,2008-03-06/issue 
title: reverse \xFF and \xFF\xFF convention for user vs. duktape internal properties
desc: |-
  Duktape uses around 20 internal properties which are prefixed with a single
  \xFF.  User internal properties are now allowed, and the current suggestion
  is to use \xFF\xFF prefix for them.
  
  Should this policy be reversed?  A reverse policy might make more sense, as
  it would be more user friendly.  Memory usage differences are tiny (unless
  user code has thousands of internal properties) so convenience matters most
  in this decision.
type: :task
component: duk
release: v1.0
reporter: Sami Vaarala <sami.vaarala@iki.fi>
status: :closed
disposition: :fixed
creation_time: 2014-09-12 08:52:30.030886 Z
references: []

id: 29e9f422f5e734acc86af4fe80dfd96bee007ac0
log_events: 
- - 2014-09-12 08:52:30.254793 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - created
  - ""
- - 2014-10-10 09:43:56.521348 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - commented
  - |-
    Perhaps just require user internal strings to begin with a capital letter, e.g.
    \xffPtr?  Or change Duktape to use capital letters.
    
    Another approach is to use a non-alphanum initial character, e.g. \xFF!value for
    Duktape internal keys.
- - 2014-10-10 11:59:24.012107 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - closed with disposition fixed
  - |-
    Final solution was to use uppercase initial character for Duktape keys, so
    that user keys can be more natural:
    
    - \xFFValue for a Duktape key
    - \xFFvalue for a user key
    
    For unknown keys, user code can use double \xFF prefix.