Hi, Am Freitag, 21. Dezember 2007 schrieb Alexandru Stanoi: > Thomas Nunninger wrote: > > Hi, > > > > there is an issue (#010913) about complex datatypes for persistent > > object. I don't know in deep about the disussion - but I just have > > an idea: > > > > Wouldn't it be good to have a dedicated Datatype component? This > > component could cover things like validation, conversion (to an > > internal representation and between different representations e.g. > > degree Celsius and Farenheit), and provide datatype specific > > operators, e.g. calculating a distance between two location-related > > datatypes. > > > > This component could be used in several places: > > > > - input validation > > > > - business objects > > > > - persistent object > > > > What do you think about such a component? > > Does it need to be a component? Then all (or at least some) > components will depend on it.
I don't really care if it is an own component or if it is in the Base component. But personally I think I would not blow up Base as it will only be used in some components. But I agree that the component itself is of no use - only if it is integrated in some other components or the developers application. But I think, you won't integrate it in all but only some few components. > I think having a "Tools" class in Base would be better, or some > conversion classes, like ezcBaseDateConverter and > ezcBaseTemperatureConverter. But then you actually don't need these > classes, just use date() with a format and the Celsius/Fahrenheit > formula and you are done. For distances there is also a formula which > does not need to be wrapped in a class inside a component in order to > be used. I'm not sure, if you got my intention: e.g. the integer datatype could ensure that the value is in a specific range. Or a currency datatype could store the currency and if is EUR, NOK, USD, ... That's the main idea. Providing datatype specific operators is just the next (logical) step of that idea. Some of those operators may be syntactical sugar, others will cover simple or complex algorithms. And having those datatypes you could also say: ok, I store it to database in an appropriate way (using as many columns as you need to). E.g. you could store a currency in a decimal column or store the Cent (instead of Euro) to ensure there are no rounding errors when calculating with them in the database. As written there are many things that can be covered by such datatypes. And as most of us use the same datatypes for most of the work it would be nice if not everybody needs to write his own abstraction or (perhaps even worse) do it manually on several places. > So I think it won't make much sense to have a dedicated component for > data types. It would force the users of ezc to learn it and use it, What should they learn and use? > and we said that our components must be independent and general > purposed. I think, it is general purposed. And I agree that dependencies should be solved via TieIns. I hope, I could make it some more clear now. Have a nice day and relaxed Christmas holidays Thomas -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
