From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sat, 17 Oct 2015 06:56:49 +0300 Message-ID: <5621C701.5030608@yandex.ru> References: <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> <561A6199.1020901@cumego.com> <561B9D87.70504@yandex.ru> <561C2C17.3090503@cumego.com> <561DC1CA.6090901@siege-engine.com> <561E3FB6.8010407@yandex.ru> <561EEFDE.7000809@gmail.com> <561F29D0.3070605@yandex.ru> <561FA79C.30207@gmail.com> <56200D07.30206@yandex.ru> <5620A99E.7080009@cumego.com> <5620D109.2010006@yandex.ru> <5620DCCD.8030809@cumego.com> <87y4f2u5ef.fsf@fimbulvetr.bsc.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1445054242 23226 80.91.229.3 (17 Oct 2015 03:57:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 03:57:22 +0000 (UTC) To: =?UTF-8?Q?Przemys=c5=82aw_Wojnowski?= , Eric Ludlam , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 05:57:15 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZnIcK-00066T-1m for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 05:57:12 +0200 Original-Received: from localhost ([::1]:56852 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnIcJ-0001WL-0j for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 23:57:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnIcD-0001W6-GU for emacs-devel@gnu.org; Fri, 16 Oct 2015 23:57:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnIc1-00077s-S9 for emacs-devel@gnu.org; Fri, 16 Oct 2015 23:56:58 -0400 Original-Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:33831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnIc1-00077N-Jl for emacs-devel@gnu.org; Fri, 16 Oct 2015 23:56:53 -0400 Original-Received: by wicgb1 with SMTP id gb1so31580566wic.1 for ; Fri, 16 Oct 2015 20:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=hWBtZsSnUd8akKnAMLi69s+/WMLts4TpnT5aOZ+zF4w=; b=wB3o9zIMo/bpkH5++WmpCtevi8ySc3ZPERC8P8jYD6v9/K6ZycfiTJB9fn74hYfcRp NHvP9QKscK5m1RIpAtX436iigXxxOc9l/xNMPJGKd3fL8oTwNkL4ykHYWAeml0z7m6Hh SNkyFzDuK97Gg25lHlhD4p9pS6kVWmmiDCLWB2o0yUBPyM82OXmsRAzAuHHF/KZZa2+M Rw7bnv+C/MWTdkGP42UNWwb7m38APNR9Fq1QHzFzeMFTf/CN1alQlfHtly0foNoMDuTn a2gPsvkfjq46vD72c/azZukaQ/Fa6BFRmYHKea7b5KiZdAc7z2t6TMO2uRbg3G+B3NhM 1qFQ== X-Received: by 10.194.82.198 with SMTP id k6mr20720007wjy.139.1445054213051; Fri, 16 Oct 2015 20:56:53 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id a9sm5533283wiy.11.2015.10.16.20.56.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Oct 2015 20:56:51 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <87y4f2u5ef.fsf@fimbulvetr.bsc.es> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191808 Archived-At: On 10/16/2015 07:47 PM, Lluís wrote: > * service-type: A type of service (one instance per type), like build, find root > directory, include search paths, compilation flags, etc. > > * service: A specific implementation of a service type, like using vc-dir for > finding the root directory of a project. This sounds good. The implementations could be different (e.g. Java-ish Service Locator [0]), but in the absence of other requirements the closest Emacs idiomatic structure would be a hook (list of functions) for each service type. Like project-find-functions, for example. Note that the objects the latter currently returns provide both "find root" and "search path" services. Thus far it seemed to make sense. Can one, and would one want to create different search-path services working with the same find-root service? That's an interesting question, and I'd love to see a practical example. More generally, if a package P registers services A, B and C, if B needs some information from A, would we expect them to go through P-internal channels, or the public interface? For instance, most services might like to know the project root (let's call that service type R). We could standardize the dependencies like that. In the simplest case, all services depend on project-root (except for itself), and we'll pass the current project-root instance to each functions in their hooks. Then an element of service-b-functions will only return non-nil if that implementation of B can work with the given kind of project-root (or simply "project"; we might include some more info into that instance as well). On the flip side, if there are no B implementations that can work with the currently detected R service r1, but there's a certain b2 in service-b-functions that would work with r2 (currently shadowed by r1), we may be missing out. > * service-collection: A set of service implementations of the same service > type. This allows aggregating results from each service into a single answer. I suppose you can get this from the same service-b-functions hook, if you treat it in a different way. > * project-type: A type of project defines the service collections it provides > for each service type it knows about. An example could be an Emacs project > (knows how to auto-detect it, things like the build system it uses, etc.), and > Android project, a Linux kernel project, an autotools project, etc. Having to declare each combination of service-types that a project can provide still seems unnecessarily limiting (and tedious). But that's what project-types would be for, right? How would a client even use those declarations? If we were to go that way, it'd be better to simply have a project instance have a method that returns a list of all services it supports. Or, even simpler, return a nil or raise a not-implemented error in each of the generic methods it doesn't implement. Next, suppose a project instance can tell whether it provides a "build tool" service. What does a "call build task" command does? Looks for the current project and gives up if it doesn't provide the required service, or specifically asks the locator for a project implementation that does provide that service? In the latter case, we potentially buy more functionality, at the cost of having different commands disagree about what the current project actually is. > Thanks, > Lluis > [0] http://martinfowler.com/articles/injection.html#ADynamicServiceLocator