From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Tadeus Prastowo Newsgroups: gmane.emacs.devel,gmane.emacs.help Subject: Re: modularity, code for yourself and possibly others Date: Tue, 2 Apr 2019 11:42:59 +0200 Message-ID: References: <86wokiqznt.fsf@zoho.eu> <86wokd9xi6.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="82938"; mail-complaints-to="usenet@blaine.gmane.org" Cc: help-gnu-emacs@gnu.org, emacs-devel To: Emanuel Berg Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 02 12:26:51 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hBGcz-000LQj-Um for ged-emacs-devel@m.gmane.org; Tue, 02 Apr 2019 12:26:50 +0200 Original-Received: from localhost ([127.0.0.1]:36858 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBGcy-00055q-O5 for ged-emacs-devel@m.gmane.org; Tue, 02 Apr 2019 06:26:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBGcl-0004hM-Ci for emacs-devel@gnu.org; Tue, 02 Apr 2019 06:26:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBGSG-0001jB-0B for emacs-devel@gnu.org; Tue, 02 Apr 2019 06:15:45 -0400 Original-Received: from mail-it1-x135.google.com ([2607:f8b0:4864:20::135]:53431) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hBFwn-00018j-4m for emacs-devel@gnu.org; Tue, 02 Apr 2019 05:43:13 -0400 Original-Received: by mail-it1-x135.google.com with SMTP id y204so4018810itf.3 for ; Tue, 02 Apr 2019 02:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unitn.it; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EsklsIKjPfC1iqHN9+yDsiMDnidN99XVlkgfjQ/K9kA=; b=HS4fiHXuC4sZ5WXPpBe1u0wrjZ9Ct9o3ldsOqJY8qdXUVR7PLQeabXGAfJcvZFNssN YYsJJhGwjzaRWNooHKtV/EtFFB5HrN1wjXRl6QFm/63lFr8U6WTNv8es99QdVLxfiKpb p3o12pntlFlUhT8tbkklVf6O14MkVCnbvDHrU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EsklsIKjPfC1iqHN9+yDsiMDnidN99XVlkgfjQ/K9kA=; b=IYvm/9FzWsv0XbktffAcOnEyBA+KpGjAdwYJY0JV5Y/Mit/L9dYww+aiMRaKOgiqaG opPeX38salaRMaxcN6QVIRt8Yj0sy5RjYy7UtdL2JAVtTP3y9dqRGV1ACYQBdKtpGT2l aJDWlSsT5YNBOmxp7D8HHMLG9yZePREwiRFYxRWGSyE0nJAQegK4eosmXNXsabl34tPF +UZp32lySZmkGovTcWDDNgb0LuFt4xMI2szsJ+JxqwLWadMnjHqEdF5h0U8AKgAyhWCK +1bddZsa//9Awh3wIQBoImnCqRf69DRoq8eftaSK+Ht4Wm/UGTet5e2/6J2xGdfDFf2Z uTNg== X-Gm-Message-State: APjAAAXdlnbiCH9SdRDuFf+FK5oFrfv/LmWx2XITsktJso7klEcrAdz7 lVdciNqFmPMm/OKUSgDXlBTlhFE8X4svVk8aJDfO X-Google-Smtp-Source: APXvYqxOjc4fPVGALHE+C6IasMQZx1jrYUWp1jUaNwjTDpQ3Gb9Bdtb4KukK3HmAIrtfwk7+tEqA6RWHfbm9ROK0Iic= X-Received: by 2002:a24:9f47:: with SMTP id c68mr3228895ite.110.1554198190430; Tue, 02 Apr 2019 02:43:10 -0700 (PDT) In-Reply-To: <86wokd9xi6.fsf@zoho.eu> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::135 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:234858 gmane.emacs.help:119826 Archived-At: On Tue, Apr 2, 2019 at 12:48 AM Emanuel Berg wrote: > Moving one function from edit.el to some other > file would require the user to `require' that > file instead, and that file would `require' yet > another file(s), and so on. How would that be > any different? > > In the extreme case, for someone else to use > a single of my .el files, s/he would have to > use my entire Elisp system! Rather than going off tangent now by talking about the extreme case, what about if we confine our discussion _for now_ to your specific case of dealing with your pet function `delete-blank-lines'? If you agree, then let's say we put that pet function to its own file `whitespace-cleaners.el'. As of now, that file will require no other file. So, its user will need to require only that file if that user needs no other function of yours. Problem solved here. Now, let's enlarge the case a bit. Suppose now the user also wants to use one other function of yours in file `edit.el'. If you had engineered that function _and_ that file properly, then the user would have no need to have your entire Elisp system. Problem solved. Jumping now to the general situation, a tradeoff exists between reinventing the wheel and having a long chain of dependencies. For having zero dependency, reinvent all the wheels. To minimize wheel reinventions, add further dependencies. As the engineer of your own Elisp system, you should think about the right design; surely different potential users of your Elisp system have their own requirements regarding this tradeoff. -- Best regards, Tadeus