References: <20121129152317.69585a4f@ncopa-desktop.alpinelinux.org> <C4453D93-B8C1-40E9-8DE2-21C595C9F6D1@yahoo.com> <20121129220245.3b7a6f9f@vostro>
In-Reply-To: <20121129220245.3b7a6f9f@vostro>
Precedence: list
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <080FA62F-A62B-46D8-8C64-0A91DF5F6C01@yahoo.com>
Cc: Natanael Copa <ncopa@alpinelinux.org>,
 Alpine ACF <acf@lists.alpinelinux.org>,
 Alpine Developers <alpine-devel@lists.alpinelinux.org>
From: Ted Trask <ttrask01@yahoo.com>
Subject: Re: [acf] Re: [alpine-devel] Ideas for a new config framework, ACF2
Date: Thu, 29 Nov 2012 16:13:51 -0500
To: Timo Teras <timo.teras@iki.fi>

On Nov 29, 2012, at 3:02 PM, Timo Teras <timo.teras@iki.fi> wrote:

> On Thu, 29 Nov 2012 10:57:48 -0500 Ted Trask <ttrask01@yahoo.com> wrote:
>=20
>> The proposed ACF2 seems to be a complete redesign to move from
>> functional to data-driven design. Unfortunately, the doc does not
>> give any reasons why this change is desired. What is the benefit?
>> This change does not address any of the goals listed below. Just as a
>> style preference, I've always been a C/functional design guy, rather
>> than C++/object-oriented guy. I find object-oriented design more
>> difficult to read and debug.
>=20
> I would recommend you trying one declarative language before condemning
> the programming paradigm.

I suppose I left myself open for that one. Note to self: never state style p=
references.

Please don't interpret a preference as condemning all other options.

> One practical example: there was recent changes in ACF on 2.4->2.5 - and
> I actually had to spend 8 hours fixing my two simple ACF modules because
> the core libraries got changed in ways that appear only imperative
> programming - problem which would not have appeared if ACF was
> declarative.

Sorry about that. Although I would blame it on iterative design and changing=
 requirements, which is a problem regardless of programming paradigm.

> There are valid reasons for both ways. But they are not just "style
> issues". Please try some declaritive language to see how they work.

Can you state some of the valid reasons for the ACF2 design?

Remember, my concern is not whether or not ACF2 can be done, but whether or n=
ot it is worth the "massive work" mentioned by ncopa. If I'm going to do "ma=
ssive work", I want to see some benefit. Changing programming paradigms does=
 not count as a benefit in my book.

Ted=


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---