diff options
Diffstat (limited to 'JOURNAL')
| -rw-r--r-- | JOURNAL | 53 |
1 files changed, 53 insertions, 0 deletions
@@ -1,5 +1,58 @@ -*- mode: muse -*- +* 2007-09-26, 00:13:11 CEST + +** Licensing + +Licensing is another open question. For the moment, I'm releasing this +project under the terms of the GPLv3. This seems like a reasonable +choice, because it gives me the option of giving people more permissions +later by applying the LGPLv3 to my code. I must be aware that only I am +allowed to do this, though, and even then only if all contributors agree +(if someone actually makes a contribution, that is). I may want to +require all contributors to dual-license their contributions, or maybe +to make them available under the terms of the LGPLv3 in the first place +(though the latter would make marking them difficult). + + +* 2007-09-25, 20:59:40 CEST + +** Value Conversion Madness + +Open question: Should NSArray instances be converted to lists or arrays +automatically? If so, we ought to make functions like OBJC-CLASS-OF +behave in a reasonable way for those kinds of objects, i.e. return +NSArray or NSMutableArray (whatever it is that INVOKE makes out of them +when converting them into Objective-C instances again). + +Note that we *must not* convert NSMutableArray instances or any other +mutable objects in this way! Note also that our decision *must* be based +on the dynamic type of the object, not the static one, because a method +whose return type is NSArray may as well return an NSMutableArray that +we've fed it sometime earlier. This is okay for immutable objects, but +mutable objects are bound to cause trouble when such a thing happens. + +Related types of objects are strings (NSString), hash tables +(NSDictionary), and numbers (NSNumber). + +Note that such behaviour would make it impossible to fully identify CLOS +classes with Objective-C classes, as arrays would have no Objective-C +class to belong to. Then again, why would you want to distinguish +Objective-C arrays from Lisp arrays in your Lisp code, anyway? Real +integration means not having to worry about such things. + +On the other hand, conversion of large NSArrays may be prohibitively +expensive, so a switch is needed, either way. The real question is what +the default behaviour should look like. + +There's an alternative to consider, too. For NSArrays, there is +Christophe Rhodes' user-extensible sequence proposal, but even without +support for that, we can provide a *conduit* (a package) that looks like +the COMMON-LISP package, but overloads all sequence and hash-table +functions. Overloading all sequence functions might be a lot of work, +though. + + * 2007-09-23, 17:09:07 CEST ** Improved Memory Management for the Masses |