The JScript Type System, Part One

Re:[HS Total] [Objet ou pas?] - Page 2 | hilpers

Re:[HS Total] [Objet ou pas?] - Page 2 | hilpers — Thu, 22 Jan 2009 19:15:31 GMT

PingBack from http://www.hilpers.fr/526142-hs-total-objet-ou-pas/2

RE: The JScript Type System, Part One

Isaac — Sat, 08 Nov 2003 05:21:00 GMT

Can we find a better forum for this discussion? >> They got rid of type restrictions > Except they didn't. Wasn't it clear from the context that "type restrictions" refered to type restrictions on variables? Ain't none of those in Smalltalk ;-) I'm a bit surprised that there's anything controversial about this - back in 1990, Justin Graver & Ralph Johnson were quite clear that "Smalltalk is untyped", see "A Type System for Smalltalk". http://citeseer.nj.nec.com/graver90type.html > Sending floogle to myVariable is a type error It might be if Dictionary was a type, but it isn't - it's a class. Implementation is inherited, specification is ignored (notably in Dictionary being a subclass of Set - see the paper). So "Sending floogle to myVariable" is just messageNotUnderstood ;-)

RE: The JScript Type System, Part One

Michael Feathers — Sat, 08 Nov 2003 01:19:00 GMT

>This kind of definition has been called misleading because languages >without typed variables do have values of different types. >OTOH being *untyped* is the easy explanation for why we have ad-hoc >polymorphism and loose-coupling in these languages. They got rid of type >restrictions - proud to be untyped and safe. Except they didn't. myVariable := Dictionary new. myVariable floggle. Sending floogle to myVariable is a type error, it is just one detected at run-time.

RE: The JScript Type System, Part One

Isaac — Sat, 08 Nov 2003 01:02:00 GMT

> It sounds like he is talking about variables, and that's fine Yes, the definition is in terms of the range of values that can be assigned to a variable. > but in some OO languages you don't have data variables, > you have references to objects The distinction between value types and reference types is unimportant to this definition. In a typed language we may restrict a variable to hold references to a particular type - such as POINTER TO ZipFile. In an untyped language we don't do that. > Now which is the variable? The object or the reference that holds it? > If you say it is the reference, then all references have the same type I'm unsure what you mean. Let's be more concrete (Smalltalk): | myVariable | myVariable := OrderedCollection new. Now myVariable holds a reference to an instance of OrderedCollection. myVariable := Dictionary new. Now myVariable holds a reference to an instance of Dictionary. myVariable is "the variable". Any value can be assigned to myVariable. The language is untyped. In some other language ArrayList myVariable = new ArrayList(); Now myVariable holds a reference to an instance of ArrayList. myVariable = new HashMap(); ***Fails - the range of values that myVariable may hold is restricted to references to ArrayList instances. The language is typed. This kind of definition has been called misleading because languages without typed variables do have values of different types. OTOH being *untyped* is the easy explanation for why we have ad-hoc polymorphism and loose-coupling in these languages. They got rid of type restrictions - proud to be untyped and safe. In that universe, "JScript Classic" would be untyped, and "JScript .NET" would be typed (presumably "untyped" variables are "restricted" to some universal type).

RE: The JScript Type System, Part One

Just some guy — Fri, 07 Nov 2003 23:11:00 GMT

Eric Lippert Writes: "I'm not following your train of thought here...if every member of X is a member of Y then X is a subset of Y. " Thank you for clearing me up. My confusion was in thinking that increasing the functionality in the subclass increases the values it can represent... like a TitledBorder with a Border superclass. I just assumed that the Border type does not include a border with a title, because it does not properly handle the title, ( has no operators for title) it shold not include values with titles.... only the TitledBorder type should include that valeu. But a TitledBorder also can handle a border with not title, as it is also a border. So I just assumed that TitledBorder will represnt a superset.. But as you note, the Border type should include borders that have titles. Even if it can not represent thoese titles properly. It just seemed silly that a border without a title is not a valid TitledBorder (or a zipfile without a manifes is a valid jar file).. but the reverse is ture, even though i have no way of representing/manipulating the title/manifest. But i see my fault. :)

RE: The JScript Type System, Part One

Curt Sampson — Fri, 07 Nov 2003 11:34:00 GMT

You seem to have confused the "set of possible values." With type systems here we're concerned about the number of possible values a variable can hold. A variable of type ZipFile can reference any ZipFile object, and any JarFile object. But a variable of type JarFile can reference only JarFile objects, not ZipFile objects that are not JarFile objects. Thus, a JarFile variable holds a subset of the values that can be held in a ZipFile variable.

RE: The JScript Type System, Part One

Eric Lippert — Fri, 07 Nov 2003 09:20:00 GMT

> You describe a subtype in terms of a subset of the possible values of a super type. But in practice (in most all exaples I have seen , in textbooks and so forth) the opposite is true > For example the class java.util.zip.JarFile extends java.util.zip.ZipFile, but it represents both a zip file AND a jar file, so clearly it's set of possible values is larger. If JarFile is a subtype of ZipFile then every instance of JarFile is also an instance of ZipFile. But that's the definition of "subset" -- if every member of X is a member of Y then X is a subset of Y. Therefore, I'm not following your train of thought here. The set of all objects that are ZipFiles contains all JarFiles plus all the non-JarFile instances of ZipFiles, so how could JarFiles be a larger set?

RE: The JScript Type System, Part One

Michael Feathers — Fri, 07 Nov 2003 08:12:00 GMT

>It's unclear to me why we cannot work with the terms defined by Luca >Cardelli (in Handbook of Computer Science and Engineering, Chapter 103. >CRC Press, 1997; http://citeseer.nj.nec.com/cardelli97type.html >typed (untyped) >"A program variable can assume a range of values during the execution of a >program. An upper bound of such a range is called a type of the variable. >Languages that do not restrict the range of variables are called untyped >languages." It sounds like he is talking about variables, and that's fine, but in some OO languages you don't have data variables, you have references to objects. Calling languages like these untyped doesn't make much sense because the objects themselves obviously have types. In other words, the languages features are at a level of abstraction where that definition isn't very relevant. Another example. In some languages you don't have to be particularly concerned if you attempt to increment an integer beyond its range. The object adjusts its range dynamically. Now which is the variable? The object or the reference that holds it? If you say it is the reference, then all references have the same type, but if you say it is the object, well, what is its type really? And, do you ever assign an object to another? In many OO languages you can't you can only assign references.

RE: The JScript Type System, Part One

Michael Feathers — Fri, 07 Nov 2003 08:11:00 GMT

RE: The JScript Type System, Part One

Just some guy — Fri, 07 Nov 2003 04:20:00 GMT

You describe a subtype in terms of a subset of the possible values of a super type. But in practice (in most all exaples I have seen , in textbooks and so forth) the opposite is true... This convention is also enforced by some language rules (which I will get to). For example the class java.util.zip.JarFile extends java.util.zip.ZipFile, but it represents both a zip file AND a jar file, so clearly it's set of possible values is larger. But it is also a subtype of ZipFile.... how can this be? does it violate the rules of subtypeing? and if it did, why does the compiler not reject it? Because most all languges have subtypes inheret attributes of the supertpe, it is easy for developers to make these kinds of mistakes.