Try as I might, I just cannot see where operator overloading has a darn thing to do with this. Nor what operator overloading and constructors notionally have to do with each other. Constructors can/do set parameters in OO, period, whether you're defining operator overloads or not.
Could you explain why or how overloading an operator would help someone define an email address default pattern, Charles? ∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me: http://www.google.com/search?q=andrew%20badera On Sat, Oct 3, 2009 at 9:20 PM, Charles A. Lopez <[email protected]> wrote: > this reminds me of operator overloading. The function runs code depending on > what parameters are received. In your case, elements are the parameters. You > Add or modify data with constructors. > > just my $.02. > 2009/10/3 rbr <[email protected]> >> >> Hello, >> >> I have a problem to solve and have come up with a few solutions. >> however, none are as clean as I would like them. I was hoping that >> someone would have done something similar and have good suggestions >> for solving the following problem: >> >> Problem: >> >> We receive data via a webservice from clients. They come in as XML and >> we map these elements to one of our Domain objects. We do not receive >> a few required elements currently and build them using the included >> elements via a hard-coded pattern. We now have the request from our >> clients to allow them to define this pattern. >> >> Example: >> >> We receive user credentials in mass uploads to our system. Currently >> we do not recieve an email. Our system requires an email so we build >> an email for each user by contatenating elements we do receive. In our >> case we use firstnamelastn...@[client.com]. Our clients are requesting >> the ability to define this pattern. So, for example, one client wants >> the following pattern. >> >> [firstname.firstletter][lastnam...@[client.com] >> >> (I just made up a faux pattern definition language for illustration >> purposes. We have not defined this aspect yet.) >> >> So, we would like the ability to define this patter per client in a >> config file, read it in, and build it appropriately. >> >> Does anybody have experience with this type of problem? It does not >> seem like it would be uncommon and we have come up with a few >> solutions. However, I would like to get outside input to make sure we >> are not missing something. >> >> We have certainly considered the strategy pattern. And that is >> porbably our "best" solution thus far. However, I would prefer a >> solution that would not require new coding when a new (not previously >> defined) pattern is introduced. >> >> Thanks in advance! >> >> rbr > > > -- > Charles A. Lopez > [email protected] > > Registered Microsoft Partner > > New York City, NY > > I'm running on Windows 7 Build 7100 > > Quality Software Works >
