summaryrefslogtreecommitdiff
path: root/JOURNAL
diff options
context:
space:
mode:
Diffstat (limited to 'JOURNAL')
-rw-r--r--JOURNAL53
1 files changed, 53 insertions, 0 deletions
diff --git a/JOURNAL b/JOURNAL
index f446a32..972a92a 100644
--- a/JOURNAL
+++ b/JOURNAL
@@ -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