Versions peresnt during packaging?

Post #28,909 by Arkadiy 2/19/02 10:02:52 AM Reply	Versions peresnt during packaging? Could we just assume that versions present when the package was created are the ones we need? A bit of a hack, but would work, I think.
Post #28,927 by ben_tilly 2/19/02 11:43:41 AM Reply	No With static typing you have to declare types at compile time from ones you have available to you. No ambiguity is possible. With dynamic typing at compile time you may have multiple versions of the same library and no way to know that a given module will ever call that library. This is ambiguity that cannot be detected then, and cannot be adequately resolved at runtime. Oh, you can declare a rule for resolving it, such as "last one linked wins". But now if someone you link later decides to link in your library, you get hosed. This is dll hell sneaking back in the back door. Cheers, Ben
Post #28,932 by neelk 2/19/02 12:11:24 PM Reply	To do library versioning dynamically... ...you need a feature called selector namespaces. Dave Simmons' Smallscript language has had them for a few years, but it's being added to the new Javascript 2.0 standard as well. You can find Waldemar Horwat's LL1 presentation on it at: [link\|http://ll1.mit.edu/horwat.ppt\|[link\|http://ll1.mit.edu/horwat.ppt\|http://ll1.mit.edu/horwat.ppt]] Here's the rationale from the JS 2.0 spec: [link\|http://www.mozilla.org/js/language/js20/rationale/versioning.html\|[link\|http://www.mozilla.org/js/language/js20/rationale/versioning.html\|http://www.mozilla....sioning.html]] Incidentally, I met Waldemar Horwat, and discovered how he is managing the Javascript standardization effort. He wrote a formal semantics for JS, and then wrote a program that uses the semantics as an interpreter. Then, whenever someone requests a new feature, he adds it and reports the problems and inconsistencies it causes. Apparently this quells a lot of the bogus feature-creep pressure. This is the most cynically pragmatic use of formal methods I've ever seen, and is IMO totally brilliant. :) (He also automatically generates the standard from the formal semantics, too!) I think Javascript 2.0 stands a very good chance of becoming a language I can actually respect -- the people designing it are doing an excellent job so far. It's more complex than I like, but still remarkably clean.
Post #29,035 by ben_tilly 2/20/02 6:54:05 AM Reply	Huh, interesting That approach does help. I don't think it is usable for what .NET wants to do, but it is an interesting approach. Why not usable? Well two cases. The first is that library authors sometimes make backwards incompatible changes. A functions behaviour changes from one release to the next. Now just knowing that you have only the right functions is not enough, you also want to be sure you have the right implementation. (I think this is a freedom which, once it is available, many library authors will want to take advantage of.) The second case is more extreme. .NET will protect you against the situation where two people independently decided to write CoolModule and they independently created functions with the same names (like new) that do somewhat different things. Now no amount of internal management within the module will get things right since the authors cannot (not knowing of each other) cooperate. For their goal, I think that .NET made the only reasonable technical decision. I am ambivalent about the goal, and hostile to their mismarketing of the result, but I don't see a better answer within that framework. Cheers, Ben

Welcome to IWETHEY!