[Pas2js] Random bugs and observations

[Ryan Joseph]

> On May 11, 2018, at 3:16 PM, Michael Van Canneyt <michael at freepascal.org> wrote:
> 
> 
> 
> On Fri, 11 May 2018, Ryan Joseph wrote:
> 
>> This has to with a myriad of type casting problems between pascal strings/arrays that should be addressed. Already after a few dozen lines of code I’m getting trapped between using pascal or JS types. At the moment using Pascal types is nice because they’re familiar and type safe but they’re missing features that exist in the JS types and require frequent types casts if they work at all.
> 
> The people at TMS Software have created a complete VCL set of widgets. We're talking a codebase of half a million to a million lines or so.

Not familiar but they didn’t used JS? The problem for Pascal is we have an option between JSString or Pascal strings and they conflict with each other.

> 
> They have not complained about this, so currently I am inclined to think the problems
> you experience are specific to what you attempt to do: WebGL programming,
> which is a bit of a special topic even in the browser.

What do you make of this? gl.getShaderInfoLog gives me a JSString like all other libraries will. I want to Pascal strings in Pascal instead of TJSString.new but now I need to make overloads. At least JSString needs to cast to string right? At the moment I had to make an overload or decide to use either Pascal strings OR JSString.

Fatal(’some error’);

Fatal(gl.getShaderInfoLog(shader)); // gl.getShaderInfoLog returns JSString

procedure Fatal (messageString: string); overload;
begin
	writeln('*** FATAL: ', messageString);
end;

procedure Fatal (messageString: TJSString); overload;
begin
	writeln('*** FATAL: ', messageString);
end;

> 
>>>> 4) JSArray really needs to be a “toll free bridge” to Pascal arrays.
>>>> 	- Any JS function that takes JSArray as an argument should accept Pascal dynamic arrays. JS would accept any array so why are we type casting from Pascal if we use array of xxx instead of JSArray?
>>>> 	- If we use JSArray then we need to cast for for..in to work right? That’s not very good obviously.
>>>> 	- Pascal dynamic arrays should probably have JSArray functions built-in since they are aliases for JSArrays anyways. It’s actually a feature of Pascal that we can do “array of integer” and get an error if we attempt to push a non-integer value to the array so we should take advantage of that.
>>> There is no short answer.
>> 
>> See above. This should be properly addressed.
> 
> Maybe.
> 
> I am not yet convinced that the statement
> "JSArray really needs to be a “toll free bridge” to Pascal arrays"
> is correct or desirable.

In my very limited experience it’s been the case that any function that takes a JSArray could take any Pascal array, however a Pascal array couldn’t take any JSArray. It’s more of a one way interchangeability. It seems easy to predict that we’re going to be type casting literally every single Pascal array without exception to every JS function to takes an array parameter. Right? it’s basically implied a Pascal array is a type cast when passed to JS functions.

> 
> I am in agreement that some methods should be applicable to arrays (using
> type helpers). But saying that they should be - in essence - interchangeable: I don't think so. A TJSArray can contain anything. A pascal array not: only
> elements of the array element type can exist. a Javascript array can contain
> integers, numbes, null, undefined, objects. So no, this is not
> interchangeable.
> 
> Forcing you to typecast from time to time makes it clear to you.

Sure enough. Consider the idea of a one way implied cast though unless I’m wrong about JSArrays being able to take any Pascal array.

> 
> 
>>>> 5) should string and TJSString by toll free bridged also? I’m already having type casting problems using Pascal strings and passing to JS functions even though they are the same type internally. String concatenation between the types doesn’t seem to work either which doesn’t seem right.
>>> typeof(new String()) === 'object’'
>> 
>> I don’t follow. Both “string” and TJString are the same type in the final output so they should be interchangeable. I can’t concatenate strings and numbers like JS can do. Is that a bug?
> 
> That you cannot concatenate integers and strings is by design. Pascal is typesafe, after all.

Fair enough. We need IntToStr to work then. I wanted to append an error integer to a message string and couldn’t figure out how to make that work.

> 
> We want your pascal to run in the browser. We do not want to pollute pascal with Javascript idiosyncrasies.

Agreed.

> 
> 
>> Already I had to make an overload of a function depending on what type I was using. I foresee this pattern being repeated over and over.
>> 
>> procedure Fatal (messageString: string); overload;
>> begin
>> 	writeln('*** FATAL: ', messageString);
>> 	exit;
>> end;
>> 
>> procedure Fatal (messageString: TJSString); overload;
>> begin
>> 	writeln('*** FATAL: ', messageString);
>> 	exit;
> 
> Same answer as for arrays.
> 
> 1. We plan to have type helpers which add the methods that exist in TJSString to string.
>  For these cases,  you will no longer need a TJSString typecast.

That would be very nice.

> 
> 2. Yes, you will still need to typecast a string to TJSString in some cases.
> 
>  A Pascal string is not fully interchangeable with TJSString.
>  a TJSString is immutable, a pascal string is not.
>  The need for a typecast makes this clear.

See above and let me know what the best solution is.



Regards,
	Ryan Joseph