Mail Archives: geda-user/2016/07/23/18:22:34
Roland Lutz <rlutz AT hedmen DOT org> writes:
> 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.
About the semantics of this feature, the only comment I ever received
was from John, who did not like some aspect of it.
> 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.
${NAME} is simple
Look how that evolved in make and bash. There is room for future
development ..
> 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:
That is syntax:
> - I'd suggest shortening the name of the attribute which defines a
> substitution from "parameter=" to "param=".
I do not like shortenings like this. The feature is not used often, and
the parameter= part is not normally visible.
parameter=
substitution=
Nice and readable.
> 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"
"show value only" shows everythinj after the first = in an attribute,
right? If you enhance gschem to have a separate switch for visibility
of the middle part, it could as well be a : separator.
> 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),
Use $NAME where appropriate, and ${NAME} or $(NAME) when required or
more readable
My use case looks like this:
value=$RFB
> 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).
in Makefiles, $A, ${A}, and $(A) are equivalent. Just like $*, ${*},
$(*). OTOH, $NAME == ${N}AME
> 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.
Thanks!
So there is to review and discuss
1. Semantics
When to apply the substitutions to what?
My patch applies the substitutions to all text objects of subsheets
after the hierachy has been built. This will pretty obviously fail
for source= attributes.
2. Syntax
I do not care much, but I will keep my own private patch with the
snytax I have used in the last few years.
- attribute name subst(itution) param(eter)
- separator : =
- parentheses $NAME ${NAME} $(NAME)
- extendability $(eval <expression>)
$(system <shellcommand>)
$(lookup key, <filename>)
3. Implementation
I am not familiar with the gnetlist code. I was looking for a hook to
attach the code to, found it, and implemented the substitutions in the
least intrusive way. There may be cases/attributes where the
substitutions do not work, because the attributes are used at
different times.
> Roland
--
Stephan
- Raw text -