Re: problem during calling method from closure
Hi Anton, could you please point out to me the concepts you mention in a private email ? It still seems to me that what I said was right, see for instance: https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented Cheers, mg (Many of these topics are quite old, and things which are no big deal now definitely were back then, such as the fact that C++ is not a TRUE OO language, since calls are only virtual if the method carries that explicit keyword - a useless design decision from my experience, yes (I remember trying to find a case where non-virtual calls actually gave a performance advantage in my C++ game engine back in 2000, and just could not construct a real world example), but at the same time not that big a deal in practice (why the much younger language of C# uses the same concept remains puzzling, though.)) On 15/10/2020 20:16, Anton Shepelev wrote: MG about Alan Kay's "message passing": It is not an approach per se, but just terminology. Lest I annoy the list administrators by continuing this off- topic disussion, I will confine my reply to the remark that Kay's concept of message passing is not mere terminology. It is also more that just an approach -- it is a full-fledged paradigm, alghough OCsite may not have meant it that way when he mentioned it. Thanks for sympathy.
Re: problem during calling method from closure
MG about Alan Kay's "message passing": > It is not an approach per se, but just terminology. Lest I annoy the list administrators by continuing this off- topic disussion, I will confine my reply to the remark that Kay's concept of message passing is not mere terminology. It is also more that just an approach -- it is a full-fledged paradigm, alghough OCsite may not have meant it that way when he mentioned it. Thanks for sympathy.
Re: Defining a global variable
On 15/10/2020 18:27, Jochen Theodorou wrote: well.. even scripts are first compiled into a class before the class is then executed. Groovy has no interpreter Which, I think, is a lesser known fact, and quite surprising to people who perceive Groovy just under its "script language" aspect ;-)
Re: Defining a global variable
On 15.10.20 12:16, Anton Shepelev wrote: Jochen Theodorou to Anton Shepelev: Jochen Theodorou: Frankly... for years we have been defending this position, but now, with so much distance I actually really wonder why we keep this. Perhaps it would have helped if you had documented not only language features but also their rationale (justification), at least is difficult, debatable cases. the reason is easy: it reflects the implementation. But the implementation can be changed The implementation reflects the implementation? I do not understand. specification by implementation I mean [...] Whereas methods are also code, I believe it would be much clearer if it said "immediate code" -- code that is executed immediately rather than compiled into a callable method. well.. even scripts are first compiled into a class before the class is then executed. Groovy has no interpreter [...] I am not sure, but we both failed to find that paragraph until Maarten pointed it out. But now that I think about it again, it is the right place. I was searching for something different. A more high-level description of variable scopes and how they work instead of describing the specific case of a script with the common base class. bye Jochen
Re: problem during calling method from closure
On 15/10/2020 13:03, Anton Shepelev wrote: we definitely should have sticked with Alan Kay's "message-sending", and there would be much less misunderstandings and problems today. I fear this message-passing approach even further from normal proceudural prgramming that conventinal OO languages and would therefore be even more confusing and unintuitive. It is not an approach per se, but just terminology. And when coming from Assembler/C/C++, like I do, it is a very confusing one: At the end of the day, it is always just about pushing the arguments on the stack and picking the subroutine address to which the CPU shall branch, whether that address selection is static (and can therefore be done at compile time), virtual (i.e. based on the object the function is called for, which requires a (quick and simple) virtual function table lookup for the object's class at runtime), dynamic (i.e. based on the object and the argument types on the stack, like Groovy does), or completely custom implemented in the language itself (as can be done in Groovy). It is never about passing messages from one object to the other, which to me implies creating messaging objects, which are being put into a queue for asynchronous processing by the receiving object (possibly with prioritization, ...), and maybe being sent over a network connection, etc. So a much more heavy & slower mechanism than what actually takes place. Of course one often times finds logical/natural what one first encountered, but keeping that in mind, from what lies underneath it, calling it a method call with passed arguments still makes the most sense to me. Cheers, mg
Re: No signature of method: javax.swing.JMenu.setMnemonic()
Unfortunately no. Not sure how to address it because it seems a type
conversion problem in the `MacOSXmenuBar`
```
menu(text: 'File', mnemonic: 'F') {
menuItem(newFileAction, icon:null)
menuItem(newWindowAction, icon:null)
menuItem(openAction, icon:null)
separator()
menuItem(saveAction, icon:null)
menuItem(saveAsAction, icon:null)
separator()
menuItem(printAction, icon:null)
}
```
it should be
```
menu(text: 'File', mnemonic: 'F' as char)
```
On Tue, Oct 13, 2020 at 9:18 PM Mariusz W wrote:
> Hi,
> Have you resolved that issue?
> I have done some tests but on Windows and it works ok.
>
> Regards,
> M
>
> On Sun, 11 Oct 2020 at 19:35, Paolo Di Tommaso
> wrote:
>
>> Dear all,
>>
>> I'm getting this exception while launching the Groovy console from my
>> app.
>>
>>
>> groovy.lang.MissingMethodException: No signature of method:
>> javax.swing.JMenu.setMnemonic() is applicable for argument types: (String)
>> values: [F]
>> Possible solutions: setMnemonic(char), setMnemonic(int), getMnemonic()
>> at
>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:70)
>> at
>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:76)
>> at
>> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:80)
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:194)
>> at
>> groovy.ui.view.MacOSXMenuBar$_run_closure1.doCall(MacOSXMenuBar.groovy:79)
>> at
>> groovy.ui.view.MacOSXMenuBar$_run_closure1.doCall(MacOSXMenuBar.groovy)
>> :
>>Complete stack trace here .
>>
>>
>> I saw this was an issue with Groovy 3 beta
>> , however, I'm using
>> Groovy 3.0.5, Java 8 on MacOS.
>>
>>
>>
>> Any clue what's could be the problem?
>>
>>
>> Thanks,
>> Paolo
>>
>>
