Mail Archives: geda-user/2016/07/23/16:58:03
  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--
- Raw text -