OpenEuphoria

1. ...so this override business

• Posted by petelomax Nov 19, 2014
• 2420 views

Not the newish keyword but the fundamental principle which existed long before it.

While "more flexible" and other platitudes might appease some people, is there any real need for it? The docs quite rightly do indeed say "would probably break code", so why, exactly, is it there at all?

In the name of all that is holy who in their right mind would override a builtin to adjust some third party code without modifying the source and without the original author's knowledge and expect it to work in the next release, so please don't go there.

When I see s = append(s,q) I would prefer to know instinctively exactly what it does, rather than harbour a nagging doubt at the back of my mind that someone has squirreled away an override in some dim corner that I haven't read yet. Even a one-click check on every keyword would soon add up to quite the extra effort. Is some much-needed refactoring going to switch silently to the original builtin instead of the override, or vice versa, and introduce some subtle bug? Is every line of code I add to anything not known inside out and backwards, potentially introducing a new bug, even if that exact same code works flawlessly everywhere else?

I think I have now convinced myself that it should, nay must, be banned, and trigger new compilation error messages.

Pete

3. Re: ...so this override business

• Posted by ghaberek (admin) Nov 20, 2014
• 2366 views

I like the override qualifier and make good use of it. My euadvlib uses it to provide extended functionality to c_func(), c_proc(), and peek_string() (all of which are built-in functions).

Take, for instance, the following code...

constant NULL = 0 
 
object x = peek_string( NULL ) 
printf( 1, "x = '%s'\n", {x} ) 

This doesn't even produce a useful crash. It just stops the interpreter dead in its tracks.

I bound this code to an executable and then profiled it with Dependency Walker, which displayed the following trace log...

This is pretty much what we expected: a memory access violation. I believe the interpreter should catch this and crash accordingly, but it currently does not.

The override qualifier allows us to correct this behavior quite simply...

 
include std/error.e 
 
constant NULL = 0 
 
override function peek_string( atom ptr ) 
    if ptr = NULL then 
        crash( "attempt to peek_string() on NULL pointer" ) 
    end if 
    return eu:peek_string( ptr ) 
end function 
 
object x = peek_string( NULL ) 
printf( 1, "x = '%s'\n", {x} ) 

C:\Euphoria\include\std\error.e:52 in procedure crash() 
attempt to peek_string() on NULL pointer 
 
... called from C:\Documents\Euphoria\Projects\Testing\peek_string.ex:8 in function peek_string() 
 
... called from C:\Documents\Euphoria\Projects\Testing\peek_string.ex:13 
 
--> See ex.err 
 
Warning { override }: 
    <0222>:: C:\Documents\Euphoria\Projects\Testing\peek_string.ex:6 - built-in routine peek_string() overridden 

Alternatively, my preferred method of handling this specific issue is to return an empty string instead of crashing. This is the behavior in euadvlib.

-Greg

5. Re: ...so this override business

• Posted by fizzpopsoft Nov 21, 2014
• 2265 views

@Pete
Greg has shown a legit override example, that is better than the builtin.
At least there is a display to show an override is in use, is that not sufficient?
Gregs alternate code may not be suitable for everyone though, so where does that leave us?
My 2c would be voting for allowed overrides but certainly the override warning should be kept.
IMHO the vast majority of non-internal Eu code is not commercial, not maintained by anyone but the single programmer.
Best practices don't need to be enforced, and would be a slight additional barrier to Euphoria take-up.
If that programmer wants to shoot himself in the foot, thats OK, its his problem.
If there is a post asking for help, and the override warning is evident, simply tell the requestor to use standards first?

Regards,
Alan

7. Re: ...so this override business

• Posted by _tom (admin) Nov 21, 2014
• 2207 views

Testing on Euphoria Interpreter v4.1.0 development Revision Date: 2014-01-16 02:53:44, Id: 5783:d41527402a7a

with warning 
 
print(1, 10 ) 
puts(1, '\n' ) 
 
atom print = 666 
? print 

The output is:

10 
666 

No need for "override" keyword, errors, or warnings.

Euphoria has been like this for a while.

_tom

9. Re: ...so this override business

• Posted by Shian_Lee Nov 22, 2014
• 2127 views

with warning 
 
print(1, 10 ) 
puts(1, '\n' ) 
 
atom print = 666 
? print 

10 
666 

I can confirm that although Euphoria allows me to behave like this - I have never allowed myself to use this option.

Maybe the fact that I used to code PLCs, leaded me to think about any single bit and method. In PLC, setting a single bit to TRUE may press hydraulic cylinder of 1000 tons, or worse then this.

Some other PLC programmers are more "brave" then me. But after seeing few accidents I don't take risks.

The only use I've made with override is with 'safe.e'. And I could live without it as well, by changing the code. I will never use it for anything else, and this kind of options makes Euphoria less safe actually.

I look at Euphoria as a programming language for the 'real life', not only for games and showoff. For real life applications, in industry for example, I don't need hidden traps. It's better to work harder, then to forget about some temporary override somewhere in the code.