Re: Too lazy for constructors

Adding more of a declarative nature to Perl's object model is an interesting thing to do. What problem does this solve? To me, one of the appeals of dynamic languages like Perl, Ruby, and Smalltalk is that they don't have rigid type systems. That is: if my object supports the desired operations, it has the right type, regardless of what its superclasses are. Although your solution at least doesn't require specific inheritance, it does differentiate between blessed objects and regular scalars. But what if I had a blessed object that overloads '+' and other numeric operations and I want to use it instead of an integer for age above? Your scheme doesn't check dynamic type, only static type. That is, why do we want age to be an integer? Because we have some preconditions? Because we're doing math with it? Why can't I substitute an object of my choice that supports the required behavior?

It does seem to me that you're trying to work around the major discrepancy in the Perl type system — not everything is an object. Maybe this solves real-world problems, I don't know. I guess it solves some problem you were having or you wouldn't have written it.

My own experience with Perl is that type errors are a rare source of bugs. Of course, I mostly use objects, but I rarely run into problems because of number/string distinctions. (Perhaps those dealing with relational databases would care more, but this hasn't been a problem for me, since I don't).

Comment on Re: Too lazy for constructors

Replies are listed 'Best First'.
Re: Re: Too lazy for constructors by mugwumpjism (Hermit) on Jul 18, 2001 at 19:34 UTC
That is, why do we want age to be an integer? Because we have some preconditions? Because we're doing math with it? No. Because I want to be able to store it in a finite amount of space. Type errors may be a rare source of bugs, but they're one of the nastiest to track down... especially if they've been allowed to propagate beyond their original source, corrupting other data structures and otherwise wreaking havoc. I can't help but say that I think strict type checking is *good*, if sometimes a pain in the ass. Adding "soft" type checking like this gives you the good points without the "pain in the ass" aspect of not being able to, say, quickly tag an object with an attribute in a debugger. ie, you can still get around it with $object->{attribute}, but $object->attribute will always be checked. `srand 3.14159; print join("", sort{rand 1<0.5}map{$_^"\037"}split m{ }x,"qmptk\|z~wOzm??l]pUqx^k?j"),",\n";` [download]	[reply] [d/l]

Replies are listed 'Best First'.

Re: Re: Too lazy for constructors
by mugwumpjism (Hermit) on Jul 18, 2001 at 19:34 UTC

That is, why do we want age to be an integer? Because we have some preconditions? Because we're doing math with it?

No. Because I want to be able to store it in a finite amount of space.

Type errors may be a rare source of bugs, but they're one of the nastiest to track down... especially if they've been allowed to propagate beyond their original source, corrupting other data structures and otherwise wreaking havoc.

I can't help but say that I think strict type checking is good, if sometimes a pain in the ass. Adding "soft" type checking like this gives you the good points without the "pain in the ass" aspect of not being able to, say, quickly tag an object with an attribute in a debugger. ie, you can still get around it with $object->{attribute}, but $object->attribute will always be checked.

srand 3.14159; print join("",
sort{rand 1<0.5}map{$_^"\037"}split m{
}x,"qmptk|z~wOzm??l]pUqx^k?j"),",\n";
[download]

[reply]
[d/l]