From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carlos Pita Newsgroups: gmane.lisp.guile.user Subject: Re: A couple of questions about goops method parameters Date: Wed, 03 Sep 2014 12:49:38 -0300 Message-ID: <8761h466wd.fsf@gmail.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1409759428 17767 80.91.229.3 (3 Sep 2014 15:50:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Sep 2014 15:50:28 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Sep 03 17:50:18 2014 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XPCp5-0004AI-5J for guile-user@m.gmane.org; Wed, 03 Sep 2014 17:50:15 +0200 Original-Received: from localhost ([::1]:46234 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPCp4-0000TK-RU for guile-user@m.gmane.org; Wed, 03 Sep 2014 11:50:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPCok-0000QE-8v for guile-user@gnu.org; Wed, 03 Sep 2014 11:50:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPCob-0005hb-83 for guile-user@gnu.org; Wed, 03 Sep 2014 11:49:54 -0400 Original-Received: from mail-qg0-x235.google.com ([2607:f8b0:400d:c04::235]:57164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPCob-0005gz-2k for guile-user@gnu.org; Wed, 03 Sep 2014 11:49:45 -0400 Original-Received: by mail-qg0-f53.google.com with SMTP id z107so8530504qgd.12 for ; Wed, 03 Sep 2014 08:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=20GthbxKx6eEj3kiw744VKkWItMyqd1yWqmoWgq0KPo=; b=Wx23pF7aA4VDjI7nL9dFQ/kbctgIAWFerY5fKqYWaDw/Nl6FZZo74RlqM0v9MHllI6 VspsJAa2Wsxkm4I2azpKuduSekB1Y5RBjRt2UTLLQhNnQPfEbvaaGd3Z5NPm4L+7D/eE f86cOsGNrpNJPBKuKAdr8Q1/84Vu6toNHqnkGubN6DrJd0XNPiKc+iHfhV7yEAjjoksw QJ2l5Clb2SdcB4SUWgA2PkpuuyPbsfgsdnuPKw3wLXga05J0/zBxUNZpSIxYKmYPNFXK D9HVswZA9LGjzX8kUKbyjWNDeLxGn1qnojZdVOzl7k8z8RXOvdu31MBk1xhMqYDltB78 mCPw== X-Received: by 10.224.11.212 with SMTP id u20mr48929287qau.82.1409759384460; Wed, 03 Sep 2014 08:49:44 -0700 (PDT) Original-Received: from carlos ([181.228.217.164]) by mx.google.com with ESMTPSA id g52sm102165qgg.17.2014.09.03.08.49.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Sep 2014 08:49:43 -0700 (PDT) In-Reply-To: (Carlos Pita's message of "Tue, 2 Sep 2014 23:05:02 -0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c04::235 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:11450 Archived-At: > directly call initialize? In any case, why is this so? Wouldn't it be > better for initialize to just get the "unpacked" argument list? This > perplexes me. I've been thinking about this, and lurking at the tinyclos implementation, and then reading the cltl sections about initialization in clos. Despite the fact that clos make-instance indeed *apply* the initargs when calling initialize-instance, thus unpacking/destructuring the initargs list, everything in the specification seems to imply a plist style of usage. Even the name part of a name-value pair is used to choose between (i) direct initialization of the corresponding slot or (ii) calling the initialize-instance method with the name-value pair. So, all in all, the usage implied is akin to dealing with a (name value name value ...) list argument in goops or tinyclos. All this seems specifically oriented to slot initialization, not to general construction of a new instance while preserving some class invariant imposed to the internal data/slots (please, notice that my interest here is not about encapsulation or access control matters). So maybe I'm suffering from a paradigm mismatch kind of thing, as I'm trying to fit initialize into the usual OOP concept of constructor. From this perspective initialize (and initialize-instance) looks to me like erotic lingerie for slots (no pun intended, really :)), as maybe it isn't completely transparent but it's surely translucent regarding the underlying slots. The focus seems to be at a lower level of abstraction than the level the usual constructor operates in. I'm aware of virtual slots and, of course, of the possibility of implementing a custom initialize method, but these solutions only buy some degrees of freedom around the slot initializing focus: virtual slots still looks like slots and the argument to initialize is still a list, presumably of slot name-value pairs. I'm also aware of the possibility of defining read only slots but, again, this is not generally enough to offer convenient ways of construction that preserve some desired invariant. So, a question to the experienced lispers here, a question that's not specifically guile or goops or scheme related. Is the make (or make-instance) way of constructing a new instance usually exposed to the final user? Or a factory function, operating at a higher level of abstraction, is intended to wrap the lower level, slot-fillig oriented, call to make? In this case, a custom initialize method implementation should be seen more as a complement to make than as a proper constructor/factory. (Moreover, the visibility and access of constructor/factory functions are easily controlled using the module system although, as I've said before, that's not my interest here). Best regards -- Carlos