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

Reply via email to