MOTE: on the subject of abort()

[wolph42]

I've started testing MOTE and I noticed that there was a fundamental change in abort

What they did (intentionally or not) is abort now aborts the current macro and NOT the entire macro chain. So if you call e.g. call macro B inside macro A and macro B contains an abort(0) then the entire chain stops there and then.
In mote however it only stops macro B and returns to macro A.

Upside: Essentially this is great, cause this is how you would expect it to work
Downside: it will basically break EVERY framework out there. So there is a HUGE compatibility issue here.

I personally am in favour of the new functionality, but it *does* mean a LOT of work to make both the Bag of Tricks and my Framework compatible once again. AND it means that all the existing frameworks require a make-over.

What do you say??

edit: metatheurgist mentioned something that was already (in a different form) in the back of my mind:
add a third option:
-1 : terminate current scope and leave the rest as it was. That is abort(0) terminates chain and abort( !(0||1) ) continues.
("!" = NOT ; || = OR)

Note that this change will ALSO break some frameworks as abort(something) is often used to check is 'something' == 0 and if so aborts and in all other cases (thus also -1) continue...!

[metatheurgist]

Doesn't abort() take a parameter? I'd think the obvious solution would be:

abort(0) - no action
abort(1) - entire chain
abort(2) - current scope

Most implementations of abort would be abort(x), where x=1 I'd think.

[wolph42]

Doesn't abort() take a parameter? I'd think the obvious solution would be:

abort(0) - no action
abort(1) - entire chain
abort(2) - current scope

Most implementations of abort would be abort(x), where x=1 I'd think.

currently abort(0) aborts everything and abort(!0) ("!"=NOT) continues, your suggestion would change things round which would be even more disastrous. I do however had similar thoughts but then of a less disastrous kind:

leave current funcitonality, which is:
abort(0) - stop entire chain
abort( !(0||1) ) - continue
and add:
abort(-1) - stop current scope

but this too would break some frameworks. For one I *know* I sometimes use abort for 'value' or '0', where 'value' can be anything not equal to 0, thus also -1. But maybe its the best way to do it.

[Full Bleed]

They should not mess with how abort() is currently set up. It is too heavily used in current frameworks. There is no reason to break compatibility for this function.

If they want additional or changed functionality (and I like the additional functionality mentioned) they should create a new abort function.


Edit: Couldn't they just add a new parameter to assert() for scope?

[Jagged]

I like the idea of the function, I can see the need for it. In fact I would have liked to have had this option just the over day.

I wonder whether the issue could be better served IF macro.return worked like a return statement?

[wolph42]

They should not mess with how abort() is currently set up. It is too heavily used in current frameworks. There is no reason to break compatibility for this function.

If they want additional or changed functionality (and I like the additional functionality mentioned) they should create a new abort function.


Edit: Couldn't they just add a new parameter to assert() for scope?

well the initial reply I got is that they revert it to its original working. They'll think about what next. good idea though to just create a seperate function!!

[CoveredInFish]

I think a new function is best, but could live with option 3 (it has a small problem that -1 is also !=0, so it DOES change current behaviour=compatibility.)

You could also add an optional second parameter that defaults to original mode if not specified.

[wolph42]

yeah I like the new function best so far. Probly something for the todo list at the bottom.

[Jack of Spades]

I understand the backwards compatibility issues, but I'd probably replace all my abort()s with a new function, if available. I keep wanting to return from macros early but ending up trapped inside one of the precious if levels.

[Jagged]

I keep wanting to return from macros early but ending up trapped inside one of the precious if levels.

Ditto. This is why I wish macro.return worked like a return statement