I use filters quite a lot, filters as supplied by the language (Perl and Shell), or filter frameworks written by me (Python). From what I have learned, your design is far too ambitious - you don't need an XML schema to store information about objects. You want your filters to comply to a simple, common interface - don't try to make filters optimize their connections, simply build optimized filter-pairs if you need them.

The filter pipeline setup can be well stored in an XML file, but if your interface is as simple as I recommend, there is not much difference between an XML file and your program, as most of your programming becomes declarative. To illustrate this, here is a small module/program, that filters a list out of one of our hosts into a csv file (Python code ahead) :

if __name__ == '__main__':
        InputFilename = sys.argv[1]

        output= Pipeline(
                FileFilter(),
                WVS19502Filter(),
                Date(["Valuta","DD.MM.YYYY"]),
                apply(Kommazahl,columns),
                SimpleCSVOutputFilter(["Broker","Valuta","Waehrung"]+c
+olumns,","),
        ).run(files(InputFilename))

        OutputFilename = "../OUTPUT/"+os.path.basename(InputFilename)+
+".csv"
        out = open(OutputFilename,"w")
        out.write(string.join(["Broker","Valuta","Waehrung"]+columns,"
+,")+"\n")
        for i in output:
                out.write(i["line"]+"\n")
        out.close
[download]

As you see, except for the setup and the output, everything is declarative. The interface each filter supports is simply two methods :

• constructor() - all relevant parameters for operation are passed to the constructor.
• process() - this method processes an array of hashes into another array of hashes. Each row of data is organized as a hash to easily allow adding / removing / permutating the data.

As for the language of implementation, this concept can be implemented in almost any language, as it neither requires reflection nor multiple inheritance. If you're looking for a resource-eating multithreaded parallel implementation, you will feel at home in both languages, but as the interface is so simplicistic, the type-enforcement of Java will buy you nothing.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]

1. There is a design pattern that does what you want it to do. It's called a (I think) facade. The idea is that you have a bunch of layers over an object that will trap calls to a method and validate whatever. Once that actual object's method is called, it can assume the input data is good.
2. Java implements a concept of interfaces in the language. Perl does not. Perl allows you to implement interfaces yourself. You can do more with interfaces in Perl than Java, but you have to do all the work. (Or, you can delegate the work to a module.)
3. Perl allows you to create any constructor class you want. And factories and base classes and whatever else you want. You just have to do it (or find a module to do it).
4. XML is not a schema for storing anything. It is an eXtensible Markup Language. It is not a specification language, a storage language, or anything other than a markup language. Don't use XML for something it is not suited to do.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

There is a design pattern that does what you want it to do. It's called a (I think) facade. The idea is that you have a bunch of layers over an object that will trap calls to a method and validate whatever. Once that actual object's method is called, it can assume the input data is good.

Somebody almost certainly has documented filters as a design pattern - but it's not a facade :-)

A facade is when you hide the details of using a group of objects behind a simple interface (e.g. LWP::Simple is a facade for LWP::UserAgent et al.)

There's an article on facade's in 0.4 edition of the Perl Review for those interested.

I have been doing some background reading on 'facades'. As far as I can work out facades are a way of combining previously unrelated objects. Out of interest, where do you think that this comes into what I have described? I am not saying you are wrong in your assertions. I would just like to understand your thinking behind them.

I am interested in using Facade methods. There is a Perl class called 'Facade'.

NAME
    Class::Facade - interface to one or more delegates
[download]

Does anyone have examples of where they have used this class for the purpose previously described? I have read through the documentation. However, it is not easy for me to understand.

An XML question related to point 4. If you had a large number of filter objects, how would you store the objects in a database?

Forget XML. XML doesn't exist for your solution. You are NOT using XML.

You are asking how to serialize objects. There are a million solutions for that, from Object-Oriented databases to solutions in C++, Java, and Perl.

In Perl, a quick'n'dirty solution could use Storable to serialize the object and store the serialized string.

Better would be to have the object know how to serialize itself, possibly depending on Storable to do the actual dirty work. (Some modules, like DBI, don't store well.)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

_________
broquaint

I think that there are some similarities to FBP. However, I don't wish to pass them through filters that change the data passing through. I simply want all my bundled objects to meet associated conditions. For example. If I had a bunch of objects that represent components of a car:- wheels, hood (American term), doors, windscreen (British term), seat belt. These objects don't together make a car. But the suppliers of these components all have to meet a given safety standards, depending on the market for the car. You have already made your cars. Given that all other export conditions have been met, to what markets can we sell the manufactured cars? ie. Each market has a set of conditions that relate to each component type (object). And all these conditions must be met, without exception. There are some standards for particular components that are common across different countries and therefore replication of objects representing these safety standards would be silly. In addition, some countries do not have conditions for all component object types. And therefore, for some analysis, all the object types are not allways required. I am not working for a car manufacturer. However, my OO problem is the same. Are there any clever monks out there that can do a better job at explaining the OO concepts behind what I have just written? Or suggesting a practical approach to how I tackle this. Java or Perl, that is the main question.

In Perl you can apply a predicate to a list using the "grep" function and you get back all the things in the list that the predicate classifies as "true". E.g.

perl -le 'print join " ", grep { $_ > 4 } (1,7,2,6,3,5,4)'
[download]

In other languages, this function (or its inverse) may be called "find_all", "filter", "select", "remove-if", or "reject". I don't know of any general framework for an XML syntax for the predicates or the filters, though

Thanks for the grep code. I have tried a variation on you code as follows:

perl -le 'print join " ", grep {  $_ =~ /start4/ |  $_ =~ /end7/ } (st
+art4,end7)'
[download]

How would you advance on this to produce a condition of print if the end position minus the start position is greater than 3?

I have answered the question myself.

perl -le '$a = join " ", grep {  $_ == 4 } (4); $b = join " ", grep { 
+ $_ == 7 } (7); $c = $b-$a; print $c;'
[download]

1. Does Java considering more things as object than Perl? No, this question is even irrelevant to any language, whether a thing is an object is really a design consideration, oppose to a language specific issue. From a more broader view, any thing that is an object in the real world, can be extracted as an object in your virtual world, the computer world. Again, this is 100% a design choice, nothing to do with language.
2. Whether filtering is an object in Perl? Have said point one, this question should really been divided into two questions: 1) Whether there is the concept of "filtering" in the real world? yes, and a lot of them for different purposes. You may want to filtering an incoming TCP stream, and only grab those packets you wanted; You want to filtering an image and only grab a particular part you wanted; You may want to filtering all CPAN modules, and only grab those under Win32::GUI, this goes on and on. Generally speaking, in real world "filtering" means to generate a sub set of a whole. 2) Do we have "filtering" modules in Perl? Well, as I said depends on what you want to filter, and how you want to filter them, CPAN is always there.
3. Conceptually XML can be understood as a way to persist your computer object, or on the other hand, a way to describe your real world object. It is alright to use XML format store your object. Again, this is not related to language choice, Perl, Java, or whatever.
4. The difference between Java OO and Perl OO is not at the conceptual level, but rather at implementation level. I agree that Java has a more mature implementation of OO, but there is nothing stop you from do what you want in Perl, especially this "filtering" thing.

