in reply to Griping about Typing

Typeless programming is great most of the time, but it can be a burning irritation as well. When the variables you are working with are malleable, like scalars, then you really don't care because of DWIM. When these scalars are actually object references, things can go all dark and blurry. 
my $bork = Bork->new();

my $x = $bork->bork()->bork();

[download]
Quick quiz: What type of thing is $x anyway? What methods can you call on it? One of the great things about C++ and other strongly typed languages is that you have to prepare a holder for the thing you are requesting. It would be a lot more like: 
Bork bork = new Bork();
Chef x = bork->bork()->bork();

[download]
No ambiguity there. Either you get a 'Chef', or you get a compile-time error.

With the coming Apocalypse, I only hope that there will be some sort of optional type checking mechanism that can backpropagate the request into the function itself, just like wantarray. Here's an idea: 
my Bork:$bork = Bork->new();
my Chef:$x = $bork->bork()->bork();

[download]
Maybe the bork method would be able to return a number of different things, including a 'Chef', based on some sort of if (wanta('Chef')) { ... } type check.

Sure, you can say name your variables properly according to type, perhaps using the so-called Hungarian notation, but this can get quickly out of hand. You can also check the return types explicitly in some sort of paranoid gesture, but these are run-time errors and not compile time, which is really tough to test in comparison.

Strict type checking, please, but only on request.

Replies are listed 'Best First'.
Re: Re: Griping about Typing
by pdcawley (Hermit) on Apr 19, 2002 at 07:04 UTC
    You can already document your intent 
        my $bork = Bork->new();
    my Chef $x = $bork->bork->bork;

    [download]
    Only trouble is (gee whizz!) I'm dreaming my life away.

    Ahem, back at the plot, the trouble is that perl will silently ignore your careful predeclaration and assign to $x even if ! $bork->bork->bork->isa('Chef'), which is a shame. use strict 'declarations' anyone? Implementation left as an exercise to the interested reader obviously. Me and C don't get on.

[reply]
[d/l]
      Okay, can anyone explain how that works? It actually parses, though the class is completely ignored, provided it is defined somewhere. Here's a quick example: 
      #!/usr/bin/perl -w

use strict;
use CGI;
use LWP;

my CGI $cgi = new CGI();      # Works
my XYZ $cgi = new CGI();      # "No such class XYZ ..."
my LWP $cgi = new CGI();      # Works, strangely enough

      [download]
      Nothing in the docs about that, at least under my.
[reply]
[d/l]
        It isn't quite ignored, but it only really does anything if you're using pseudo hashes and you've defined your the class using use fields, in which case, $CGI would be initialized as an arrayref with an appropriate hashref in the zeroth slot.
[reply]
        Perl records this information, but does nothing (or very little) with it. Because it is recorded, the typesafety.pm and types.pm modules are able to use it. This kind of core hooks for extensibility via modules is a recurring pattern in Perl: overload.pm can intercept the definitions of constants and turn them into objects; attributes.pm handles cases where tags like :foo appear after variables or sub definitions (in cases where the tag isn't one of the built ins like :lvalue, :method, or the depricated :shared). This feature, like attributes, went through growing pains. It is undocumented because it is still experimental - the details of how and when it is used are up in the air, even though some experimental modules are using it now.

        The short of it is, use types.pm and/or typesafety.pm. http://perldesignpatterns.com/?TypeSafety has an intro to the idea of type safety and details about the Perl implementations. It quotes this thread heavily =) I hope this answers your question.

        -scott
[reply]

In Section Meditations