Page 3 of 3
Re: Statiscal lazy loading idea
Posted: Thu Dec 04, 2008 10:38 am
by allspiritseve
PCSpectra wrote:That goes for any problem. Everything is simple once it is understood
Man, you and jshpro2 sure like your philosophy, don't you
PCSpectra wrote:I recall reading a study/article years ago, titled: "what makes a super programmer" or something similar...the study was from 1978 in an old book I have so it's a little dated. The conclusion was that of all backgrounds tested (Psychologists, physicists, etc about a dozen in total) mathematicians made the best programmers. Assumingly because they are 'experts' at breaking complex problems into atomic problems.
That made me laugh... I'm picturing my abnormal psych prof trying to program.

(I'm a psychology major)
Re: Statiscal lazy loading idea
Posted: Thu Dec 04, 2008 2:24 pm
by alex.barylski
Man, you and jshpro2 sure like your philosophy, don't you
Sure I guess....I think he's probably more formal than me.
Most of my understanding of philosophy, spirituality and psychology is from self-observation and just spending a lot of time thinking about thinking...
Cheers,
Alex
Re: Statiscal lazy loading idea
Posted: Fri Dec 05, 2008 12:27 am
by josh
PCSpectra wrote:Man, you and jshpro2 sure like your philosophy, don't you
Sure I guess....I think he's probably more formal than me.
It takes one debauched by the process of learning to question 'why'

Re: Statiscal lazy loading idea
Posted: Fri Dec 05, 2008 2:05 am
by alex.barylski
One will slide further in bullsh*t when compared to gravel.
Now that were getting all Filisofical and all...I'd just like to add:
2b || !2b --- That is the question...
Re: Statiscal lazy loading idea
Posted: Mon Dec 08, 2008 10:18 pm
by allspiritseve
An interesting variation on the original post:
Fowler wrote:The way to deal with [situations where different use cases work best with different varieties of laziness] is to have separate database interaction objects for the different use cases. Thus, if you use DataMapper (165), you may have two order mapper objects: one that loads the line items immediately and one that loads them lazily. The application code chooses the appropriate mapper depending on the use case. A variation on this is to have the same basic loader object but defer to a strategy object to decide the loading pattern.
Re: Statiscal lazy loading idea
Posted: Mon Dec 08, 2008 11:45 pm
by Kieran Huggins
So would a strategy object essentially be a model wrapper with embedded laziness settings?
Like:
Code: Select all
class User extends SmartORM # vanilla User class, default laziness
# properties
property id, Integer, auto-inc
property username, String
property name, String
property description, Text
property signature, Text
# associations
belongs_to groups
has_many posts, order_by(date, desc)
end
class Poster extends User # the class to use when displaying posts
lazy [description,username,groups]
eager [id,name,signature,posts]
end
class Profile extends User # the class to use when displaying profiles
lazy [username,posts]
eager [id,name,signature,description,groups]
end
Re: Statiscal lazy loading idea
Posted: Tue Dec 09, 2008 12:41 am
by allspiritseve
Kieran Huggins wrote:So would a strategy object essentially be a model wrapper with embedded laziness settings?
That's probably one way to do it. I think he meant injecting an object through a method, such as setLoader (LoadingStrategy $loader) ...but subclassing works as well.
Re: Statiscal lazy loading idea
Posted: Tue Dec 09, 2008 2:37 am
by josh
Or any kind of compositional inheritance / "behavioral" design pattern

Re: Statiscal lazy loading idea
Posted: Tue Dec 09, 2008 2:47 am
by alex.barylski
compositional inheritance

Re: Statiscal lazy loading idea
Posted: Tue Dec 09, 2008 8:59 pm
by josh
Composition is inheritance. Sub classing is static inheritance, only a subset of kinds of ways to inherit functionality. Delegation is a way to inherit functionality, despite it's de-facto usage. I guess head first books don't teach you that, only GoF. The confusion, I guess, comes from implementation specific terms vs the context I'm using them in being for analysis / design phases.