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