"Phillip J. Eby" wrote:
> Nope. The two levels of methods (get/retrieve and new/create) are there to
> seperate Rack-level concerns from implementation concerns. getItem() and
> newItem() handle maintenance of Rack-level invariants such as the retrieval
> cache, while retrieveItem() and createIt
At 10:33 AM 7/4/00 +0400, Jephte CLAIN wrote:
>
>Back to my first question: is it intended that Rack.createItem (a IMHO
>low level method) calls Rack.getItem (a IMHO higher level method) to
>check the existence of the item?
Yes. It is perfectly valid OO design (and common framework-building
prac
"Phillip J. Eby" wrote:
> >When Philipp wake up (I guess he's asleep right now :-)), he might give
> >his opinion about that.
> I've been on vacation.
I knew it. But it's always funny to play with timezone issues.
> I'm basically with Mike on this one, with a slight
> amplification on my intentio
At 11:54 AM 6/27/00 +0400, Jephte CLAIN wrote:
>mike wrote:
>> There is no way to infinite recursion if Rack.getItem is leaved
>> untouched.
>Ah ah. But people will touch it. Like me for example :-)
>There is no way to prevent overriding getItem from a ZClass for example.
>And it *will* recurse i
Jephte CLAIN wrote:
>
> mike wrote:
> > There is no way to infinite recursion if Rack.getItem is leaved
> > untouched.
> Ah ah. But people will touch it. Like me for example :-)
> There is no way to prevent overriding getItem from a ZClass for example.
> And it *will* recurse infinitely, making Z
mike wrote:
> There is no way to infinite recursion if Rack.getItem is leaved
> untouched.
Ah ah. But people will touch it. Like me for example :-)
There is no way to prevent overriding getItem from a ZClass for example.
And it *will* recurse infinitely, making Zope dumping core.
> getItem/newIt
Jephte CLAIN wrote:
>
> mike wrote:
> > > This causes infinite loop because Rack.newItem calls Rack.createItem
> > > which calls my (modified) getItem
> >
> > 1. Leave getItem untouched. Move all that SQL-related stuff into the
> > retrieveItem method which *is intended* to be overriden.
> >
> >
mike wrote:
> > This causes infinite loop because Rack.newItem calls Rack.createItem
> > which calls my (modified) getItem
>
> 1. Leave getItem untouched. Move all that SQL-related stuff into the
> retrieveItem method which *is intended* to be overriden.
>
> 2. Move newItem stuff into Specialist
Jephte CLAIN wrote:
>
> mike wrote:
> > Jephte CLAIN wrote:
> > > Rack.createItem (low level method) first calls Rack.getItem (higher
> > > level method) to check the existence of the item.
> > > This causes infinite loop in certain cases. It should (IMHO) call
> > > Rack.retrieveItem instead
> >
mike wrote:
> Jephte CLAIN wrote:
> > Rack.createItem (low level method) first calls Rack.getItem (higher
> > level method) to check the existence of the item.
> > This causes infinite loop in certain cases. It should (IMHO) call
> > Rack.retrieveItem instead
> Could you provide an example please?
Jephte CLAIN wrote:
>
> hello,
>
> Rack.createItem (low level method) first calls Rack.getItem (higher
> level method) to check the existence of the item.
> This causes infinite loop in certain cases. It should (IMHO) call
> Rack.retrieveItem instead
>
Could you provide an example please?
Mik
hello,
Rack.createItem (low level method) first calls Rack.getItem (higher
level method) to check the existence of the item.
This causes infinite loop in certain cases. It should (IMHO) call
Rack.retrieveItem instead
regards,
jephte clain
[EMAIL PROTECTED]
__
12 matches
Mail list logo
