From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [IPv6:2a0c:5a00:149::26]) by sourceware.org (Postfix) with ESMTPS id 367CC3858D32 for ; Thu, 1 Dec 2022 22:16:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 367CC3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bothner.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bothner.com Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1p0rr3-001KvV-Ug for kawa@sourceware.org; Thu, 01 Dec 2022 23:16:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bothner.com ; s=selector1; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID; bh=MnO+qzYjVXE/YNvrTj4jS1vYXZRMeYSs+dMk2yU0Phs=; b=acqlzhMeH4pYOwVL1kqtBu5xI7 MstHuwI9VxoBGmmFo2CwflfZz6abTWjmAwj54ztrxaXgs7KQQnALyYASnult0OZV81qhjtijqQav2 9D27yc4qTU4qT7u5xs3QRSAqAh/Z4+IRTk1bf9OrJB6/ikwZKWVbJYxHqmsvi9REtObtlhE8rWCsi H4XrGE/15RF5lb82AL8+L+83C8dkAmNI7n4dAAgNS5RzGLcJ21IhTeuHkVnG3i18zqN0VAjb92vpJ gt5GJVnyIery0dU07t2asg3wBxf1jlYsZmPWAUL3yD43DSNHPvoFbNgKzlkk66WcBQFt3Pj5qYaSy dQ1ibjhQ==; Received: from [10.9.9.73] (helo=submission02.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1p0rr3-0004AY-Ap; Thu, 01 Dec 2022 23:16:29 +0100 Received: by submission02.runbox with esmtpsa [Authenticated ID (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1p0rr2-0000Ig-QG; Thu, 01 Dec 2022 23:16:29 +0100 Message-ID: Date: Thu, 1 Dec 2022 14:16:23 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: Having Named Parts Content-Language: en-US To: Panicz Maciej Godek , kawa@sourceware.org References: From: Per Bothner In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 12/1/22 03:19, Panicz Maciej Godek via Kawa wrote: > I've been trying to build a simple wrapper for a hash table, > that I call Bundle, such that > > (Bundle x: 5 y: 10) > > would return a bundle object, let's call it b, so that I could refer to its > fields using > > b:x That would be a nicer syntax, but there could be some problems combining the concepts of hash-table (extensible with arbitrary keys, not necessarily strings) and structures (with a fixed set of keys). JavaScript does it, and it does make things more convenient. There are a lot of issues to consider. Should key names be strings or symbols? What about keys that are not names (keys or strings)? How does this conflict with existing usage of colon-notation, and how do we deal with those? So I'm not sure if hash tables should implement HasNamedParts by default. An alternative is to use function-call notation, like we do for vectors: (TABLE KEY) (set! (TABLE KEY) VALUE) This has the advantage that it does't conflict with other uses of colon-notation. However, it doesn't provide a constructor syntax "for free". I brought up these concerns on the mailing list years ago. If someone can find these old message it might be helpful ... > I have found that Kawa offers a gnu.mapping.HasNamedParts interface which > facilitates value reference, ...s > The source code for the gnu.kawa.functions.SetNamedPart.apply3 method > reveals, that there was a plan for supporting this -- the method begins > with a commented-out fragment: > > /* > if (container implements HasNamedParts) > return ((HasNamedParts) container).getNamedPart(part); > */ > > which wouldn't work with current Kawa, because the HasNamedParts interface > doesn't containt getNamedPart method, and instead it contains a method > called get. I think that this could be fixed by: > - adding a method Object set(String key, Object value) to the HasNamedParts > interface > - uncommenting and fixing the above snippet to invoke the above method. That is probably OK, except use 'put' instead of 'set' to be consistent with java.util.Map. Also, 'put' needs a default implementation, which should probably throw UnsupportedOperationException. (Defaults were added in Java 8. It is probably OK to require Java 8 as a minimum at this point - though Android might be an issue.) Do compare with the getNamedPart and apply 2 method in GetNamedPart. They handles various extra cases, that might not be appropriate for a setter. > By the way, the interface also contains isConstant method, which doesn't > seem to be documented anywhere. isConstant(KEY) returns true is the binding for KEY is immutable. It is used to optimize namespace resolution. I think that also - for consistency - the > interface should also provide a boolean hasPartNamed(String name) method. > > But this only solves one problem, and there's another one, namely - when I > try to initialize Bundle as, say > > (Bundle x: 5 y: 10) > > I get the following warnings: > > /dev/tty:6:20: warning - no field or setter 'x' in class Bundle > /dev/tty:6:20: warning - no field or setter 'y' in class Bundle > > These are issued from the build() method in > gnu.kawa.reflect.CompileBuildObject. It does seem that this class doesn't > take into account the existence of the HasNamedParts interface at all. That is probably the case. > Is there any way out of this situation? If there was a clean problem-free solution I would have already done so ... That doesn't mean we shouldn't have a better syntax for hash-tables, or that this is a dead end - but there are definitely a number of issues to consider. -- --Per Bothner per@bothner.com http://per.bothner.com/