From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-67258-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id A8038138A2F
for <garchives@archives.gentoo.org>; Sat, 16 Aug 2014 22:32:22 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 1BC76E0948;
Sat, 16 Aug 2014 22:32:16 +0000 (UTC)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 19E43E0942
for <gentoo-dev@lists.gentoo.org>; Sat, 16 Aug 2014 22:32:14 +0000 (UTC)
Received: by mail-qa0-f46.google.com with SMTP id v10so3196528qac.19
for <gentoo-dev@lists.gentoo.org>; Sat, 16 Aug 2014 15:32:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=kxaR+GVGXN+eut76ZtwojNmS/3t5ptGiNwLoNARfqaA=;
b=beiCXHP/x5ty3i23MWxR+51nmW7u06qIpC6x5ydq3OCCXm//D2zrcXw/bEunCy6yys
qY2CqqLC5uynMpJEsuXMbKJ8fWJm7bAyPa9YQjDM9QM4bthV8U1CUaL90u4mmSjUEe7l
eOFBH/o0P3fRQONsyOiK6XYWufoS/O0vZyRQ2wUeCxSWI48pidLxiVhZ9JgHXa7bBKU2
SaN1rFbsP+HBZoopZZyHoWnUr1x0SxAxa51jKfRLUdD2yY7wg13avgracZj/DBPHTLhp
h8NsrbnqvN+7mMhHLxSqoe1QKA6ONFU8mYgnt1BxSzACueF1iCUNyr5fVtISedBmU8Y4
UeiA==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.224.89.10 with SMTP id c10mr42562277qam.51.1408228334202;
Sat, 16 Aug 2014 15:32:14 -0700 (PDT)
Received: by 10.140.44.34 with HTTP; Sat, 16 Aug 2014 15:32:14 -0700 (PDT)
In-Reply-To: <20140816215428.GA6773@linux1>
References: <20140816215428.GA6773@linux1>
Date: Sun, 17 Aug 2014 10:32:14 +1200
Message-ID: <CAATnKFB4E3UrQgeRvi5h0N0tXkhUT8mR3Yk56t2hiy9afojqCQ@mail.gmail.com>
Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev@lists.gentoo.org
Content-Type: multipart/alternative; boundary=001a11c3bf009f75d40500c6b590
X-Archives-Salt: a47470c1-40f6-490d-af76-da77b4d62cc5
X-Archives-Hash: 573df62d97a7e7d41482b36dc00a39e5
--001a11c3bf009f75d40500c6b590
Content-Type: text/plain; charset=UTF-8
On 17 August 2014 09:54, William Hubbs <williamh@gentoo.org> wrote:
> I strongly oppose this change, because I feel it will make our
> entire tree very unpredictable at best. I realize this might eliminate
> boilerplating from our tree. Weighing that against the possible
> ramifications in this big of a change in automagic behaviour, I think
> the cost is much higher than the gain.
>
>
I agree on that part, for what its worth.
The current system we have in place is an analogue of "role based" or
"trait based" inheritance, where you have very straight forward composition
behavior with regards to the final ebuild.
One of the parent classes "wins", and if you don't like this, you have to
adapt it manually.
This in practice usually proves more useful than diamond style multiple
inheritance, that while seeming like a nice idea in concept, in practice
proves more complicated than its worth.
The only downside I see is we don't have a clear straight forward collision
strategy, which is essential for most role based systems:
For instance,
dog.eclass : function bark
tree.eclass: function bark
Proves not to be resolvable automatically in a sensible way.
Collison systems I've seen usually do one of two things:
- In the event of a collision, demand the consumer resolve the problem by
redefining the function the collision occurs on in terms of its composite
parts. ( which is basically what we already do )
- Declare syntax to "exclude" a potential collision from either composite
part.
Our only real difference at present is unlike these systems, we assume we
can simply guess which one wins and just choose it automatically, where
collision systems tend to force you to deal with the situation if any
collision occurs.
> I am also not very comfortable with our current state, because it has
> a lot of uncertainty in terms of how the eclass phase functions are
> called.
>
> My counter proposal to this is that we stop calling eclass phase
> functions automatically, and to minimize the amount of boilerplating
> we would have to do, we use a variable, such as ECLASS_PHASES which
> would be defined at the ebuild level and contain a list of the eclass
> phase functions we want to run automatically.
>
> Going back to my previous example, say your ebuild does the following:
>
> -- code begins here --
>
> inherit foo bar
>
> # Foo and bar both have src_unpack and src_install functions.
> # we want foo's src_unpack and bar's src_install:
>
> ECLASS_PHASES="foo_src_unpack
> bar_src_install"
>
> -- code ends here ---
>
> If ECLASS_PHASES is undefined, I think the default should be to not run
> the eclass phase functions.
>
> Yes, this means there is some boilerplating. However, there are some
> strong advantages:
>
> - this is no longer dependent on order of inheritance.
> - The ebuild author knows exactly which eclass phase functions will
> be run.
>
>
This proposal, seems reasonable, given my comments. I anticipate however
its biggest downside would be
the requirement to state *all* the functions you want, which would lead to
maintenance headaches
due to people forgetting to declare they wanted some function or other.
So if you could sculpt it to be broader by default and have less scope for
developer error, that'd be an improvement.
--- code start --
ECLASS_EXCLUDE="foo_src_unpack bar_src_unpack"
inherit foo bar baz
--- code end ---
here, src_unpack would be baz_src_unpack *regardless* of composition order
because "foo" and "bar" were barred from being used, and baz took
precedence as a result.
If baz provides no src_unpack, then the ebuild in question is simply left
without one.
You'll still need to declare src_unpack explicitly if you need use
conditional behaviour, however.
--
Kent
*KENTNL* - https://metacpan.org/author/KENTNL
--001a11c3bf009f75d40500c6b590
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra">On 17 August 2014 09:54, Wi=
lliam Hubbs <span dir=3D"ltr"><<a href=3D"mailto:williamh@gentoo.org" ta=
rget=3D"_blank">williamh@gentoo.org</a>></span> wrote:<br><div class=3D"=
gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I strongly oppose this change, because I feel it will make our<br>
entire tree very unpredictable at best. I realize this might eliminate<br>
boilerplating from our tree. Weighing that against the possible<br>
ramifications in this big of a change in automagic behaviour, I think<br>
the cost is much higher than the gain.<br>
<br></blockquote><div><br><br></div><div>I agree on that part, for what its=
worth.<br><br>The current system we have in place is an analogue of "=
role based" or "trait based" inheritance, where you have ver=
y straight forward composition behavior with regards to the final ebuild.<b=
r>
<br></div><div>One of the parent classes "wins", and if you don&#=
39;t like this, you have to adapt it manually.<br><br></div><div>This in pr=
actice usually proves more useful than diamond style multiple inheritance, =
that while seeming like a nice idea in concept, in practice proves more com=
plicated than its worth.<br>
<br></div><div>The only downside I see is we don't have a clear straigh=
t forward collision strategy, which is essential for most role based system=
s:<br><br>For instance, <br><br></div><div>=C2=A0 dog.eclass : function bar=
k<br>
</div><div>=C2=A0 tree.eclass: function bark<br><br></div><div>Proves not t=
o be resolvable automatically in a sensible way.<br></div><div><br></div><d=
iv>Collison systems I've seen usually do one of two things:<br><br></di=
v>
<div>- In the event of a collision, demand the consumer resolve the problem=
by redefining the function the collision occurs on in terms of its composi=
te parts. ( which is basically what we already do )<br></div><div>- Declare=
syntax to "exclude" a potential collision from either composite =
part.<br>
<br></div><div>Our only real difference at present is unlike these systems,=
we assume we can simply guess which one wins and just choose it automatica=
lly, where collision systems tend to force you to deal with the situation i=
f any collision occurs.<br>
</div><div><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am also not very comfortable with our current state, because it has<br>
a lot of uncertainty in terms of how the eclass phase functions are<br>
called.<br>
<br>
My counter proposal to this is that we stop calling eclass phase<br>
functions automatically, and to minimize the amount of boilerplating<br>
=C2=A0 we would have to do, we use a variable, such as ECLASS_PHASES=C2=A0 =
which<br>
=C2=A0 would be defined at the ebuild level and contain a list of the eclas=
s<br>
=C2=A0 phase functions we want to run automatically.<br>
<br>
Going back to my previous example, say your ebuild does the following:<br>
<br>
-- code begins here --<br>
<br>
inherit foo bar<br>
<br>
# Foo and bar both have src_unpack and src_install functions.<br>
# we want foo's src_unpack and bar's src_install:<br>
<br>
ECLASS_PHASES=3D"foo_src_unpack<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bar_src_install"<br>
<br>
-- code ends here ---<br>
<br>
If ECLASS_PHASES is undefined, I think the default should be to not run<br>
the eclass phase functions.<br>
<br>
Yes, this means there is some boilerplating. However, there are some<br>
strong advantages:<br>
<br>
- this is no longer dependent on order of inheritance.<br>
- The ebuild author knows exactly which eclass phase functions will<br>
=C2=A0 be run.<br>
<br></blockquote><div><br></div><div>This proposal, seems reasonable, given=
my comments. I anticipate however its biggest downside would be<br></div><=
div>the requirement to state *all* the functions you want, which would lead=
to maintenance headaches<br>
</div><div>due to people forgetting to declare they wanted some function or=
other.<br><br></div><div>So if you could sculpt it to be broader by defaul=
t and have less scope for developer error, that'd be an improvement.<br=
>
<br></div><div>--- code start --<br></div>ECLASS_EXCLUDE=3D"foo_src_un=
pack bar_src_unpack"<br></div><div class=3D"gmail_quote">inherit foo b=
ar baz<br><br></div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote">
--- code end ---<br><br></div><div class=3D"gmail_quote">here, src_unpack w=
ould be baz_src_unpack *regardless* of composition order because "foo&=
quot; and "bar" were barred from being used, and baz took precede=
nce as a result.<br>
<br></div><div class=3D"gmail_quote">If baz provides no src_unpack, then th=
e ebuild in question is simply left without one.<br><br></div><div class=3D=
"gmail_quote">You'll still need to declare src_unpack explicitly if you=
need use conditional behaviour, however.<br>
</div>-- <br><div dir=3D"ltr"><div>Kent<font size=3D"1"><b> <br><br></b></f=
ont></div><div><span style=3D"color:rgb(204,204,204)"><font size=3D"1"><b>K=
ENTNL</b> - <a href=3D"https://metacpan.org/author/KENTNL" target=3D"_blank=
">https://metacpan.org/author/KENTNL</a></font></span><br>
</div><div><br></div></div>
</div></div>
--001a11c3bf009f75d40500c6b590--