The contact list example uses a "contact" data structure defined by defstruct. Since defstruct structures are themselves CLOS objects, this is the example for now. The approach used there for accessing the individual slots of contact objects is to define individual per-slot getter functions that are call-ins available to Obj-C / Java. The macro def-contact-getters is used to eliminate the boilerplate around defining a getter for every slot.
I understand that this approach is heavy, and something more convenient is needed for simple use cases. If you'd like, I can try to push out a commit within the next few days that can auto-convert CLOS objects (or hash tables, if you prefer) to a suitable type on the Obj-C and/or Java side. Let me know your thoughts on this.
- Wukix, 1168 days ago
That *sounds* like what I'd want, but let me be explicit about the goals I'm currently attempting to achieve, to make sure we're on the same page.
1. I want UI interactions to result in the retrieval of an object which is ultimately backed by a CLOS object (maybe there's an interface layer between it and OBJ-C), which OBJ-C would then be able to call methods on.
2. I want the methods I expose to OBJ-C to be able to return lists which *could* contain CLOS objects (or their translated representations). So that I could then use the contents of that list in a list view. If it wasn't possible to do CLOS objects within the list then at least lists of lists.
3. I want to be able to return hashes ( also list of hashes, hashes of lists, etc). This one is lower priority since you can always pair lists to fake a hash.
The biggest thing is lists. There's SO much more we could do if we could just return a list of primitives (and lists). I'm just going by the Manual at the moment, which doesn't include lists as one of the available return types.
Re. the def-contact-getters My thought was that a macro like it, that auto-generates getters and setters for slots in a CLOS object should be part of a standard MOCL package that all MOCL projects could import. Just pass it your object and the appropriate package name and it'll inspect the object to see what slots it has and define getters/setters in that package (IF they haven't already been defined). Alternatively (and probably more easily) you could create a defmoclass macro which passed its arguments on to defclass and then went ahead and generated the getters / setters.
P.S. I'm still fairly new to Common Lisp so my apologies if I've missed something that would be obvious to someone more experienced with CL.
- masukomi, 1168 days ago
I just committed a new call-in :result option called "auto-object".
Lists and vectors are converted to NSMutableArray.
Lisp fixnums and floats are converted to NSNumber.
Strings are converted to NSString.
CLOS instances are converted to NSDictionary with string keys that have been downcased.
Individual elements of lists, vectors, and CLOS instances are converted according to the above rules.
The Objective-C return type for such a call-in is "id". So you could do something like:
id value = foo();
NSMutableArray value = foo();
if you know that only an array will be returned.
Let me know what you think.
- Wukix, 1165 days ago
Additional note: defstruct structures are not yet handled even though they are supposed to function as CLOS instances. Will have to work on that.
- Wukix, 1165 days ago
Sounds awesome. Will play with it this week and give you feedback.
- masukomi, 1163 days ago
Update: auto-object now maps structures of type structure-object to dictionaries as well.
- Wukix, 1162 days ago
For anyone following this ticket, some additional types are supported on the latest source code commits:
* Simple arrays with element-type '(unsigned-byte 8) now return as NSData
* nil returns as NSNull
* Symbols return as downcased NSString
* Hash tables return as NSDictionary
Additionally, most of these type conversions work in reverse. For example, if you pass an NSArray argument to a call-in function, it will be seen as a Lisp array inside the body of the function.
Finally, similar conversions are now also available in Android, but using idiomatic Java types: HashMap in place of NSDictionary, Object in place of NSMutableArray, byte in place of NSData.