Hey,

(Full replied to message can be found here: http://pastebin.com/J0aLk2t9)

Please respond to appropriate mail list -- either WikiTech-L

Might be interesting to people here :)

But I found terminology used in Validator frustrating and misleading.

Well yeah, I agree, the names parameter and argument are used pretty loosely through the extension.

However, it will break compatibility with existing Validator… What do you

think? It is possible? How manage compatibility? Create incompatible Validator2?

In general I agree with your remarks, but it's not really possible to just change this on the fly, as it would break a lot of compatibility. I suggest creating a new alternate system while keeping the old one, so things can gradually be migrated, and then have the old thing go when it's no longer used.

In particular, I'd like to split the param definition from the parameter (with value) handling functionality. Since the Parameter class is used all over the place to define parameters, changing this one would be hard. I also thing it's not that bad of a name, and clearer then Descriptor. So maybe it's better to find an alternate name for the "parameter with value" class, which is only used in Validator itself anyway. And I'd like to have a more lightwight way of defining parameters, rather then creating a Parameter object for each. In most cases an associative array suffices, which can then be turned into an object later on.

And I think the current way parameter criteria and manipulations are defined sort of sucks. You need a class for each, while often you want to do very simple stuff. Passing in a function should also work. In PHP 5.3+, anon functions would make a lot of sense here. If a separate parameter definition class is cerated, it might actually make a lot of sense to have doValidation and doManipulation methods in there. This does not allow to share criteria and manipulation objects like the current system, but is probably less of a hassle and less over engineered.

Also, I'd like to get rid of the evil LSB hack in the ParserHook class, but guess it's still to early to do that (since you'd need PHP 5.3+).

Any such changes would contribute to a new mayor release, version 0.5. The last big changes, those for 0.4, where made over a year ago, and although I see a bunch of stuff that could be made better architecture wise, the current system works. So I'm not that keen on making these changes now and deal with all the compatibility issues. (Maybe after SMW 1.7 has been released.) But if you feel like poking at it or writing up a proposal for a new architecture, please do, I'll happily provide feedback.

BTW, in many languages positional arguments are allowed before the first

named argument. Validator allows:

{{ #func: pos1… | namedA=… | pos2… | namedB=… }}

Yeah, it does allow this. Originally it did not, but I figured some users might not understand or think about the difference, so I just added this because it works. I don't see what your issue with this is. I don't know how this is called, but don't see how that matters :)

I am sure Validator is a great idea and really helps. I used it in few my

extensions. I also wrote parser function `#validate' to validate template arguments and use it in almost all my templates!

Well, please share your code - sounds like this could be useful to other people as well ;)

Although the current architecture might need some tweaking to become really nice, I think having a declarative system for parameters is very powerful as it allows for a whole range of cool things, which is why I created the extension in the first place. Since then I've only become more convinced of this, and would really like to see such functionality get put into core at some point, in one form or another. Any comments on this are appreciated.

Cheers

-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --