[Cuis-dev] [IMPROV] Bring back #break

[Juan Vuletich]

On 4/11/2023 1:39 PM, Gerald Klix via Cuis-dev wrote:
> Hi juan,
>
> You a right, I forgot to call the actual method,
> so it also missed its (side) effects, silly me.
>
> In nutshell the BDFL ruled:
>
>    1. #halt is enough and it should be used for debugging.
>    2. If there are sends of #halt in production code,
>       we just bail out (without a parachute).
>    3. If the aforementioned behavior is unwanted,
>       the developer is free to catch the Halt exception
>       and resume it.
>
> I can live with that.
>
> I will move the break-related code to a breakpoint-package
> yet to be written.
>
>
> Best Regards,
>
> Gerald

Hi Gerald,

I never intend to tell people how their dev environment or process 
should be. But we need to find a common ground on what goes in the base 
image.

I'd think that breakpoints, with your new BreakingMethodWrapper is the 
way to go for debugging. Many will keep using #halt, because we're used 
to it. Then #break is an alternative, optional way.

OTOH, I don't see much value in Halt being an exception. One way to 
avoid having three different implementations "for the same thing" could be:
- #halt exits Cuis if isDevelopmentEnvironmentPresent = false, but uses 
your #break mechanics if not. No longer an exception.
- #break is a nop if isDevelopmentEnvironmentPresent = false, but calls 
#halt otherwise.
- Breakpoints could perhaps call #break, to avoid duplicating code.

I think this would cover common cases, including your preference. It 
would also keep code duplication and "uninteresting for most" complexity 
to a minimum. It would make it impossible to do exception handlers for 
#halt, though.

Thoughts?

Thanks,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230411/8cca52cd/attachment.htm>