X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sat, 23 Jul 2016 22:56:19 +0200 (CEST)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Parameter substitution
In-Reply-To: <s6na8h843d4.fsf@blaulicht.dmz.brux>
Message-ID: <alpine.DEB.2.11.1607232216030.1399@nimbus>
References: <98D1C4E4-581D-4A03-94E4-E0330960EADF AT wellesley DOT edu> <s6na8h89ydi DOT fsf AT blaulicht DOT dmz DOT brux> <alpine DOT DEB DOT 2 DOT 11 DOT 1607231941050 DOT 16188 AT nimbus> <s6na8h843d4 DOT fsf AT blaulicht DOT dmz DOT brux>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-923931301-1469307063=:1399"
Content-ID: <alpine DOT DEB DOT 2 DOT 11 DOT 1607232255001 DOT 1606 AT nimbus>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-923931301-1469307063=:1399
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine DOT DEB DOT 2 DOT 11 DOT 1607232255002 DOT 1606 AT nimbus>

On Sat, 23 Jul 2016, Stephan Böttcher wrote:
> Roland Lutz <rlutz AT hedmen DOT org> writes:
>> I'd guess that, since that's quite a relevant change, the developers 
>> didn't want to just apply it without prior discussion.
>
> A discussion that never happend. :-(

So, let's discuss it now.

I think everyone on this list agrees that having parametric
subschematics would be a nice thing.  The easiest way to achieve this 
would be the way you implemented: simple substitution.  On the other end 
of the spectrum, the subschematic could contain complex logic which 
instantiates components algorithmically.

While this sounds great in theory (and may be fun to work on), I'd suggest 
to keep it simple for now and stick to the method both of us implemented. 
As to the semantic differences in our implementations:

- I'd suggest shortening the name of the attribute which defines a 
substitution from "parameter=" to "param=".  Components are probably going 
to have multiple instanes of them, each potentially being a long line, so 
there is no point in making the attribute name longer than necessary. 
I'd personally prefer calling the attribute "subst=" to indicate that it's 
a simple substitution (as opposed to a "real" parameter), but I wouldn't 
object "param=", either.

- I'd suggest using the character "=" to separate substitution name and 
value.  This way, the attributes can be set to "show value only" to show a 
neat list of substitutions for a given symbol.  (Using upper-case letters 
for substitution names and possibly a different color for the text objects 
would minimize the risk of mistaking them for regular attributes.)

- As to whether to use "$(NAME)" or "$NAME"/"${NAME}", I've mostly been 
following a gut instinct when going with "$(NAME)".  I've thought a bit 
about why "$NAME" feels wrong for me, and I think it's something about 
context: in places where you use "$NAME" (e.g., shell scripts), there's 
usually all kinds of substitutions going on, whereas in places where you 
use "$(NAME)" (e.g., Makefiles), it's usually the only kind of 
substitution (or other "$" sequences mean different, non-substitution 
things).  Therefore, I'd suggest using "$(NAME)".

I haven't had the time yet to look at your implementation in detail, but I 
hope I'll be able to do so in the next few days.

Roland

--8323329-923931301-1469307063=:1399--