background of the question: spurred by yesterdays irc discussion I thought through the remapped G0 example which came up there, and the M6 and M69 case
what I took from it was that it using the builtin behaviour and just draping a few lines around it might be a more common use case than defining a completely new code from scratch - like in the remapped M6 example Chris came up with: default M6 behaviour plus tool length touchoff plus G10 L2 I added M69 as an alias for M6 so it could be referred to in a G6 remap procedure, but it smells like a cludge - it litters the namespace and is non-obvious that brought me on the following idea: maybe it makes sense remapping *existing* codes behaves as follows: - when you remap an existing code, and, say, execute a replacement ngc procedure, - AND that replacement procedure refers to the code being remapped - then that 'inner' remapped code will always refer to the builtin semantics (*) (1) As it currently stands: REMAP=M6 ngc=foo.ngc o<foo> sub (wants to execute builtin M6 behaviour and then some) M69 (cludge: alias original M6 to M69) ... o<foo> endsub (2) After the change, you could do this: REMAP=M6 ngc=foo.ngc o<foo> sub (wants to execute builtin M6 behaviour and then some) M6 (refer to the code being remapped and get the builtin behaviour) ... o<foo> endsub ---- this strikes me as a more natural way to deal with it and reuse builtin functionality, and in that case I would see a use case to make many, if not all existing codes remappable -m (*) this case currently causes a remapping recursion with an error message, and therefore is an error situation. ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
