3 ms·

Besides reflection, do you have examples of this?

moron4hire 11y ago
Having done a lot of reflection in both JS and C# (well, .NET really, it's a library and runtime feature, not a language feature), I think I can confidently say that .NET is light years ahead of JS when it comes to reflection. I don't think I've seen a system better than .NET's. Because of the way it is built, you can still write type safe code. That's impossible to do in JS. I think people forget that, in JS, the types still exist. Just because it's not statically typed doesn't mean you don't have to think about types and what types are appropriate for given scenarios. With JS, it's impossible to tell just from inspecting a reference to a function what it expects from you and what you can expect to give back. You have the length property to tell you the number of arguments and that's it. Of course, that's assuming it's not using a variadric arguments pattern, in which case the length value only tells you the minimum number of parameters expected, but not that more are possible. Even if you can make reasonable assumption about the number of parameters, you won't be able to tell at all what types the function expects for those parameters. Want to list all the functions in a class that take two numbers and return a different number? Can't do it. But still, if you could make reasonable assumptions about the type of things that go in and out of the function, you won't know how to even call the function. Does the function expect to be called as a method of a class? Does it expect to be called as a static function? The best you can hope for is to toString the function and check if the source includes the word "this". Here's hoping it's one written in JS itself and not one that is implemented internally in the browser. Now before anyone says "why would you ever need anything like that?", it's an absolute necessity for building any sort of user-driven or data-driven reporting system. You need to be able to tell when your data set matches the functions you want to apply to them, at run-time, because the data isn't available at design-time. It's the classic reflection use case. As far as I'm concerned, safety-guaranteed reflection is impossible in JS, unless you throw away JS functions almost completely and create your own Functor class with all the extra type information that you would need.
- tracker1 11y ago
  Or you could, you know follow either a naming convention or a parameter convention... For that matter, you can have each method simply test the data and return null if it doesn't apply and the resolved value if it does, or any number of other patterns... For that matter, you can use an object stream, and pipe it all through to resolution. If your data comes from variant sources (spreadsheets, dirty xml, etc) then you are way better off with a scripted language. Try importing a WSDL that defines various interfaces to use "Object" and VS/.Net chokes on it. As far as users go, without the hard enforcements you can coerce values into either what you expect or cleanly drop out... unlike .Net where you have to go through the Try versions of convert, on who knows how many types in order to get something resembling predictable values... that doesn't even include regular expression syntax as a first class concept in JS. I've handled dynamic input sources from both .Net (VB.Net and C#) and I'll tell you that most of the time JS/Node is simply easier... I've replaced complex importers written in .Net with straight forward, easy to reason with JS importers that run in Node, and edit/run/deploy without a compile step. I will say that I do like that VB.Net has XML literals which can be very useful... but now that JSON is getting to be more common JS is less of a disconnect.
  - moron4hire 11y ago
    Naming conventions are a great way to end up with liar-code--code that isn't what it calls itself. Coercing user input into expected types is a good way to get exploits. Testing parameters explicitly is just asking for someone to forget a particular parameter, and just returning null instead of an error is how we end up with black-box functions that nobody can figure out why they get called in different places because they don't seem to have any particular use. WSDL is a different issue entirely; now you're talking about RPC (of which WSDL is just one format that .NET supports), which is not the same thing as reflection. The things you're talking about doing, they are bad software design.

Having done a lot of reflection in both JS and C# (well, .NET really, it's a library and runtime feature, not a language feature), I think I can confidently say that .NET is light years ahead of JS when it comes to reflection. I don't think I've seen a system better than .NET's. Because of the way it is built, you can still write type safe code. That's impossible to do in JS. I think people forget that, in JS, the types still exist. Just because it's not statically typed doesn't mean you don't have to think about types and what types are appropriate for given scenarios. With JS, it's impossible to tell just from inspecting a reference to a function what it expects from you and what you can expect to give back. You have the length property to tell you the number of arguments and that's it. Of course, that's assuming it's not using a variadric arguments pattern, in which case the length value only tells you the minimum number of parameters expected, but not that more are possible. Even if you can make reasonable assumption about the number of parameters, you won't be able to tell at all what types the function expects for those parameters. Want to list all the functions in a class that take two numbers and return a different number? Can't do it. But still, if you could make reasonable assumptions about the type of things that go in and out of the function, you won't know how to even call the function. Does the function expect to be called as a method of a class? Does it expect to be called as a static function? The best you can hope for is to toString the function and check if the source includes the word "this". Here's hoping it's one written in JS itself and not one that is implemented internally in the browser. Now before anyone says "why would you ever need anything like that?", it's an absolute necessity for building any sort of user-driven or data-driven reporting system. You need to be able to tell when your data set matches the functions you want to apply to them, at run-time, because the data isn't available at design-time. It's the classic reflection use case. As far as I'm concerned, safety-guaranteed reflection is impossible in JS, unless you throw away JS functions almost completely and create your own Functor class with all the extra type information that you would need.

tracker1 11y ago
Or you could, you know follow either a naming convention or a parameter convention... For that matter, you can have each method simply test the data and return null if it doesn't apply and the resolved value if it does, or any number of other patterns... For that matter, you can use an object stream, and pipe it all through to resolution. If your data comes from variant sources (spreadsheets, dirty xml, etc) then you are way better off with a scripted language. Try importing a WSDL that defines various interfaces to use "Object" and VS/.Net chokes on it. As far as users go, without the hard enforcements you can coerce values into either what you expect or cleanly drop out... unlike .Net where you have to go through the Try versions of convert, on who knows how many types in order to get something resembling predictable values... that doesn't even include regular expression syntax as a first class concept in JS. I've handled dynamic input sources from both .Net (VB.Net and C#) and I'll tell you that most of the time JS/Node is simply easier... I've replaced complex importers written in .Net with straight forward, easy to reason with JS importers that run in Node, and edit/run/deploy without a compile step. I will say that I do like that VB.Net has XML literals which can be very useful... but now that JSON is getting to be more common JS is less of a disconnect.
- moron4hire 11y ago
  Naming conventions are a great way to end up with liar-code--code that isn't what it calls itself. Coercing user input into expected types is a good way to get exploits. Testing parameters explicitly is just asking for someone to forget a particular parameter, and just returning null instead of an error is how we end up with black-box functions that nobody can figure out why they get called in different places because they don't seem to have any particular use. WSDL is a different issue entirely; now you're talking about RPC (of which WSDL is just one format that .NET supports), which is not the same thing as reflection. The things you're talking about doing, they are bad software design.