in reply to Fun with Typed Objects 1

You're right in that C# and Java have a lot of duplication in this case. It'd certainly be nice to have to type what I mean only once. Here's some food for thought, though.

A good type-inferring system can gather, at compile time, the type of $dog in this construct:

my $dog = Dog->new();

I'll probably write much, much more code that actually works with a Dog than code that instantiates a Dog. It seems more valuable to have the option to strictify your type checking these situations, where type inference really can't help: 

method bark_at (Dog $some_other_dog, $message)
{
    # horrible Perl6y pseudo-code
    print "$.name says to $some_other_dog.name, '$message'\n";
};

[download]

I wouldn't expect bark() to autoinstantiate a Dog object, but effectively it's declaring a lexical $some_other_dog that somehow conforms to Dog.

It'd also be weird to say: 

class DogShow
{
    my Dog @showdogs;
}

[download]

and fill an array with placeholder Dogs. I might want to throw a robot dog in there, or a Puppy, or something that's not specifically a Dog.

Replies are listed 'Best First'.
Re: Re: Fun with Typed Objects 1
by Elian (Parson) on Apr 02, 2003 at 20:47 UTC
    A good type-inferring system can gather, at compile time, the type of $dog in this construct:
    my $dog = Dog->new();
    No, no it can't. Alas. You have no idea how much I'd like that to be the case.

    It's perfectly valid to redefine, at runtime, Dog::new to return a Cat object. Or a FlatTire object.

    Good compile-time type inferencing with a language as dynamic as perl is very difficult.

[reply]

      Good point. Perl is rather different from type inferring languages, isn't it?

[reply]
        Only in the extent of its dynamism. Lots of the type inferencing techniques are usable, but with great care and some amount of tentativeness.
[reply]
Re: Re: Fun with Typed Objects 1
by simon.proctor (Vicar) on Apr 02, 2003 at 23:19 UTC
    Faced with the alternative I'm glad Perl isn't typed much (just scalars et al). Think about your snippets above for a bit and then be glad we don't have to worry about interfaces and up/down casting. Its because of this casting that we have so much verbosity in Java and C# in the first place.

    Imagine something like this: 
    my $skip = (Dog) Animal->new;
or
my Dog $skip = Animal->new;

    [download]
    I think you hit the nail on the head with your: 
    my Dog @showdogs;

    [download]
    After all. Java has had to use Object with its collections to keep them generic. This leaves it to the programmer to *know* what to cast to when fetching the contents. Imagine this in Perl: 
    foreach  my $dog(Dog @showdogs)
{
   print $dog->bark(),"\n";
}

    [download]
    Eeeew. However, on the flip side perhaps some kind of autotesting at debug run time to see if an object can do what you want would be nice. So when you do the following: 
    method bark_at ($some_other_dog, $message)

    [download]
    You can specify debug code to run that uses isa() and can() on the references of your choice to test that you are passing the right stuff around.

    However, I've only just thought of that and I don't know how valid or useful such an approach would be. What do you think? Example: 
    sub method bark_at ($some_other_dog, $message)
{
  if(DEBUG)
   {
      die "Not valid class" unless is_obj_instance("Dog", $some_other_
+dog);
   }
}

    [download]
    This function returning ok if the var is either an instance of Dog or can do all of Dogs methods. However, in this case its more like an assertation. You could then also create your own $! if you wished.

    I'm not convinced of the usefulness of this though.
[reply]
[d/l]
[select]
[reply]

In Section Meditations