Re^5: use fields; # damnit

[stvn]

The syntax my Dog $brain declares that $brain is a Dog, and therefore everything that can be done with $brain has to be something that a Dog can do.

But then how come this works without error? (assuming that the method getCells is declared in Brain)

my Dog $brain = $dog->getBrain();
print $brain->getCells(); # prints 10 (see earlier example)

Are you just speaking theoretically? Or are you just refering to class fields and not methods? If that is so, then where is the real benefit in this? It seems I have to write code like this, to see any benefit.

print $brain->{cells};
# this prints:
# No such pseudo-hash field "cells" in variable $brain of type Dog at 
+test.pl line 48.

And to me that defeats so much of what makes OO good (yes I know I am being a purist, but hey, its my opinion).

These are compile-time tests on the container $brain.

There is no runtime check in Perl 5 about whether the value put into $brain actually is a Dog.

So what is it checking then at compile time, if it cannot see the value I put in there and know its wrong? Is is only checking the underlying "hash" and access to that?

after all nothing stops someone from making a class that inherits from both Dog and Brain!

So it does not check the @ISA at all then either? Hmmm.

Now I know that perl (like LISP, Python and others) is a more dynamic langauge than say Java, C# or even Ada95. And I know that to add something like "strong" typing would make much of what makes perl so cool just about impossible. But you don't need "strong" typing to get the benefits of type "safety". Type inference in Standard ML works just fine and IMO is superior to "strong" typing (and much simplier to use too). It seems to me that maybe fields and its accompanying technology is not finished yet, and if it is, then its not what I am looking for.

[tilly]

The latter works without error because Perl 5 understands that the Dog method may have methods added later, and so does not assume that accessing a currently missing method is bad.

In fact all that it understands are the fields of the object. So yes, it only checks hash access. And I agree with your comments about it not being very useful, which is why I personally don't bother with it.

As for where this idea will go, not very far in Perl 5. In Perl 6 it may mutate into something more useful. But so far all that I can recall is lots of thought, but not much that is concrete.

Incidentally I thought that type inference in Standard ML was a form of strong typing, but I don't know Standard ML. Since you appear to think otherwise, how would you describe the distinction that you'd draw?

[stvn]

Incidentally I thought that type inference in Standard ML was a form of strong typing, but I don't know Standard ML. Since you appear to think otherwise, how would you describe the distinction that you'd draw?

It all depends upon what you see as strong typing, maybe static typing is a better word for it. It is more specific.

My first experience with strong typeing was with Ada, which is probably one of the most draconian type systems out there. Which IMO is a good thing since Ada was intended to be used in things like missle guidance systems and is mostly used today in Aerospace (I think Boeing still uses Ada).

With Ada (and similar "staticaly" typed languages), you must strictly define your type and the scope of any polymorphism is limited. For a more common example, think of Java, there is no universally polymorphic type so the primatives like the int, string and array types are never compatible with others. If you want to be overly permissive with your types in a method argument, you declare the them of type Object. But before you really do anything with them you need to cast them to the proper type.

ML is not statically typed, you dont have to define it to use it, nor do you have to cast it when you do intend to use it. In your function arguments, you can either not define your type, or you can just define your type as 'a, which is sort of the universal polymorphic type. ML will figure it out for you (at compile time too) and give you the protection of type-safety. Dominus actually has a really good article which talks about this (start at slide 14), and does a much better job of explaining it than I really can.

I guess because typing is somewhat optional in ML, I don't view it as strong typing really. Again, maybe static is the better word for it.

... but I don't know Standard ML

You should give it a try, I actually think you in particular might like it. It may not be as practical as perl, but I think it is one of those languages which just the act of learning it can give you a lot of insight.

[adrianh]

I guess because typing is somewhat optional in ML, I don't view it as strong typing really. Again, maybe static is the better word for it.

I think you'll probably confuse a fair number of people :-) I've seen a number of definitions of strong/weak typing but ML would always come in on the strong side. The most common definitions I find are:

• Strong: The language knows what type something is (ML, Perl, etc.)
• Weak: You have to figure out what type something is (C, assembler, etc.)
• Static: We know what type something is at compile time (ML Eiffel, etc.)
• Dynamic: We know what type something is at run time (Perl, Ruby, etc.)

These certainly aren't universal (what I call "dynamic" above are often called "weak" too), but ML would always fall into the "strong" category.

The difference you're talking about (where the language figures out the type of something at compile time without you having to tell it all the time) I've seen called "inferred typing", which seems suitably descriptive.

[Aristotle]

But then how come this works without error? (assuming that the method getCells is declared in Brain)

What should happen if one of the classes has an AUTOLOAD? Also remember that you can add methods a class and remove them from it, at run time. You can even manipulate @ISA in all of your packages at runtime, completely changing your inheritance tree around at will. In fact, the inheritance tree is always manipulated on the fly, since there's no way to declaratively populate @ISA, even if that manipulation just so happens to commonly happen in implied BEGIN {} blocks.

It is impossible to make your scenario fail properly at compile time because Perl is simply too dynamic. Other similarly dynamic very high level languages have similar problems with such scenarios.