Re^3: Being more Assert-ive with Perl

in reply to Re^2: Being more Assert-ive with Perl
in thread Being more Assert-ive with Perl

>> It's much less verbose than what you're doing,...

> Personally I don't see that. I have looked at Params::Validate before, and I didn't much care for it's style of parameter handling.

When you're validating only one parameter, the framework takes up more space than the declarative parts. But as you start adding more parameters the framework pieces grow at a much slower rate than the declarative parts. But with your code, you'll be adding another "or die" for each parameter.

Anyway, I don't think you have to use it, but I think your optimizations here are seriously premature. You should be using some sort of module for this stuff, not hand-coding it over and over and over, especially since you say you use it everywhere. You could use a source filter if you're really dead set on maximum speed.

Comment on Re^3: Being more Assert-ive with Perl

Replies are listed 'Best First'.
Re^4: Being more Assert-ive with Perl by stvn (Monsignor) on Sep 19, 2004 at 20:08 UTC
But as you start adding more parameters the framework pieces grow at a much slower rate than the declarative parts. But with your code, you'll be adding another "or die" for each parameter. I agree with you there, and I can see where this will happen if you are validating a large number of parameters coming in from say a web request or something like that. At that point, something like Params::Validate is the superior solution. However, when I speak of pre/post-conditions I am really talking about checks on arguments for methods in classes. IMO it is good style to not have more than few (2-3 tops) parameters for methods. Any more parameters, and it is likely that you need to either subclass or be more polymorphic. Validating a few (2-3) parameters with `\|\| die` is not a problem, and can even be done in a single line if you want. Anyway, I don't think you have to use it, but I think your optimizations here are seriously premature. But they are not optimizations, but instead using the optimial approach. As I said in another post here, why would you not want to use the sharpest knife in the drawer? I see this style of assertions as being easy to read and understand, and having the added benefit of also being fast too. If I was going to build an application, and needed a module which had a pure perl version and an XS version, I would choose the XS version because it just makes sense (assuming of course they were reasonably equivalent). You should be using some sort of module for this stuff, not hand-coding it over and over and over, especially since you say you use it everywhere. Why should I use a module for this? It is not something that IMO needs to be in a module, and any module I would write would still require me to declare my conditions which is the bulk of what I am doing with this approach anyway. I agree that with a large number of parameters, each of which have specific validation needs, something like Params::Validate is the way to go, but surely you would agree that it would be overkill for just testing if an argument is defined and of a specific type? (which is the majority of what I use this for) Modularity is a great concept, but like all good ideas, it can be overused or just badly used. There is a time and place for a module, and there is a time and place for a good solid idiom. I think that (simple) pre/post-condition checking of method/function arguments is be done with an idiomatic approach rather than trying to abstract and modularize a general purpose approach which will almost surely never be optimal in all situations. You could use a source filter if you're really dead set on maximum speed. First of all getting even midly complex source filters right is difficult at best and impossible at worst, otherwise you would see some kind of full blown perl macro system out there. Perl is just very hard to parse, and doesn't lend itself well to things like this. Source filters are not a way to increase relability and robustness, they are a way to introduce subtle and insidious bugs. Second, I am not dead set on speed. I am dead set of building robust and reliable modules which break in all the right places. And in order to achieve that I would like not to have to sacrifice speed (subroutine calls) and memory (module loading). I would like the users of my modules not to have to deal with the consequences of my descisions/trade-offs. -stvn	[reply] [d/l]

Replies are listed 'Best First'.

Re^4: Being more Assert-ive with Perl
by stvn (Monsignor) on Sep 19, 2004 at 20:08 UTC

But as you start adding more parameters the framework pieces grow at a much slower rate than the declarative parts. But with your code, you'll be adding another "or die" for each parameter.

I agree with you there, and I can see where this will happen if you are validating a large number of parameters coming in from say a web request or something like that. At that point, something like Params::Validate is the superior solution. However, when I speak of pre/post-conditions I am really talking about checks on arguments for methods in classes. IMO it is good style to not have more than few (2-3 tops) parameters for methods. Any more parameters, and it is likely that you need to either subclass or be more polymorphic. Validating a few (2-3) parameters with || die is not a problem, and can even be done in a single line if you want.

Anyway, I don't think you have to use it, but I think your optimizations here are seriously premature.

But they are not optimizations, but instead using the optimial approach. As I said in another post here, why would you not want to use the sharpest knife in the drawer? I see this style of assertions as being easy to read and understand, and having the added benefit of also being fast too. If I was going to build an application, and needed a module which had a pure perl version and an XS version, I would choose the XS version because it just makes sense (assuming of course they were reasonably equivalent).

You should be using some sort of module for this stuff, not hand-coding it over and over and over, especially since you say you use it everywhere.

Why should I use a module for this? It is not something that IMO needs to be in a module, and any module I would write would still require me to declare my conditions which is the bulk of what I am doing with this approach anyway.

I agree that with a large number of parameters, each of which have specific validation needs, something like Params::Validate is the way to go, but surely you would agree that it would be overkill for just testing if an argument is defined and of a specific type? (which is the majority of what I use this for)

Modularity is a great concept, but like all good ideas, it can be overused or just badly used. There is a time and place for a module, and there is a time and place for a good solid idiom. I think that (simple) pre/post-condition checking of method/function arguments is be done with an idiomatic approach rather than trying to abstract and modularize a general purpose approach which will almost surely never be optimal in all situations.

You could use a source filter if you're really dead set on maximum speed.

First of all getting even midly complex source filters right is difficult at best and impossible at worst, otherwise you would see some kind of full blown perl macro system out there. Perl is just very hard to parse, and doesn't lend itself well to things like this. Source filters are not a way to increase relability and robustness, they are a way to introduce subtle and insidious bugs.

Second, I am not dead set on speed. I am dead set of building robust and reliable modules which break in all the right places. And in order to achieve that I would like not to have to sacrifice speed (subroutine calls) and memory (module loading). I would like the users of my modules not to have to deal with the consequences of my descisions/trade-offs.

-stvn

[reply]
[d/l]

In Section Meditations