[Opensource] Future Code for Expresso 5.1 and beyond [LONG THINK TANK ARTICLE]

[D Lloyd]

Choice 1 and 3 may have similar code bases, but would it not be better
encapsulation and possibly better re-use to go with choice 1?

Just playing devil's advocate,
David Lloyd


--- larry hamel <expresso at codeguild.com> wrote:
> hi Mike,
:
:
:
> 
> >Pseudocode:
> >
> >        DBObject.getField().asString()/.asDate()/.asInteger()  etc.
> >
> >                or
> >        (Date)DBObject.getField()/(String)DBObject.getField() etc.
> >                or
> >
> >        DBObject.getFieldString()/.getFieldInt()/.getFieldDecimal()
> >
> >Maybe it's preference, but I don't really like the 3rd method, even
> though that's what we're doing right now.  The biggest problem is that
> it is part of the reason we have this monster of a DBObject class right
> now.  By delegating conversion code to the field object (as in #1) we
> slim down DBObject.   #2 is easier to code in that you make DBObject a
> dynabean and leave it up to the coder to know what is what.... but I
> think it might lead to weird class cast exceptions.  So I'm currently
> leaning towards #1 as my own personal preference.
> 
> does choice 2 work if we want transformations from one type to another? 
> it is useful to have every field rendered as a string sometimes.
> (everything coming from SQL is a string under the hood, so this should
> remain inexpensive, right?)  
> 
> if choice 1, in essence, just moves the methods from DBObject to
> DBField, are we creating a monster DBField class?  
> 
> unless I'm missing something, +1 vote for choice 3. (i.e. leaving
> methods in DBObject).  these methods get a lot of use in expresso, so
> convenience (smaller # of keystrokes) may deserve more weighting.
> 
:
:
:
> 
> larry
> 


__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/