Open davidedc opened 10 years ago
agree that this would be good to have, and pretty easy to implement.
I feel like matrixScope
has the right kind of name, but there's probably a clearer phrase for it.
matrixScope would work. Very technical though. How about "locally"?
locally 2 times rotate box
how does that sound/read?
There might be a chance of confusion with other things that have associated stacks that could be localised?
edit: but it seems to read quite well on the face of it.
indeed, Processing has 2 stacks (matrix and styles). On top of that, speaking about a hypothetic future, there could be something related to sound transforms, particles and palettes (particles and palettes have been tackled by cyrilcode.com and it'd be nice to take a look into that one day).
How about we get locally
to work on both the matrix and styles stack, we figure out the keywords for matrix-specific and style-specific stack, and we ignore the other potential future stacks?
Sounds sensible to me.
So I think we can actually close this issue now can't we? This feature is fully implemented and working really well. Unless there's other stuff we'd like to do?
I don't think we have a specific keyword yet for this specific thing I'm proposing. Yes we do have local transforms so we can achieve the same by saying:
rotate 0 // or move 0 or scale 1
5 times
rotate
box
otherCode // not affected by any of the rotates above
but I don't think we have a more coincise way like with a specific keyword. (Or do we?)
What about Reversing the order matrixPush or matrixPop that seems to make a bit more sense to me
@Richard-Mineall that's an idea. Although this particular issue is about something else, it's about inventing one keyword that runs a block of code with particular transformations and isolates the code after from those transformations... as in the examples above... (welcome to github by the way)
then how about Push and Pop, we could put it under a section in the demos and tutorials called Matrix
Feel free to open another Github issue about that so we don't confuse two things in this thread... (I think maybe Matrix sounds too technical as a menu entry. I'd call it "transformations" maybe.)
so I'm still not seeing why we might want keywords as well as having the block indentation. I think the keywords are also a bit tricky as we have block indentation working with colours as well, so any keywords chosen can't just be transformation specific.
unless we have multiple keywords I guess...
yeah we don't strictly need them for matrix transformations cause we can do:
scale 1 // kind of strange but it works
5 times
rotate
box
otherCode // not affected by any of the rotates above
although actually for other states (fills or strokes or strokeSizes) there is no equivalent...
aaahhh hang on I see, so actually the issue with the above code is a lack of scoping for these things within the times loops.
to be honest, that should be pretty easy to fix
should we scope state within the times loops though? And is that the only case where this would be needed?
I have two reasons against "times"-bound scoping.
1) I'm thinking about coding a "turtle graphics" extension tonight (I realised how neatly it would map to LCL and it would be fantastic for visualising what happens with the transformations). I like the mapping between LCL and Logo, but in Logo "repeat" doesn't limit scope of transformations (with great visual results). So we either add a "repeat" that achieves the same (which could be OK but it's sort of difficult to explain why we have two looping statements at that point)... or we don't scope "times".
2) it would leave open the question "what do we scope". Everything? stroke thickness, stroke color, fill color, and world matrix? That seems a lot... If we pick a subset of the state, then what's the reasoning?
that seems like fair reasoning not to do it. I think the issue then is just defining how we think it should work, and then making the languages work the same way.
so, if we have
4 times
rotate
box
peg
The expectation is that the peg would be rotated 4 times?
correct. As a recap, if that's not desired, one can write:
4 times
rotate
box // 4 exactly overlapping boxes, contrarily to original source
peg
or
scale 1 // or move 0
4 times
rotate
box
peg
or
TheKeywordWeAreLookingFor
4 times
rotate
box
peg
that all makes sense to me. I guess my next inquiry would be how the following should work?
4 times
red
rotate
box
peg
and
TheKeywordWeAreLookingFor
4 times
red
rotate
box
peg
I quite like the idea of having a keyword that works with the block scoping, but will block scope everything, colours, line thickness, rotations and all.
thoughts?
So far we have two proposals to only scope the world matrix:
and I throw-in now:
We have no proposals for other aspects of the context like stroke size, stroke color, fill.
maybe withMatrix is growing on me. It's technical (but this looks like a keyword not needed by beginners?) but at least is specific...
instead of doing
we could use a special notation, something like the (with-state) of Fluxus
.
You'd think that this is never needed given we already expose matrix operations that are block-scoped (I thought so) but actually take this example (found looking at https://github.com/xinaesthete/livecodelab/commit/a532582b8d5b18ba2853a5bc3c3db094e068ba39#diff-568408f5e3594dce731522f377b2ac5aR87 ):
this is a case when such command would be useful.
Any suggestIons for the name? just 'pushMatrix'? Would that be confusing?