[Libre-soc-dev] my current plan regarding simdsignal

[lkcl]

On October 22, 2021 5:46:06 PM UTC, lkcl 
>>To be clear, SimdSignal would always access its SimdScope through a
>>member
>>variable, specifically: self.shape.scope. 
>
>simply passing in the SimdScope as an argument to all SimdSignals, via
>the new function SimdScope.Signal, is sufficient.
>
>modifying SimdShape after-the-fact to add in scope? mmm... yyeah,
>honestly it doesn't matter how it gets there.
>
>(this will make sense when you read the comments / commits of a few
>hours ago)

as things stand, it is unnecessary to have SimdShape have a scope member variable, but if you would prefer that it have one please *do not* make it take the scope parameter in its constructor.

instead, use the exact same trick as i deployed by adding SimdScope.Signal(*args, **kwargs) calling
and returning SimdSignal(mask=self, *args, **kwargs)

or, have a function SimdShape.set_scope()

both of which when you think through, you will realise have limitations (that are solved by not having scope be a member of SimdShape at all).

limitation 1: SimdShapes (unnecessarily) absolutely and inappropriately have to be in a Context (with SimdScope).

limitation 2: intrusive modification of SimdShape by calling set_scope then prevents and prohibits its use elsewhere.

plus, as explained in the comments now in layout(), scope is scope and has nothing to do with shape which is shape.

*only the layout function* combines the Context (scope) with the shape, to create the required information that SimdSignal needs.

it therefore makes sense to keep scope entirely separate from shape, for multiple reasons.

l.