>1. Does Java considering more things as object than Perl? No

I'm not sure I agree with this statement, even with its follow-up. In Perl, everything can be implemented as an object if you are willing to do the work; a great example of this is tied stuff. In java, everything short of base types is an object, and even these base types have optional classes built into the language core.

Offhand, my uneducated opinion is that applying strict filters to objects is more instrinsically accomplished with java, with its strong typing, single inheritance, and enforced method signatures, as opposed to Perl with its vague typing (scalar, list, boolean, void), multi-inheritance (use base class1, class2...classn), and pathetic proto-typing. Don't get me wrong, you can do it all with Perl, but it's not built in nearly as strongly to the language itself. If someone wants to kick the crap out of the above assertions, please be my guest. :)

No, I have no problem with your assertion. On the contrary, I fully agree with you.

At the implementation level, Perl only supports very primitive OO concepts, and it is pretty much hacked for the sack to be modern.

Java is OOO, "OO"-oriented. It is based on OO methodology, it is almost a full (there are still gaps) implementation of OO methoddology, and it solely exists for OO.

Even c++ is not that OOO. When you write code in c++, you can choose not to have even a single class, but in Java, at least you have to have at least one class, (although a bad Java programmer can put everything into one huge class, and all code into the constructor of that class, that's just the bad judgement of a single person;-)

When I replied to the original post, I am more focused on a conceptual level. What I dislike the most is that, the author of the original post clearly mixed OO design with specific languages. (I dislike the idea, not the author, make this crystal clear)

OO is not a language, it is a design methodology, language is just the implementation of the idea, not the idea.

There is no such question as whether Perl have the filter object. Filter is an object, this is a given, and it is a reflection of the real world. It can be implemented by using Java, as well as using Perl.

Of course, on the other hand, When Perl can make it, Java can make it really gracefully, and make it into a beauty. I don't have problem with this assertion, not at all ;-)

I love Perl, but not a fundamentalist.