On Sun, Apr 10, 2011 at 5:27 PM, Dmitry A. Soshnikov <
dmitry.soshni...@gmail.com> wrote:
>
> As I see it, you address the "issue" of unstratified meta-programming
> (note, I take the "issue" in quotes, since there's no a single meaning
> whether the unstratified meta-level is so bad).
>
> It depends on how to look on the issue. On one hand, why if a user changes
> the behavior of the `hasOwnProperty` of _his_ object in _his_ program, then
> the program should be considered as incorrect? The user knows how to handle
> `hasOwnProperty` for the particular object and the ability to override it is
> the ability to control unstratified meta-level via simple reassigning to
> meta-hooks.
>
Hi Dmitry, your response makes clear two issues I failed to explain well:
By "program", I do not mean a whole program, i.e., the totality of all code
run within a given JS environment. David's original getDefiningObject
function and variations are clearly not whole programs. Rather, they are
reusable program fragments that could be packaged in reusable libraries,
meant to be link into and used from within larger programs that the author
of getDefiningObject should not need to know about.
Since we're not worried here about programming under mutual suspicion, it
could very well be valid for getDefiningObject to assume that various
methods are overridden in a contract preserving manner. For example, a Java
hashtable that calls a key's "hashCode" method could be correct. The key's
hashCode method might be incorrect, in which case the hastable would
function incorrectly, but we'd say that this incorrect behavior is the key's
fault rather than the hashtable's fault.
We would like a notion of correctness that allows us to reason in a modular
manner: A correct composition of individually correct components should
yield a correct composite, where the correctness of the composition depends
only on the contracts of the components to be composed -- not on their
implementation. The Java composite above is incorrect because the key is
incorrect. This does not contradict the notion that the hashtable
abstraction by itself is correct even though in this case it behaves
incorrectly.
The problem here is specifically with the methods on Object.prototype vs the
pervasive use of objects as string->value maps in JavaScript. What are we to
do about
getDefiningObject(JSON.parse(str), 'foo')
? Even without mutual suspicion within the program code, we would like to
reason about the correctness of this as quantified over all strings, for
example, even if the string is received from an external untrusted or
unreliable source.
>
> On the other hand, yes, since we have the ability to modify any JS code via
> console or even via browser address bar (using pseudo-protocol javascript:),
> then it can be viewed as the issue and as a security program.
>
> But the salvation by the big deal should not be found in making a dynamic
> language as a completely frozen and static, but in the disallowing of code
> modification (code injection, code poisoning if you will) via such a simple
> tools as the console or address bar.
>
> Having the ability to inject the needed code via console just makes e.g.
> browser scripting as just an _addition_ for the server code. This is in case
> if we have combined client-server application. It's obvious, that if we have
> some validation tool, then the validation on the client side should be done
> only as the _convenient addition_. But the same validation will be done on
> the server, since we understand that the client code can be easily injected
> (the simplest example e.g. utils.validate = function () { return true; }
> which always will return positive result).
>
> If we have only client-side application, then the user, if breaks some code
> via injection just breaks his own page and therefore just refuses the
> convenience we wanted to give him. He doesn't break anything besides his own
> page.
>
> So that's the language is dynamic and allow to change objects in runtime is
> not in my view about "correctness" of a program. A programmer, having
> control of his code, knows how and why he wants to augment and modify his
> current runtime objects and code.
>
> From this viewpoint I don't think we need to disallow modifying of
> `hasOwnProperty` and similar. Better then to reuse ES5 approach and separate
> this meta-operation to Object.hasOwnProperty(foo).
>
> The fact that a language is static perhaps doesn't cancel the fact that the
> code still can be injected, etc. So again, IMO a "correct program" is not
> about "let's freeze everything here". And "predefined and predicted
> contract" also relates to statics mostly. In "duck typing" exactly this
> contract can be achieved during the runtime -- one line before an object
> cannot pass the "duck-test", on the other line (after some mutations) it
> already can do this, it satisfies the contract -- and it's achieved not via
> statics in the language.
>
> Dmitry.
>
>
> [1] SES initialization freezes the primordials, so SES programs can
> safely assume they are frozen. But the point I'm making here are not
> specific to SES.
>
>
>>
>> Dave
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
>
> _______________________________________________
> es-discuss mailing
> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
