Benjamin Goldberg <[EMAIL PROTECTED]> writes: >> Or, rather, it doesn't matter if we are or not, since >> perl, python, and ruby are all untyped so there's not much to be >> done, and full type inferencing's a halting-problem sort of thing. >> (Though a useful subset of many programs can be analyzed enough to do >> some optimization) > > If it's a halting-problem sort of thing, then how does smalltalk > work?
It doesn't do type inferencing. All messages are resolved at runtime by the class of the object receiving the message. Unless I've completely misunderstood what's going on. >> Reading or writing from the hash does a lookup in the backing database >> and reads or writes from it. A handy thing, with the variable getting in >> the way of reads or writes to itself. However, you can do this with >> plain scalar variables. >> >> For example, if you had code: >> >> int Foo; >> Dog Bar = new(); >> Foo = Bar; >> >> you wouldn't want there to be a Dog in Foo--you've declared it an >> integer, so it can only hold an integer. The assignment can't do a >> plain pointer copy the way it would in the case where both sides can >> hold objects. > > Indeed ... the compiler needs to detect that a conversion is necessary. > > Fortunatly, since we've told the compiler the types of the variables, it > can do that. How about this then: sub wibble($arg is rw) { $arg = Dog.new; } my int $foo; my Cat $bar; wibble(rand < 0.5 ?? $foo :: $bar); The compiler does not and cannot know the type of thing passed into wibble until runtime, so assignment must be handled by the target thing. Yes, this is a pathological case, but it is a case that must be handled. >> As an alternate example, try this: >> >> TempMeter kitchentemp = new('kitchenroom'); >> TempMeter bedroomtemp = new('bedroom'); >> bedroomtemp = kitchentemp; >> >> Where in this case kitchentemp *is* an object, but one of type >> TempMeter, and bound to an object that represents the temperature in >> your kitchen, while bedroomtemp is a TempMeter object that represents >> the temperature in your bedroom. (Code I'd not recommend using in CGI >> programs....) The assignment does *not* bind the bedroomtemp name to >> the object for the kitchen temp, rather it sets the bedroom >> temperature to be the same as that in the kitchen. Even being an >> object, the object's methods still intercept read and write requests >> and instead of assignment being rebinding, it's instead a get or set >> call on the object. > > Again, we've told the compiler the types, so it can do that. > >> The part that affects us is that we can't tell at compiletime whether >> assignment is rebinding or is a get/set, because we could have code >> like: >> >> kitchentemp = new('kitchenroom'); >> bedroomtemp = new('bedroom'); >> bedroomtemp = kitchentemp; >> >> which is typeless, > > Actually, we *could* try to infer the types of the variables, based > on our knowledge of the types of the values assigned to them. I'll > ignore that, and pretend that we don't know the return type of new() > at compile time. There's no pretending required. In the vast majority of cases you don't *know* the types returned by new. After all, something could have altered the behaviour of Class::new after the code in question is compiled but before it gets run. >> and yet should still respect the fact that the >> objects bound to the name intercept assignment (basically overloading >> it) rather than having the compiler or runtime doing the rebinding >> for you. >> >> Since, of course, we're dealing with basically typeless languages we >> have to do all the checking at runtime (lucky us) which is why the >> PMCs have generic get and set methods so they can decide whether >> we're doing rebinding or something more funky. (Whether this affects >> languages where = is an explicit binding rather than assignment is up >> in the air, but neither python nor ruby is truly that way, though >> they're close. But we can fake it so that things do what they ought >> when they ought) > > I forget, should "bedroomtemp = kitchentemp" be using set_pmc, or > clone? set_pmc