Improve JMP Compiler Context-Awareness

[ErraticAttack]

What inspired this wish list request? Messages sent to the log can be slow and also confusing to users

What is the improvement you would like to see? Don't swamp the log with useless messages

Why is this idea important? It's more of a nuisance, really.

Consider the following JSL -- I am attaching a function to the name "print" within a custom namespace.

New Namespace( "This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!" );

"This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!":print = Function( {},
	Print( "Why does JMP think I am trying to overwrite a Builtin???" )
)

Why do I get this warning?  I am not trying to overwrite a Builtin.  I know that I am putting the name within a namespace and that is the way that I will be accessing the value held by that name.

Can the JMP compiler be aware of when the name is within a namespace and not send these messages to the log?  I use namespaces to create custom classes, so whenever a new instance is created it will spam the log with these superfluous messages.

[SamGardner]

Thanks for the input.  We want to let the user know when they are potentially overwriting a core JMP function.  I can see how this might be annoying for a more expert user.  We will share this with our development team and see if we can provide a way to suppress warning messages like this.   The challenge will be how to determine which warning messages should or could be suppressed.  

I suppose if you were defining functions like this over and over again it could cause the log to be filled up.  How often are you seeing this happen in your scripts and the associated log files?  Also, defining the function differently would prevent this sort of message in the log, e.g.

"test namespace":customprint=Function({}, "will  this print?");

[ErraticAttack]

Thanks for your response -- it's not too much of a nuisance -- it's when the AddinLoad runs and my classes initialize -- I've switched the instance generators to use the below method to avoid having it put these messages in the log for every new instance.

So, if it something that is easily done on your part that would be quite nice, but by no means is it a high priority.

new namespace( "test",
	{
		print = Function( {},
			show( "test" )
		)
	}
);

"test":print;

[Craige_Hales]

I believe this is a better workaround:

x=New Namespace( "This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!" );


x["print"] = Function( {},
	Print( "hello 1" )
);
"This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!":print(); // hello 1
// or 
y=namespace("This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!");
y["print"] = Function( {},
	Print( "hello 2" )
);
"This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!":print(); // hello 2
// or
namespace("This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!")["print"] = Function( {},
	Print( "hello 3" )
);
"This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!":print(); // hello 3
x:print(); // hello 3
y:print(); // hello 3

// the above is to work around the log message from variations on this:
x:print = Function( {},
	Print( "hello 4" )
); 
/*
The user-defined function "Print" conflicts with the JMP function "Print". 
Use a scoped reference (for example, Global:Print or Here:Print) to call 
your user-defined function. Other uses of "Print" in your script source 
will continue to call the JMP function.
*/
// which actually works...
"This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!":print(); // hello 4
// logcapture() is a less pretty way to make the message go away.

// The associative array style assignment prevents JMP from looking up the "print"
// name in the usual way. 

// shownamespaces(); // there is only one; x and y are alternate ways to use it

I don't like adding assignment statements (other than simple constants) in the NewNameSpace list of arguments because they are kept as expressions that still need to be evaluated. So, in your example, print is an expression holding the function's definition and is re-evaluated into the actual function on each use, before the actual function can run. It does accomplish your goal because it never creates a variable named print that holds a function...just an expression that evaluates to a function.

z = New Namespace(
	"z",
	f = If( Is Missing( Beep() ), // this is evaluated later, on each access
		1,
		2
	)
);

z:f; // beep!

I agree, the current message should not happen for this case; I hope it gets fixed.