Important: 1. do you use allowJavaScriptCalls? 2. If yes, try if this works

> Hello!
>
> I played with boot.js and found allowJavaScriptCalls is a bit strange.
>
> It allows an otherwise Smalltalk object try to perform JS calls /
> property access in case of DNU,
>
> So far, only known object using this on a regular basis is jQuery. I
> have two pleas for you:
>
> 1. Do you use allowJavaScriptCalls in your projects? Tell me in what
> circumstances.
>
> 2. I found this split-personality state of these objects strange and
> another solution came to my mind. Instead of adding special case
> .allowJavaScriptCalls = true to an object, I can just .klass = null
> ("foo basicAt: 'klass' put: (JSON parse: 'null')" in Smalltalk). This
> way I opt out of Smalltalk behaviour completely (so the basicAt: was
> last Smalltalk thing done on the object), instead opting in for JS
> treatment.
>
> It needed very little changes to run (in fact, it worked out of the box;
> but tests should have needed to be updated to have done new thing and
> allowJavaScript code had to be removed from boot.js to have shown it
> worked without it). This new variant is present in 'null-klass' branch
> of amber-smalltalk/amber repo (should be installable by `bower install
> amber#null-klass` into your project unless I am not mistaken). If you
> answered 'YES' in 1., could you please try if the new approach works for
> you (you must change the allowJavaScriptCalls<-true to klass<-null)?
>
> Additionally, tell what you think of the change. Is it good one?
>
> Thanks, Herby
>
> --
> You received this message because you are subscribed to the Google Groups
> "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>

> On Dec 7, 2014, at 7:06 PM, Herby Vojčík <[hidden email]> wrote:
>
> Hello!
>
> I played with boot.js and found allowJavaScriptCalls is a bit strange.
>
> It allows an otherwise Smalltalk object try to perform JS calls / property access in case of DNU,
>
> So far, only known object using this on a regular basis is jQuery. I have two pleas for you:
>
> 1. Do you use allowJavaScriptCalls in your projects? Tell me in what circumstances.
>
> 2. I found this split-personality state of these objects strange and another solution came to my mind. Instead of adding special case .allowJavaScriptCalls = true to an object, I can just .klass = null ("foo basicAt: 'klass' put: (JSON parse: 'null')" in Smalltalk). This way I opt out of Smalltalk behaviour completely (so the basicAt: was last Smalltalk thing done on the object), instead opting in for JS treatment.
>
> It needed very little changes to run (in fact, it worked out of the box; but tests should have needed to be updated to have done new thing and allowJavaScript code had to be removed from boot.js to have shown it worked without it). This new variant is present in 'null-klass' branch of amber-smalltalk/amber repo (should be installable by `bower install amber#null-klass` into your project unless I am not mistaken). If you answered 'YES' in 1., could you please try if the new approach works for you (you must change the allowJavaScriptCalls<-true to klass<-null)?
>
> Additionally, tell what you think of the change. Is it good one?
>
> Thanks, Herby
>
> --
> You received this message because you are subscribed to the Google Groups "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.

>>
>> Hello!
>>
>> I played with boot.js and found allowJavaScriptCalls is a bit strange.
>>
>> It allows an otherwise Smalltalk object try to perform JS calls / property access in case of DNU,
>>
>> So far, only known object using this on a regular basis is jQuery. I have two pleas for you:
>>
>> 1. Do you use allowJavaScriptCalls in your projects? Tell me in what circumstances.
>>
>> 2. I found this split-personality state of these objects strange and another solution came to my mind. Instead of adding special case .allowJavaScriptCalls = true to an object, I can just .klass = null ("foo basicAt: 'klass' put: (JSON parse: 'null')" in Smalltalk). This way I opt out of Smalltalk behaviour completely (so the basicAt: was last Smalltalk thing done on the object), instead opting in for JS treatment.
>>
>> It needed very little changes to run (in fact, it worked out of the box; but tests should have needed to be updated to have done new thing and allowJavaScript code

>>
>> Additionally, tell what you think of the change. Is it good one?
>>
>> Thanks, Herby
>>
>> --
>> You received this message because you are subscribed to the Google Groups "amber-lang" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
>> For more options, visit https://groups.google.com/d/optout.
>

> jQuery has it by default, so you can do jQuery ajax: ... etc. while
> simultaneously treat it as Smalltalk object (instance of
> BlockClosure). Without it, you could not do #ajax:. With new solution
> you wouldn't be able to do #value: etc (not that I see anyone using
> jQuery value: x, there is #asJQuery for that).
>
> It is nevertheless questionable to me whether it should be removed or
> not. JSObjectProxy is also not _completely_ transparent. It has
> operation of its own and ones inherited from ProtoObject. Only if
> those are not met, DNU does the proxying... but this seems as general
> issue - how minimal set of operations should this kind of proxy have
> to be able to blend in to the image while still proxying to its target...
>
> sebastian wrote:
>> 1. No. Not even aware of it.
>> 2. Sounds like a good idea to me
>>
>> I’m curious.. what applicability does this have? what problem does it
>> solve?  you’d use it to achieve what?
>>
>>
>>
>>> On Dec 7, 2014, at 7:06 PM, Herby Vojčík<herby@mailbox.
> sk>  wrote:
>>>
>>> Hello!
>>>
>>> I played with boot.js and found allowJavaScriptCalls is a bit strange.
>>>
>>> It allows an otherwise Smalltalk object try to perform JS calls /
>>> property access in case of DNU,
>>>
>>> So far, only known object using this on a regular basis is jQuery. I
>>> have two pleas for you:
>>>
>>> 1. Do you use allowJavaScriptCalls in your projects? Tell me in what
>>> circumstances.
>>>
>>> 2. I found this split-personality state of these objects strange and
>>> another solution came to my mind. Instead of adding special case
>>> .allowJavaScriptCalls = true to an object, I can just .klass = null
>>> ("foo basicAt: 'klass' put: (JSON parse: 'null')" in Smalltalk).
>>> This way I opt out of Smalltalk behaviour completely (so the
>>> basicAt: was last Smalltalk thing done on the object), instead
>>> opting in for JS treatment.
>>>
>>> It needed very little changes to run (in fact, it worked out of the
>>> box; but tests should have needed to be updated to have done new
>>> thing and allowJavaScript code
> had to be removed from boot.js to have shown it worked without it).
> This new variant is present in 'null-klass' branch of
> amber-smalltalk/amber repo (should be installable by `bower install
> amber#null-klass` into your project unless I am not mistaken). If you
> answered 'YES' in 1., could you please try if the new approach works
> for you (you must change the allowJavaScriptCalls<-true to klass<-null)?
>>>
>>> Additionally, tell what you think of the change. Is it good one?
>>>
>>> Thanks, Herby
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "amber-lang" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to [hidden email].
>>> For more options, visit https://groups.google.com/d/optout.
>>
>