I would miss dynamic typing.

Post #28,627 by static 2/16/02 5:44:20 AM Reply	I would miss dynamic typing. That's one the features I most like in modern languages like Icon and PHP. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #28,645 by ben_tilly 2/16/02 11:08:12 AM Reply	Take your pick Which do you prefer. Dynamic typing. Or the ability to have multiple versions of the same library loaded at the same time without any conflict? That is why they made the decision that they did. OK, I understand that. I just think it is complete marketing BS to then claim that they are language agnostic. Cheers, Ben
Post #28,883 by static 2/19/02 12:25:30 AM Reply	Please, sir... Noted about the language agnostic rubbish. :-) But I don't understand why not supporting dynamic typing prevents the version management they want. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #28,887 by ben_tilly 2/19/02 2:50:14 AM Reply	Very simple With static typing you figure out at compile time what versions of everything you will call. That makes it easy to not get confused about different versions. With dynamic typing you need to make the decision at runtime. This quickly gets impossible. Consider the following case. A loads B which loads C. A also loads B' which loads C'. A method in A is then called which will call a constructor which might resolve to C or C'. With static typing you can be required to give enough information up front that the ambiguity can never arise. With dynamic typing you can't predict ahead of time that it won't arise, and what is a good resolution if it does? Cheers, Ben
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
Post #29,018 by static 2/20/02 12:32:47 AM Reply	Yes, it makes sense now. I'd forgotten the object-oriented approach C# requires (strike another for language agnosticism? :-). Thank you. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #30,432 by tablizer 3/1/02 11:15:38 PM Reply	Specify prefered libraries up front >> Consider the following case. A loads B which loads C. A also loads B' which loads C'. A method in A is then called which will call a constructor which might resolve to C or C'. With static typing you can be required to give enough information up front that the ambiguity can never arise. With dynamic typing you can't predict ahead of time .... << What about declaring the prefered libraries up front? If it needs a library not on the list, then it either requests it, like web plug-ins, or fails (depending upon configuration). The library list could also specify priorities by either its position in the list, or a "rank" field. If a specific thing needs a specific library version, then it can specifically request that one. If the specific version is not available, then perhaps it could try to use any newer version around (or fail depending on configuration). Static typing could face similar issues if the prefered library is not around. The developer should have the choice of it using an alternative rather than completely fail. Whether this feature is practical may depend on the environment. A lone user in Alaska may need more options than the cubicle next store. I too have grown to like dynamic typing (or no typing even). The code is more to-the-point than under static typing IMO. You see more business logic and less formality nitty gritty. ________________ oop.ismad.com

Welcome to IWETHEY!