{"action":"created","issue":{"url":"https://api.github.com/repos/jamesladd/stc/issues/10","repository_url":"https://api.github.com/repos/jamesladd/stc","labels_url":"https://api.github.com/repos/jamesladd/stc/issues/10/labels{/name}","comments_url":"https://api.github.com/repos/jamesladd/stc/issues/10/comments","events_url":"https://api.github.com/repos/jamesladd/stc/issues/10/events","html_url":"https://github.com/jamesladd/stc/issues/10","id":262056100,"number":10,"title":"Playing with the JVM Reciever","user":{"login":"mattys101","id":30459857,"avatar_url":"https://avatars2.githubusercontent.com/u/30459857?v=4","gravatar_id":"","url":"https://api.github.com/users/mattys101","html_url":"https://github.com/mattys101","followers_url":"https://api.github.com/users/mattys101/followers","following_url":"https://api.github.com/users/mattys101/following{/other_user}","gists_url":"https://api.github.com/users/mattys101/gists{/gist_id}","starred_url":"https://api.github.com/users/mattys101/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mattys101/subscriptions","organizations_url":"https://api.github.com/users/mattys101/orgs","repos_url":"https://api.github.com/users/mattys101/repos","events_url":"https://api.github.com/users/mattys101/events{/privacy}","received_events_url":"https://api.github.com/users/mattys101/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2017-10-02T11:31:43Z","updated_at":"2017-10-05T13:43:06Z","closed_at":null,"author_association":"NONE","body":"I've been playing with the concept of the JVM receiver a little  \r\n[JVMReceiver-Example.zip](https://github.com/jamesladd/stc/files/1348719/JVMReceiver-Example.zip)\r\n\r\nYou might not want to look at the code files, they are a bit hacky and woefully incomplete, but the smalltalk file might give you an idea of what I am thinking.\r\n\r\n    | tempVar |\r\n    tempVar := 3.\r\n    JVM invoke: 'println' on: 'java.lang.System.out' with: 'TestingJVM'.\r\n    JVM invoke: 'print' on: 'java.lang.System.out' with: 1.\r\n    JVM invoke: 'println' on: 'java.lang.System.out'.\r\n    JVM invoke: 'println' on: 'java.lang.System.out' with: 2 ofType: 'int'.\r\n    JVM invoke: 'println' on: 'java.lang.System.out' with: tempVar ofType: 'int'.\r\n\r\nThe core of it is to the JVM pseudo variable a suite of 'methods' like\r\n\r\n    invoke:on:\r\n    invoke:on:with:\r\n    invoke:on:with:ofType:\r\n\r\nthat can be used in different situations and have varying degrees of inference depending on whether the values given are literals or variables. That sort of thing.\r\n\r\nBasically, I think if we can give the JVM reciever a nicer interface and some smarts, we can make it a little more natural to mix adaptor code with Smalltalk code. For example, we could perform calculations, call other methods, etc. using standard Smalltalk and use the result in the code output by the JVM receiver. I think your original one was much more limited, unless I am mistaken, and basically required you to write methods as if you were writing the byte code directly?\r\n\r\nThe other thing about giving it some smarts is that you can potentially detect some issues at (smalltalk) compile time, not when the code is executed, which I think was a bit of a problem before?\r\n\r\nWhat do you think?\r\n\r\nMatt\r\n"},"comment":{"url":"https://api.github.com/repos/jamesladd/stc/issues/comments/334468713","html_url":"https://github.com/jamesladd/stc/issues/10#issuecomment-334468713","issue_url":"https://api.github.com/repos/jamesladd/stc/issues/10","id":334468713,"user":{"login":"mattys101","id":30459857,"avatar_url":"https://avatars2.githubusercontent.com/u/30459857?v=4","gravatar_id":"","url":"https://api.github.com/users/mattys101","html_url":"https://github.com/mattys101","followers_url":"https://api.github.com/users/mattys101/followers","following_url":"https://api.github.com/users/mattys101/following{/other_user}","gists_url":"https://api.github.com/users/mattys101/gists{/gist_id}","starred_url":"https://api.github.com/users/mattys101/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mattys101/subscriptions","organizations_url":"https://api.github.com/users/mattys101/orgs","repos_url":"https://api.github.com/users/mattys101/repos","events_url":"https://api.github.com/users/mattys101/events{/privacy}","received_events_url":"https://api.github.com/users/mattys101/received_events","type":"User","site_admin":false},"created_at":"2017-10-05T13:43:06Z","updated_at":"2017-10-05T13:43:06Z","author_association":"NONE","body":"The emitter stuff looks much neater than your previous version.\r\n\r\nThinking about the Java wrapper class. I may not have fully understood what you were thinking and am struggling to determine where the wrapper class and the old Adapter depart in their approach.\r\n\r\nSo with what you sketched above:\r\n\r\n    | j |\r\n    j := Java new: 'MyJavaClass'.\r\n    j call: 'someMethod'.\r\n    j call: 'someMethodWithArg' with: arg1 and: arg2.\r\n\r\nmy thinking is that you would get an instance of the 'Java' class that wraps an object of the specified class. The Java class itself does not necessarily have many methods other than say `call:`, `call:with`, `call:withArgs:` and similar, maybe some to retrieve (non-private) fields. These methods would be dynamic and search for the appropriate methods of the underlying java object and call them, most likely with caching so it doesn't have to search every time. But it wouldn't generate an in memory class like the old Java Adapter did. Is that right?\r\n\r\nA possible issue might be dealing with static methods since something like:\r\n\r\n    Java new: 'java.lang.System'.\r\n\r\nwould create an instance of 'java.lang.System' wrapped by an instance of Java. One possibility is to have another wrapper class `JavaStatic` that gives access to the static members of the class. JNIPort does something similar to this IIRC. Then you could do something like:\r\n\r\n    | j |\r\n    j := JavaStatic new: 'java.lang.System'.\r\n    j call: 'exit' with: 1.\r\n\r\nBut accessing fields might be problematic/messy, for example:\r\n\r\n    out := j field: 'out'. \"if we extend the metaphor used for the call: method\"\r\n    out call: 'println' with: 'this isn''t too bad, except you have to store it in a variable'.\r\n    (j field: 'out') call: 'println' with: 'this is starting to look messy though'.\r\n    j out call: 'println' with: 'this is a little better'.\r\n    j out println: 'this is the nicest way though'.\r\n\r\nThe problem is I think the last two bring us back into Adapter territory, unless we did it all dynamically based on an implementation of `#messageNotUnderstood`. If that were the case, we could allow adapter classes to be created manually (or semi-automatically) that subclass the classes `Java` or `JavaStatic` as appropriate, where methods can be implemented if desired. This way the dynamic behaviour can be inherited if you are lazy ;-) or you could implement the adapter methods yourself if you wanted. You could even ship some pre-made adapters for commonly used classes if you wanted. (Maybe some of the core classes String, List, Set, etc. may even be (special) adapter classes? Or maybe I am just over thinking things now)\r\n\r\nIs this the type of thing you were thinking? If I can get on the same page (or at least pick up the same book) I might be able to start working on the `Java` and `JavaStatic` classes.\r\n\r\nBTW: I think such an approach would be very JNIPort-ish, which is not necessarily a bad thing in that anyone working with JNIPort in their current Smalltalk environment wouldn't really need to change the way they interact with Java. Not sure if that is your intention though or if it is the best approach.\r\n\r\nWhat do you reckon?"}}
{"actor":{"display_login":"mattys101"}}