Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 11, 2013
- 1392 views
By itself, from the 4ft pov, true, no error as Euphoria is now. But Euphoria still put two sleeps into the same namespace, and it had to include both sleeps in the run code, because of routine_id() being called. In this example, neither sleep is namespaced.
Actually, that depends on the contents of sleep.e - which isn't either a 3.1 or 4.0 include file.
I had previously said, in reponce to a post by you in this thread:
So if i write an include with a sleep proceedure in it, and then i include it and misc.e, no error should be thrown? This should not be a problem?
Well, I suppose it depends on the contents of that include.
Had i included os.e also, there'd be 3 sleep()s in the same namespace,
Actually, the one in os.e would be in os.e's default namespace.
It's also in "no namespace", you can call it without specifying os:sleep.
Good point. Perhaps, in the case where there's a routine with a namespace and a routine without one, routine_id() should choose the routine without the namespace.
and the program would happily begin running and not crash untill the program executed a routine_id(sleep), maybe hours later, with data loss. Come on Matt, surely Euphoria can be smarter than that.
It would not, as currently, routine_id(sleep) (assuming sleep is a variable containing the string "sleep") returns -1 instead of crashing. No crash, no data loss.
Only if i always wrote code to catch the -1 returned from routine_id() (even when i KNOW there is a procedure of the name i am routine_id'ing), which to me is like saying "i know Eu is going to overlook an ambiguous situation at compile time and crash during runtime...". So i suggest AGAIN that Euphoria alert of the ambiguilty before it runs instead of wasting all the runtime before the inevitable crash. It's not terribly reasonable to read the entirety of every include file and compare to every other include file, to check for duplicates procedure names, and not even Euphoria is alerting to this happening until that name is called in the program during runtime.
That's a good point. Adding better lint-type help is always a good idea imvho. I think this makes sense as a warning emitted by eui -test.
