-
Notifications
You must be signed in to change notification settings - Fork 240
- TypeUtil.IsStructImmutable() added, [JSImmutable] works with readonly/structs and more #516
base: master
Are you sure you want to change the base?
Conversation
…ly/immutable structs with member methods (no MemberwiseClone() anymore) - Exception.GetType() implemented - JSIL.Array.FindIndex()/Find()/ForEach()/ConvertAll() implemented via proxy (support typed arrays) - Builtins.IsFalsy/IsTruthy() explicit case to object in parameter - Configuration.EmitAttributes list introduced (minimizes .js output substantially) - JSIL.Meta.dll made strong named - Float and Double +/-Infinity added via proxy
@@ -539,6 +539,13 @@ JSIL.ImplementExternals( | |||
} | |||
); | |||
|
|||
$.Method({ Static: false, Public: true }, "GetType", | |||
new JSIL.MethodSignature(mscorlib.TypeRef("System.Type"), []), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The recently introduced MethodSignature.Return(T)
is appropriate for signatures like this when writing new code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How should I use it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MethodSignature.Return(T)
=== new JSIL.MethodSignature(T, [], [])
, but the instance is cached so memory usage is lower and invocation thunks are shared
Hi, This looks great, thanks for the contributions. I'm not willing to merge a strong name because of the various problems with strong names (especially given that I do not do binary/source compatibility versioning of JSIL assemblies). Given the fact that the actual contents of JSIL.Meta do not matter (just the attributes), I think it is not useful for it to have a strong name. If you have some further thoughts on this to explain why you think it's a worthwhile change, I'd be glad to hear them. |
Our project (WebGL engine) is split between assemblies (one of the assemblies is for example UnitTests). |
Are you sure you can't use InternalsVisibleTo without strong naming? Pretty sure that you can. |
…() methods - AssemblyTranslator TimeSpan.MaxValue debug section removed, it's still bug, somehow TimeSpan.MaxValue/MinValue are not initialized
You need to sign both assemblies, because effectively both assemblies reference each other. |
Ah, yes. Either both must be signed or both must be unsigned: |
Yes you right, InternalsVisibleTo() both can be NOT signed, it worked. |
Also, we have one more problem with JSIL.Meta now - it is not PCL assembly, so we cannot use it inside PCL projects (but really it will be easy enough to do it PCL). On other hand, it should be possible to insert sources of JSIL meta attributes in any users assembly, as JSIL checks them only by name (same way as you can insert Resharper meta attributes insise your own assembly to exclude references to Jetbrains assembly). |
One more question - maybe it will be better use meta attributes and proxies for specifying .Net attributes that should be dropped from JS output instead of using .jsilconfig for it. For sure, we should exclude attributes that marked with JSIgnore. |
Moving JSIL.Meta to PCL makes a lot of sense, we should definitely do that. I think I agree that filtering attributes should be done with JSIgnore as a baseline, that way any code that references a filtered attribute will generate 'reference to ignored type' instead of just mysteriously failing to find the attributes it's looking for. If you need strong names because you're deploying a strong named assembly, that's understandable, but in that case I would suggest either signing your build of JSIL.Meta (quite inconvenient, of course), or directly including the .cs files for the attributes you use (as @iskiselev pointed out, JSILc only checks by full name, not by assembly, so this will work fine.) |
I agree [JSIgnore] on attributes must drop it from JS output.
It will be nice to have an option to say which attributes to emit via REGEX (be default ALL of course). |
To clarify, my code only removed the .Attribute() reference, not the attributes definitions themselves and this results in reducing mscorlib.js substantially. |
JSProxy accepts a list of class names (check the overloads), so you'd just On Tue, Jun 3, 2014 at 4:30 AM, Daniel [email protected] wrote:
|
@dzeitlin, I really can't imagine why may I want don't include attribute in code, but still preserve it's definition. Even in cases, where I may want use this option - I need much more feature-rich config with not only options to preserve/exclude some attributes, but also with option to point members on which I should exclude such attributes. |
…type, very useful) - Don't define (DeclaringType) on skipped/ignored attributes - TypeUtil.IsStructImmutable(TypeReference type) is more robust, all fields are 'readonly' -> struct is immutable, (much faster than: typeInfo = TypeInfo.GetTypeInformation(type) + typeInfo.IsImmutable)
@iskiselev, @kg User defined ignored Attributes are skipped as well and not defined (saves another 4% from mscrolib.js output, now it's only 7048KB, originally was 9400 KB). Also I very recommend to introduce "T Verbatim.Expression < T >(string javascript)" see my commit, it simply saves the return cast in many cases, for example OnKeyUp(dynamic e): |
Also I'm going to introduce [JSChangeEnumToNumber] optional attribute on enums. Such enum will be converted to JS number, enum will be eliminated. Very usefull for example in GLenum case, has hundreds of enum values defined.
I already implemented and I will commit it tomorrow. Any ideas? |
I'm not sure I'm happy with the idea of dropping type system info from enums. We already drop too much info about numbers, so that will only make it worse. Have you explored the edge cases where that breaks down? How bad are they? |
- int? CodeGeneratorConfiguration.ChangeEnumToNumber added, values are: 0 - disabled, 1 - with attribute only, 2 - all enums - TypeUtil.IsEnum() enhanced to report about enums to number change - Enums changed to number (Int32) implemented: generic parameter, default(Tenum), $Cast()
As I mentioned I successfully implemented the [JSChangeEnumToNumber] attribute.
I handled and implemented:
The improvement is quite straight-forward, I enhanced the already known TypeUtil.IsEnum(type) : bool method, to return state of enum (keep it as is or convert to number). |
So I am ready to merge some but not all of the commits in here. We have two options: Multiple commits are fine, and multiple commits in related areas are usually fine, this is just too much disjoint stuff for me to merge unless I'm okay with all of it (and for me, ChangeEnumToNumber and the strong name and the list of attributes in the config are all things I'm not okay with merging into trunk, at least as-is) |
333b078
to
89e3560
Compare
mscorlib.js droped from 9400 KB to 7140 KB
use in jsilconfig like:
"CodeGenerator": {
"EmitAttributes": [
"NUnit.Framework"
]
}